Incident Response and Digital Forensics – Denver Chapter of ISACA

1. Incident Response and Digital Forensics –Denver Chapter of ISACA

2. Outline • Introduction • The Incident Response Process • Preparation • Identification • Containment • Eradication • Recovery • Lessons Learned • The Attacker Process • Reconnaissance • Scanning • Exploitation • Keeping Access • Covering Tracks • Conclusion

3. Introduction • FishNet Security • Started in 1996, largest InfoSec VAR • Support, Consulting, Training, Products • Locations – Boston, Omaha, Kansas City, St. Louis, Dallas, Minnesota • Assessment Team: Policy, Network, WebApp and DB, Wireless, IR and Digital Forensics

4. Introduction • Trey Keifer - (trey.keifer@fishnetsecurity.com) • Level II Security Engineer • Sr. Incident Response Analyst • Coordinator of Incident Response Program • SANS Certified Incident Handler (GCIH)

5. Incident Response and Digital Forensics • One of the least practiced, most stressful, highly scrutinized areas of Information Security. • Every incident is unique and can incorporate many different areas of the affected organization. • Incident analysts must be able to think quickly, remain calm and consider all possibilities.

6. Common Incident Types • Economic Espionage • Intellectual Property Theft • Unauthorized Access • Stolen Passwords and Data • Unauthorized Use • Inappropriate E-Mail and Web Habits • Malicious Code • Worms with Backdoors (Sasser) • Insider Threats

7. 6 Steps of the Incident Handler Methodology • Preparation • Identification • Containment • Eradication • Recovery • Lessons Learned

8. Preparation: • The key to a successful response is preparation. • Form a strategy. • Design a procedure. • Gather Resources. • Practice, practice, practice.

9. Preparation: • Identify the “Core Team” • Technical (IT, InfoSec and System Owners) • Management • Legal Department • Forensics • Public Relations • Human Resources • Physical Security and Maintenance • Telecommunications

10. Preparation: • Organizing Individuals • All members of the CSIRT team should know their role and how they will interact with the other members. • Outsourced or “third party” members should have contracts in place. • Contacts for Law Enforcement should be known and situations for their involvement discussed.

11. Preparation: • Develop a Procedure • Incident response can be a high-stress time. A well documented procedure, that is easy to follow, can greatly reduce the anxiety. • Develop a call tree and notification procedures • Brainstorm likely scenarios. • Identify general information needed in most scenarios ahead of time. • Make checklists and forms for as much as possible.

12. Preparation: • Communication • Communication is incredibly important during an incident. Not only the people involved, but the method which it is done. • Updates should be frequent. • Out-of-Band Communications are very important. • Faxes • Cell Phones • Be careful with the Blackberry’s

13. Preparation: • Access Rights • The incident response team must have access to systems without the administrators authorization. • Controversial Issue • User Accounts, Passwords and Encryption keys • Third-party storage methods are available

14. Preparation: • Policies • Protect the organization from legal liability and allow investigators to do their job. • Warning Banners are readily displayed. • Search policy is detailed in employee manual. • Human Resources and Legal have signed off. • Employees have acknowledged knowing their expectations on privacy. • Beware of international laws (European Privacy Directive)

15. Preparation: • Gathering Resources • Incident analysts should have all information ready and be able to respond to the incident. • Procedures, Checklists and Forms are ready. • Access credentials are available or individuals with them are known. • System information, network diagrams, software and intellectual property are documented thoroughly.

16. Preparation: • Training • SANS Institute and GIAC Certifications • Track 4: Incident Response and Hacker Techniques • Track ??: Digital Forensics • Vendor Training • Guidance Software • Access Data • Partners • Incident Response Scenarios

17. Identification: “Incidents can’t always be prevented, but must always be detected.”

18. Incident: Intentional or Unintentional • Multiple failed logins to the domain administrator account. • Administrator credentials were cached on a users workstation and they are attempting to login. • Someone is actively attempting to brute-force the account.

19. Identification: • Goals • Determine Scope • Identify what systems, people and informational assets are involved in the event. • Preserve Evidence • Protect the facts of the incident while determining the scenario.

20. Identification: Suspicious Events • Unexplained Occurrences • New Accounts or Files • File Modifications • IDS Triggers • Firewall Entries • Accounting Discrepancies • Poor Performance/Unresponsive services • System Instability

21. Identification: Passive Identification • Sniffers and Traffic Analysis • Cyclical Buffers allow full recording of events at the packet level to a point, depending on size and utilization. • Target machine evidence is still preserved. • Assist in determining new attacks for which signatures have not yet been written.

22. Identification: Passive Identification • Intrusion Detection Systems • Least invasive method • Target machine evidence is preserved • Logs must still be protected • Write-Once, Read-Many Media

23. Identification: Passive Identification • Tripwire-style File Modification • A hash of the file is taken and stored in a secure database. Any modification to that file results in a change of the hash. • Very indicative of a successful compromise. • Can be noisy during patching and must be tuned after every software upgrade.

24. Identification: HoneyPots and HoneyTokens • Specific systems or accounts with additional logging and notification to alert on suspicious activity. • Operators must be careful of entrapment. • Systems have to be secured and heavily monitored. • Systems cannot invite intruders – • No “hackme” accounts • No “Salary Database” systems

25. Identification: Chain of Custody • Evidence must be accounted for from the time it is collected until the time it is submitted to the court. • Each piece of evidence must be under the control of one, identifiable person at all times. • A change in control of the evidence must be recorded. • Evidence in storage must be protected from contamination. (ie… sealed and secured)

26. Containment - Now that the events have been identified as an incident and a chain-of-custody for evidence has been established, we will take the first step into system modification by beginning our containment.

27. Containment: • Vendor Coordination • Work closely with your vendors and know how to open security-related tickets with high priority. • ISPs can prevent some Denial of Service situations. • They are more familiar with attacks because they have seen them with other clients and are up-to-date on advisories. • Additional people working towards identification, containment and recovery. • We are used to the pressure!

28. Containment: • Identifying the Trust Model • The trust model identifies not only the technology, but also the people that are involved in the incident. • What connectivity does the network or system have to other areas in the organization? • What information is contained within it? • Who needs to be involved and to what extent?

29. Containment: • Documentation Strategies • Documentation should be collected from most volatile to least volatile and least invasive to most invasive. • Volatile evidence includes RAM, running processes and active connections. • Be careful of running system commands from anything but recovery media.

30. Containment: • Should we Quarantine? • Changes to a system may be easily observed by an active attacker. • Rootkits may identify a pulled network connection or extensive system modification and protect the attacker. • Some exploits are entirely memory resident and will disappear when the power is pulled.

31. Containment: • Initial Analysis • Keep a low profile • Never analyze the original • Make frequent updates to CSIRT • Acquire log files • Stick to the facts and avoid blame • Consider all possibilities but keep it simple

32. Containment: • Backups • Numerous backups allow both investigation and preservation of evidence. • Different strategies exist and depend on the situation. • Original is kept as evidence • Backup 1 – Placed back in production • Backup 2 – Forensic Analysis • Backup 3, 4, etc… separate copies for analysis

33. Containment: • Digital Forensics • Numerous separate analysis all yield the same results. • Requires specialty hardware, software and training. • Bit by Bit copying and analysis of data. • Recovery of deleted data. • Identification of altered system files (trojans) and binaries in a safe environment.

34. Containment: • Digital Forensics: Hardware Write Blockers • No modification to the data itself, we want to observe and duplicate only. • Hardware device or driver between acquisition machine and target system. • May use NIC, USB, FireWire or IDE/SCSI channels. • Intercepts write commands and gives logical return results. • Allows browsing of the filesystem during acquisition.

35. Containment: • Digital Forensics: Forensic Software • Allows quick and efficient analysis of the information contained on the device. • Guidance Software’s EnCase used by law enforcement. • Linux Forensics CD’s are coming along in maturity. (still must use write blockers!!!) • Scripts allow quick searching of keywords in files and deleted data. • Hash comparisons verify original files, known dangerous applications and aid the examiner in avoiding the bad stuff.

36. Containment: • Digital Forensics: What are we looking for? • Many areas of interesting data are forgotten about. • Cached web content • Email Files (PST’s) • Recoverable Deleted Files • Specific Incidents: CAD drawings, Engineering diagrams, Pornography • Known file signatures of hacking tools, backdoors, etc…

37. Containment: • Digital Forensics: Other devices? • May not be able to submit as evidence in court, but can assist the Incident Handler in their investigation. • Personal Organizers (PIMs): Blackberry, Palm Pilots, IPAQ’s. • SIM Cards/Cell phones • USB Tokens/Flash Drives

38. Containment: • Digital Forensics: Not Perfect! • Some tools have been written specifically to defeat forensics software. • DoD: 7-Pass, random-write method for secure deletion of magnetic media. (Rainbow Method) • Windows: Eraser • Unix: Wipe

39. Containment: • Slowing the Attack • Change passwords and access rights. • Change hostnames and IPs. • Null Route suspicious traffic. • Block IPs or Networks. • Apply Patches to similar systems. • Shutdown services.

40. Eradication - Once an incident has been contained we attempt the total removal of malicious applications from a system or network.

41. Eradication: • Remove or Restore • The decision of whether to remove malicious files or restore from backups is a difficult task. • Rootkits almost always demand a rebuild. • Verification of backups is a must. • Patches may not be available and a total change of architectures may be necessary.

42. Eradication: • Improve Defenses • Implement additional detection and protection methods and strengthen existing technologies and processes. • Apply firewall and router filters. • Perform “mini-assessments” using the same tools and techniques as your attackers. • Look for the same exploits and backdoors on multiple machines.

43. Recovery - Once the threat has been removed the organization must begin the process of returning the business to normal operation.

44. Recovery: • Returning to Operation • System owners make the final call on returning to production. • Owners depend on the systems and know their true value. • If a disagreement occurs on whether to return to production or not it should be documented by the analysts and the owner should acknowledge responsibility.

45. Recovery: • Monitoring • At this point in the process you should have enough information to identify the attack if it occurs again. • Create custom IDS signatures if possible. • Verify proper operation to baseline configurations. • Implement additional logging on network, hosts and applications.

46. Lessons Learned - The lessons learned meeting provides a method for the organization to coordinate knowledge of an incident, suggest changes in procedures and policies for the future and justify the implementation of new safeguards.

47. Lessons Learned: • Recap Meeting • Should occur promptly after eradication of an incident while details are fresh in the team members heads. • Create a timeline of events. • Provide a consensus of notes and documentation. • Finalize facts for a final report.

48. 7 Deadly Sins • Failure to report/ask for help • Incomplete/Non-Existent Notes • Mishandling/Damaging Evidence • Failure to create backups • Failure to eradicate or contain • Failure to prevent re-infection • Failure to apply lessons learned

49. Attacker Methodology • Reconnaissance • Profiling the Target • Scanning • Identifying Weaknesses • Exploitation • Breaking the Law • Keeping Access • Backdoors • Covering Tracks • Staying out of Jail

50. Reconnaissance: • The target is profiled – • Employee Information (name, numbers, titles) • Systems Information (usenet postings, job listings) • Process Information (vendors and transactions) • Location Information (external networks, physical locations)