Critical Log Review Checklist for Security Incidents

This is a checklist for reviewing critical logs when responding to a security incident. It can also be used for routine log review.

General Approach

  1. Identify which log sources and automated tools you can use during the analysis
  2. Copy log records to a single location where you will be able to review them.
  3. Minimize “noise” by removing routine, repetitive log entries from view after confirming that they are benign
  4. Determine whether you can rely on logs’ time stamps; consider time zone differences.
  5. Focus on recent changes, failures, errors, status changes, access and administration events, and other events unusual for your environment
  6. Go backwards in time from now to reconstruct actions after and before the incident.
  7. Correlate activities across different logs to get a comprehensive picture
  8. Develop theories about what occurred; explore logs to confirm or disprove them.

Potential Security Log Sources

  • Server and workstation operating system logs
  • Application logs (e.g., web server, database server)
  • Security tool logs (e.g., anti-virus, change detection, intrusion detection/prevention system)
  • Outbound proxy logs and end-user application logs
  • Remember to consider other, non-log sources for security events.

Typical Log Locations

  • Linux OS and core applications: /var/log
  • Windows OS and core applications: Windows Event Log (Security, System, Application)

What to look for on Windows

  • User logon/logoff events
  • User account changes
  • Password changes
  • Service started or stopped
  • Object access details

What to look for on Network devices

  • Traffic allowed on Firewall
  • Traffic blocked on firewall
  • Bytes transferred
  • Bandwidth and protocol usage
  • Detect attack activity
  • User account changes
  • Administrator access

What to look for on Web Servers

  • Excessive access attempts to non-existent files
  • Code (SQL,HTML) seen as part of the URL
  • Access to extensions you have not implemented
  • Web service stopped/started/failed messages
  • Access to “risky” pages that accept user input
  • Look at logs on all servers in the load balancer pool
  • Error code 200 on files that are not yours

Authored by Anton Chuvakin (chuvakin.org) and Lenny Zeltser (zeltser.com). Reviewed by Anand Sastry. Distributed according to the Creative Commons v3 “Attribution” License.

 

Please follow and like us: