Slideshare.net (beta)

Slide 1: Integrating Log Analysis into Your Incident Response Practice Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA Chief Logging Evangelist LogLogic, Inc May 7, 2007

Slide 2: TEASER This is a shortened TEASER presentation. Please contact us for a full presentation PAGE 2

Slide 3: Outline  Log and logging overview  Just what is log management?  A brief on Incident response  Logs in incident response  “Log forensics”: reality or marketing?  Conclusions and call to action! PAGE 3

Slide 4: Goals  Get a refresher on logs and logging  Become familiar with log analysis and log management  Learn how logs help during (and before!) incident response  Pick a few logging tips PAGE 4

Slide 5: Logs for Cybercrime Investigations A few thoughts to start us off …  All attackers leave traces. Period!   It is just that you don’t always know what and where  And almost never know why  Logs are the place to look, first PAGE 5

Slide 6: Log Data Overview From Where? What logs?  Firewalls/intrusion prevention  Audit logs  Routers/switches  Transaction logs  Intrusion detection  Intrusion logs  Servers, desktops, mainframes  Connection logs  Business applications  System performance records  Databases  User activity logs  Anti-virus  Various alerts and other messages  VPNs PAGE 6

Slide 7: Top 11 Reasons to Collect and Preserve Computer Lo 1. Before anything else, do you deal with credit cards? Patient info? Are you a government org under FISMA? A financial org? You have to keep'em 2. What if there is a law or a regulation that requires you to retain logs - and you don't know about it yet? Does the world \"compliance\" ring a bell? 3. An auditor comes and asks for logs. Do you want to respond \"Eh, what do you mean?\"? 4. A system starts crashing and keeps doing so. Where is the answer? Oops, it was in the logs - you just didn't retain them ... 5. Somebody posts a piece of your future quarterly report online. Did John Smith did it? How? If not him, who did? Let's see who touched this document, got logs? 6. A malware is rampant on your network. Where it came from? Who spreads it? Just check the logs - but only if you have them saved. 7. Your boss comes and says 'I emailed you this and you ignored it!!' - 'No, you didn't!!!' Who is right? Only email logs can tell! 8. Network is slow; somebody is hogging the bandwidth. Let's catch the bastard! Is your firewall logging? Keep the info at least until you can investigate. 9. Somebody added a table to your database. Maybe he did something else too - no change control forms were filed. Got database log management? How else would you know? 10. Disk space is cheap; tape is cheaper still. Save a log! Got SAN or NAS? Save a few of them! 11. If you plan to throw away a log record, think - are you 100% sure you won't need it, ever? Exactly! :-) Keep it. PAGE 7

Slide 8: A Guide to Log Management: NIST 800-92 “This publication seeks to assist organizations in understanding the need for sound computer security log management. It provides practical, real-world guidance on developing, implementing, and maintaining effective log management practices throughout an enterprise. “ PAGE 8

Slide 9: Incident Response Methodologies: SANS  SANS Six-Step Process [P]reparation [I]dentification [C]ontainment [E]radication [R]ecovery [F]ollow-Up PAGE 9

Slide 10: Logs at Various Stage of Incident Response  Preparation: verify controls, collect normal usage data, baseline, etc  Identification: detect an incident, confirm incident, etc  Containment: scope the damage, learn what else is lost, etc  Eradication: preserving logs for the future, etc  Recovery: confirming the restoration, etc  Follow-Up: logs for “peaceful” purposes (training, etc) PAGE 10

Slide 11: Firewall Logs in Incident Response  Proof of Connectivity  Proof of NO Connectivity  Scans  Malware: Worms, Spyware  Compromised Systems  Misconfigured Systems  Unauthorized Access and Access Attempts  Spam (yes, even spam!) PAGE 11

Slide 12: Example: Firewall Logs in Place of Netflow  Why Look at Firewall Logs During Incident Investigation?  1990-2001 – to see what external (inbound) threats got blocked  2002-2006 – to see what internal system got connected (out)  Thus, firewall logs is poor-mans netflow… PAGE 12

Slide 13: So, What is “Log Forensics”  Log analysis is trying to make sense of system and network logs  “Computer forensics is application of the scientific method to digital media in order to establish factual information for judicial review.” So….  Log Forensics = trying to make sense of system and network logs + in order to establish factual information for judicial review PAGE 13

Slide 14: How Logs Help… Sometimes If logs are there, we can try to  … figure out who, where, what, when, how, etc but  Who as a person or a system?  Is where spoofed?  When? In what time zone?  How? More like ‘how’d you think’…  What happened or what got recorded? PAGE 14

Slide 15: Conclusions  Turn ON Logging!!!  Make Sure Logs Are There When You Need Them (and need them you will )  Include Log Analysis into the IR process and training  Prepare and Learn the Analysis Tools  When Going Into the Incident-Induced Panic Think ‘Its All Logged Somewhere – We Just Need to Dig it Out’   Logs in Incident Response are critical for …  Threat detection: “Is there something wrong?”  Early incident triage: “What is going on?”  Detailed investigation: ‘What REALLY happened?”  Logs for Forensics  Logs can tell you things, but are they “good evidence”?  Logs become evidence only if precautions are taken PAGE 15

Slide 16: More information? Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA http://www.chuvakin.org Chief Logging Evangelist LogLogic, Inc Author of “Security Warrior” (O’Reilly 2004) See http://ww.info-secure.org for my papers, books, reviews and other security resources related to logs. See http://chuvakin.blogspot.com for my blog! PAGE 16