Incident response cycle in a nutshell

• Preparation
  • Define your "team" -- roles, responsibilities
  • Policies (e.g., account use, passwords, punishments)
  • Procedures (e.g., system integrity checks, account expiration, patch application, investigation)
  • Have (and know how to use) security tools
  • Make good backups
  • See: CERT's List of Security Tools, UNIX Configuration Guidelines and C&C's Unix System Security Checklist

• Detection
  • Assess type and extent of problem
  • As soon as you know this is a real incident, do a full backup ASAP!
  • Start documenting everything in a notebook (with time/date)
  • Keep track of time spent (a good open source tool is TimeTracker)
  • Capture audit information, accounting data, etc. for evidence
  • Realize that the intruders may have installed trojan horse programs that hide things
  • Initiate notification process (at least send email to security@cac.washington.edu)
  • See: CERT's Intruder Detection Checklist

• Containment
  • Continue to document your actions and track time spent
  • Notify departmental administration
  • Decide whether to shut the system down or keep it running
  • Decide when/how to notify users

• Eradication
  • Don't stop documenting what you are doing (and tracking time)
  • Should you check binaries for tampering or just re-install the entire operating system?
  • Should you clean/reformat discs?
  • Are backups OK, or do they need to be checked as well?

• Recovery
  • Follow your recovery procedures (make one now if you didn't before)
  • Did I mention you should document your actions?
  • Do you need to restore user files/data from backups?
  • See: CERT's Steps for Recovering from a UNIX Root Compromise

• Follow-up
  • Review what has been done; were your procedures adequate?
  • Write a summary report of the incident and "lessons learned"
  • Use the logs you've been keeping to assess time/cost of handling this incident; law enforcement will need damage estimates to persue prosecution

[Next]