Responding to Computer Attacks

1. Responding to Computer Attacks Presenter Name Job Title Company

2. Session Prerequisites • Basic knowledge of computer security incidents • Basic knowledge of security incident response • Basic knowledge of Windows networking Level 200

3. What this session is…...and what it is not • It is: • A chance for you to see and understand the methodology and process required for effective incident response • An opportunity to see some of the tools and processes that help you identify attacks • It is not: • A “forensics investigation” class • The definitive guide for all things IR/IH • …we simply want to show you how to plan and react to things if you think you may have been “Øwn3d”

4. “Øwn3D!!!” demo

5. The Demo Disclaimer… • No, I will not give you those tools and they are not on the DVD. It does not matter what you do for a living or who you work for. • If you don’t ask, I don’t have to say no. • …this demonstration was only meant to “wake everyone up” and to show you what an incident could look like. • Remember, SQL Injection is the result of improper form validation…..and can lead to bad things.

6. Agenda • Introduction • The Incident Response Lifecycle • Forming your Incident Response Team • Summary

7. First things first, whatis an “incident”? • An incident is an adverse event (or threat of an adverse event) in a computer system • Adverse events include the following general categories: • Compromise of Confidentiality • Compromise of Integrity • Denial of Resources • Intrusions • Misuse • Damage • Hoaxes

8. The components ofan incident Howard, John D. “A Common Language for Computer Security Incidents” 1998. http://www.cert.org/research/taxonomy_988667.pdf

9. Who are these“31337 H4xØrz”? • Not all are as elite as you (or they) may think…. • …but first and foremost, they’re just criminals. CyberWar Foreign Intelligence THREAT Terrorists Organized Crime Competitors (Foreign & Domestic) Organized Hacker groups “Hacktivists” Real Hackers Script Kiddies CAPABILITY

10. So what is“Incident Handling”? • Incident Handling - Actions taken to protect and restore the normal operating condition of computers and the information stored in them when an adverse event occurs. • Incentives for efficient incident handling: • Economic • Protecting Proprietary / Classified / Sensitive Information • Operational / Business Continuity • Public Relations • Legal / Regulatory Compliance • Safety

11. Incident HandlingMethodology • “Failing to Plan, is Planning to Fail!” • So how do we do that? • You have in place, an IR/IH methodology • Why should we bother using an incident handling methodology? • Provides structure and organization • Improves efficiency • Facilitates understanding the process of responding • Helps dealing with the unexpected

12. Incident Response Lifecycle • The incident response lifecycle consists of six stages: • Prepare • Detect • Contain • Eradicate • Recover • Follow-Up *PANIC is not one of the stages.

13. Step 1 - Prepare • Your direction: • Develop an incident response policy • Create procedures for dealing with incidents as efficiently as possible • Ensure that a suitable management infrastructure is in place • Implement a reasonable set of defenses for systems that are to be used in responding to incidents

14. Solving “Now What?!?”:Your written Incident Response policy • The anchor of an entire incident response effort • A suitable incident response policy should address/include • Provides scope, purpose and objectives • Help define what is a “security-related” incident • Acceptable risk limits, eval criteria, reporting reqs, etc. • Roles, responsibilities and authority

15. Remember… • Good planning will help you mitigate the situation. • You are not the first person this has ever happened too. • Panic is worthless and contagious. • Where are you in your process?

16. Step 2 - Detect • Determine if Incident Occurred: • Determine what the problem is and to assess its magnitude • Major sources of information • Log files and syslog output • Wrapper tools (e.g., TCP wrapper) • Personal firewalls (e.g., BlackIce Defender) • Firewall logs • Intrusion detection systems (IDS) and prevention systems (IPS) • Analyze all anomalies

17. Holy Cow! Is that our IDS? Wow! Kai was right…this new Britney Spears album kicks! No problem. We got Matt on this. He’s on our CERT. If it’s a real intrusion…..he’ll catch it.

18. Understanding the dreadedIP Header Total Length Version TOS Length Flags Offset Identification TTL Protocol Header Checksum Source IP Address Destination IP address Options Data

19. What should I be looking for? • Are any IP Header fields suspect? • Is the Source IP address suspect? • Is odd fragmentation occurring? • Does the size of the packet raise concerns? • Are any TCP header fields suspect? • Is the destination port a valid service? • Does the traffic follow RFC standards? • What are the timestamps of the traffic? Mandia, Kevin and Chris Prosise. “Incident Response: Fighting Computer Crime”. 2001. Osborne/McGraw Hill.

20. Developing an Audit Policy • As with all security policy, proper design of audit policy requires a threat analysis • Audit mitigates some threats with non-repudiation • Audit has real costs • Storage (disk) • Collection (network) • Analysis (machine and human) • Sometimes additional audit categories are desirable for correlation • Process Tracking (except on batch/CGI servers) • Account Logon • Audit Policy is iterative: Test & Refine

21. Some Logon/LogoffEvent IDs • 528 - Successful Logon • 529 - Logon Failure: Unknown user name or bad password • 530 - Logon Failure: Account logon time restriction violation • 531 - Logon Failure: Account currently disabled • 532 - Logon Failure: The specified user account has expired • 533 - Logon Failure: User not allowed to logon at this computer • 534 - Logon Failure: User not granted requested logon type at this machine • 535 - Logon Failure: The specified account’s password has expired • 539 - Logon Failure: Account locked out • 540 - Successful Network Logon (Win2000, XP, 2003 Only)

22. Important Event IDs on yourDomain Controller • 675 – Failed logon from workstation, usually a bad password • 676/672 – Other AutN failure • 681/680 – Failed logon with a domain account • 642 – Reset PW or Disabled account was re-enabled • 632/636/660 – User was added to a group • 624 – New user account created • 644 – Account lockout after repeated logon failures • 517 – User cleared the logs

23. Success/Failure Policy • Audit can be a denial-of-service (DoS)!! • Success audit requires more attacker access & resources and can be constrained by quota • Failure audit can, in the worst case, allow anonymous remote users to consume resources • Success audit • Provides a forensic or accounting record • Failure audit • Provides evidence that security controls are working • Can be used for intrusion detection (if scenarios are clearly defined and analyst resources are allocated) • Can be difficult to analyze • Some failures are normal

24. Setting Audit Policy • When thinking about your policy, consider… • Audit is good at: • Tampering- changes to system executables & config • Change tracking to data files • Audit is not good at: • Recording reads to files (audit directory instead or audit a single critical file) • Explaining events from the user’s point of view (one click often causes multiple audits • Copy protection (where the file went) • Beware of: • Oddly-behaved applications (winword.exe, explorer.exe)

25. Detecting the Incident • Reviewing a Network Trace • Reviewing security logs • Using some great tools demo

26. Step 2 - Detect • Upon Identification: • Obtain full backup and copy any hacked files or bogus code for analysis • If it’s likely you’ve been “Øwn3d”: • Turn on or increase auditing • Set system clock correctly • Document! Document! Document! • Initiate notification process • The IR Team • Your InfoSec contact • Your PR people • Your Legal team • Law Enforcement!!!!

27. Step 3 - Contain • To keep incident from spreading • Important decisions need to be made during this stage: • Do we shut down? • Should we disconnect from the network? • Continue monitoring? • Set a trap? • Disable features? • Call in the Feds?

28. Step 4 - Eradicate • To eliminate cause of incident • Be sure to save any copies of malicious programs before deleting them • May require the use of eradication software • Clean/reformat disks (if appropriate) • Ensure that backups are clean • Continue to document all activities • Continue to keep your public relations and legal offices advised (if warranted)

29. Step 5 - Recover • Business Resumption: • Return to mission status • Follow procedures for system recovery • Send the “All Clear" message • Restore data • Change passwords • Continue to log all activities • For classified/sensitive/proprietary systems, require verification of data integrity

30. Step 6 – Follow Up • Make things better: • Review and integrate info • Most neglected stage of the process, and the most valuable. • Conduct Postmortem • Reevaluate procedures • Assess time and resources used, and financial damage • Prepare report(s) • Support prosecution activity (if applicable)

31. Technical Considerations • React Accordingly!!! • Some incidents occur on large servers with special complications • They cannot be taken off-line, OR • They have so much storage that it cannot be successfully imaged (or have RAID, so an image will be technically infeasible) • The best option is still to perform some sort of backup, at least of the suspicious files and logs, then analyze them off-line • A tape backup will not include all the information such as slack space data, but it may be the only alternative

32. Legal Considerations • Incident Response has legal implication • Documentation is a legal foundation. Do it thoroughly! • Keep good records • Know when to contact law enforcement

33. Some Best Practices forIncident Handling • Verify the incident, ruling out alternative explanations of what has happened • Follow written procedures during incidents • Ensure that you have backups very early during the course of an incident • Coordinate and consult with other technical experts • Keep management advised of status of incident and your efforts • Log all activities

34. Why form anincident response team? • Incidents are complex- experts are needed • Efficiency • Proactive element • Agency or corporate requirements • Liaison function • Authority to engage in activities that a normal organization doesn’t get

35. Considerations for yourIncident Response Team • Executive Sponsorship • Without it, your team will die. • Keep the sponsor aware of the situation • Identify the Key Stakeholders • Not just the “IT guys” • Key reps from all the LOB owners • Choosing a Team Leader • Owns the CSIRT, not necessarily each incident response • Conducts team “post-mortems” to make policy update changes Smith, Ben and Brian Komar. “Microsoft Windows Security Resource Kit v2.0”. 2005. Microsoft Press

36. Train your “A-Team”, Fool! • Mock Incident Response Exercises: • Allows validation of your procedures • “Practice makes perfect” • You can gauge the size and complexity of the process • Benefits increased if external objective observer helps identify issues • Mock Incident Handling Exercises: • Develop a variety of scenarios • Record critical data and evaluate • Conduct at regular intervals • Warning--Carefully plan any mock incident handling exercises to avoid disruption of operational environments

37. CERT’s Virtual TrainingEnvironment (VTE) • FREE! Web-based training resource to the community • Nearly 200 hours of videocaptured course lectures • Over 100 demonstrations of Security techniques and tools • 2,200 pages of written material • Searchable and sortable • CERT® also offers online training through VTE • Introduction and Advanced Information Security • Forensics and Incident Response for Admins • Subscriptions to the 48 hands-on labs in our environment • Learn more about online courses through VTE: http://www.sei.cmu.edu/products/courses/courses.html#VTE • https://www.vte.cert.org

38. CERT’s Virtual Training Environment (VTE) • Classroom instruction • Hands On Labs demo

39. Microsoft Has Resources to Help • Microsoft Security Response Center (MSRC) • Microsoft Security Advisories & Bulletins Sign up to receive security updates notifications via email, instant message, mobile devices or RSS Download and deploy security updates (Microsoft Download Center, Windows Update) Report security vulnerabilities through secure@microsoft.com Attend the monthly TechNet Security Bulletin Webcast Review information and guidelines on the Microsoft TechNet Security site Check out the MSRC Blog at http://blogs.technet.com/msrc

40. Microsoft Security Resources • The Microsoft Security Response Center (MSRC) blog: http://blogs.technet.com/msrc/ • Security Advisories: http://www.microsoft.com/technet/security/advisory/default.mspx • Security Bulletins: http://www.microsoft.com/technet/security/current.aspx • Security Notification Services (regular and comprehensive): http://www.microsoft.com/technet/security/bulletin/notify.mspx • Monthly Security Bulletin webcast: http://www.microsoft.com/technet/security/bulletin/summary.mspx • Contact Microsoft PSS Security: 1-866-PCSAFETY

41. Additional Microsoft Resources • Windows Security Logging and Other Esoterica http://blogs.msdn.com/ericfitz/ • The Security Monitoring and Attack Detection Planning Guide http://www.microsoft.com/technet/security/topics/auditingandmonitoring/securitymonitoring/default.mspx • Microsoft Windows Security Resource Kit v2.0 ISBN: 0735621748

42. 3rd Party Resources! • Computer Emergency Response Team (CERT) http://www.cert.org/tech_tips/incident_reporting.htm • National Institute of Standards and Technology http://csrc.nist.gov/publications/nistpubs/800-61/sp800-61.pdf • Forum of Incident Response and Security Teams http://www.first.org • SysInternals (Freeware utils AutoRuns, PSList, etc.) http://www.sysinternals.com • “Incident Response: Investigating Computer Crime” ISBN: 007222696X

43. Questions and Answers

44. Session Summary • There are bad people out there. • You can properly protect, identify, and resolve network incidents. • Remember, defense-in-depth. • Planning now is critical! • …so is auditing….but I’m sure everyone is already doing that, right?