Search

FIRST 2006 Full-day Tutorial on Logs for Incident Response

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Notes on slide 1

    Source: http://www.sans.edu/resources/securitylab/loglogic_chuvakin.php

    Audit records is sometimes viewed as a specific kind of log, related to process controls. However, we will treat them as the same for clarity. Some people even manage to define the “event” (as “observable occurrence”), but the ideas is pretty self-explanatory: event is something that happened. We have less crazy marketing terms than the “intrusion prevention” crowd, but I figured I’d mention those explicitly so there is no confusion. Confusions reigns supreme… Also: events, alerts, logs, records, etc. “ Audit of monitoring logs”? “Monitoring of audit logs”? “Logging of monitoring audit?  Auditing – reviewing audit logs Message – some system indication that the event has transpired. Log or audit record – recorded message related to the event Log file – collection of the above records Logging – recording log records Alert – a message usually sent to notify an operator Device – a source of security-relevant logs etc

    I did mention security data, events, etc on the previous slides. But what am I really talking about? In other words, what do we LOG and MONITOR? What is called “security data” in this presentation consists of various audit records (left), generated by various devices and softwares (right). It should be noted that business applications also generate security data, such as by recording access decisions or generating messages indicative of exploitation attempts.

    Now, the above only covers system logs, not network or application-specific ones Does all of it has security relevance? You bet!

    Those are some of the common messages/log records/alerts

    Yes, specific will be covered later!

    Underlies the logging and monitoring. So, now that we know it’s a good idea, how do we go about centralizing the data? Here is the plan. The whole process starts from the initial data generation, collection, preliminary analysis and possible volume reduction, secure (against attacks and DoS attacks) and reliable transportation to the central point. It is then followed by further processing before storage (for real-time cross-environment analysis) and long term trend analysis. Visualization of data also helps in the analysis and may be separated as another step (both real-time and historical visualization may sometimes reveals new properties of the collected data). Note that I skipped obvious things, such as filtering. We have a plan, but does it really that simple to follow it? Challenges abound. Some of the above challenges are inherent, but others can be and are overcome by Security Information Management solutions. Too much data is the main data volume problem. Hundreds of firewalls (not uncommon for a large environment) and thousands of desktop security applications have a potential of generating millions of records every day. Not enough data might hinder the response process in case the essential data was not collected or is not being recorded by the application or a security device. Visibility of data. Like in yesterday snort example, SOC missed the internal stuff. Cross NAT and cross-proxy data analysis. Diverse records problem is due to the lack of the universal audit standard; most applications log in whatever formats developed by their creators, thus leading to the massive analysis challenge. False alarms are common for network intrusion detections systems (NIDS). Those might be false positives (benign triggers) and false alarms (malicious triggers with no potential of harming the target) Duplicate data is due to multiple devices recording the same event in their own different ways. Hard to get data problem is less common and might hinder analysis in case some legacy software or hardware is in use. For example, getting the detailed mainframe audit records may be a challenge. Chain of custody concerns refer to higher security and handling standards that need to be in use if the data might end up in the court of law. So, now that we know it’s a good idea, how do we go about centralizing the data? Here is the plan. The whole process starts from the initial data generation, collection, preliminary analysis and possible volume reduction, secure (against attacks and DoS attacks) and reliable transportation to the central point. It is then followed by further processing before storage (for real-time cross-environment analysis) and long term trend analysis. Visualization of data also helps in the analysis and may be separated as another step (both real-time and historical visualization may sometimes reveals new properties of the collected data). Note that I skipped obvious things, such as filtering.

    We have a plan, but does it really that simple to follow it? Challenges abound. Some of the above challenges are inherent, but others can be and are overcome by Security Information Management solutions. Too much data is the main data volume problem. Hundreds of firewalls (not uncommon for a large environment) and thousands of desktop security applications have a potential of generating millions of records every day. Not enough data might hinder the response process in case the essential data was not collected or is not being recorded by the application or a security device. Visibility of data. Like in yesterday snort example, SOC missed the internal stuff. Cross NAT and cross-proxy data analysis. Diverse records problem is due to the lack of the universal audit standard; most applications log in whatever formats developed by their creators, thus leading to the massive analysis challenge. False alarms are common for network intrusion detections systems (NIDS). Those might be false positives (benign triggers) and false alarms (malicious triggers with no potential of harming the target) Duplicate data is due to multiple devices recording the same event in their own different ways. Hard to get data problem is less common and might hinder analysis in case some legacy software or hardware is in use. For example, getting the detailed mainframe audit records may be a challenge. Chain of custody concerns refer to higher security and handling standards that need to be in use if the data might end up in the court of law. Also: Volume is getting even higher Audit data standards don’t exist Binary and text logs Undocumented formats Free form logs Same events described differently Different level of detail in collected data Now, how many folks only use one security device type and only from single vendor? Not many. Most companies have multiple types of devices from multiple vendors. And a weird mix it is! Now, we move away from homogenous data of one device type to multi-vendor diverse device data centralization, which brings lots of new challenges. Advantages of cross-device analysis will also be shown further in the presentation. Heterogeneous environment brings forth new problems and also boosts some of the old ones, familiar from single device centralization. For example, more peculiar file formats need to be understood and processed to get to the big picture. Volume just gets out of control, firewalls spew events, IDSs pitch in, etc. Horrendous, eh?

    How to plan a response strategy to activate when monitoring?

    You actually can log and not monitor. No slide set is valid w/o a compliance slide. “ Too much stuff out there – why even bother?”  Situational awareness What is going on? New threat discovery Unique perspective from combined logs Getting more value out of the network and security infrastructures Get more that you paid for! Extracting what is really actionable automatically Measuring security (metrics, trends, etc) Compliance and regulations

    Including spyware And other internal abuses

    One of the primary aims of a traditional forensic investigation is to reconstruct past events in an attempt to answer the ‘what happened’ question. To achieve this aim forensic investigators treat the scene as the witness examining the environment as a source of trace evidence (Chisum and Turvey, 2000). In principle a witness is potentially a useful source of evidence. The witness may be able to recount the sequence of events that took place thereby assisting the reconstruction of the scenario for the investigation. In the digital world where activity is conducted by processes, the ‘scene’ is the entire computing system including the processor, the memory, secondary storage devices, applications and so forth. Historically, investigators have typically studied storage devices like hard disks as they are usually the only source of preserved evidence. Although interactions among computing processes do not drop bodily properties akin to hair or blood, their interaction with and use of resources may leave traces that can be used to help reconstruct past events. In trying to ask ‘what happened’, computer forensic investigations tend to concentrate on the state of the filesystem including slackspace and virtual memory space for traces of deleted data or indications of the nature of programs previously run on the system (Yasinsac 2001). From a forensic point of view perhaps the most significant advantage of the computing scene over the real world scene is the computing system’s provision of an event log. The log is an ongoing record of events taking place in the operating system. In addition, since event logs are collected as part of the routine course of system operation they are generally considered ‘direct evidence’ and may be admissible in court (Casey 2000, p.46). At first the provision of a readily available history of computing activity appears to have the capacity to resolve the problem of reconstructing past events. However, the event logging mechanism of computing systems has proven to be largely unsuitable for forensic purposes and rarely used in litigation. Evidentially, the weight of the information contained in the event log does not readily conform to the requirements of a forensic investigation. In fact although the weighting criteria of the investigator’s evidence extraction process has been somewhat discussed (Sommer 1998), the weighting of the system’s own evidence extraction facility (event logs) has been relatively left unexplored in scientific research. SOMMER’S CRITERIA With the traditional forensic investigation process in mind we present Sommer’s criteria for the weighting of non-testimonial evidence. Sommer identifies three main attributes – authenticity, accuracy and completeness (Sommer, 1998 cites Miller, 1992): (1) Accurate: free from any reasonable doubt about the quality of procedures used to collect the material, analyse the material if that is appropriate and necessary and finally to introduce it into court – and produced by someone who can explain what has been done.. (2) Complete: tells within its own terms a complete story of particular set of circumstances or events (3) Authentic: specifically linked to the circumstances and persons alleged Sommer expands these attributes for more technical types of evidence and presents five main tests designed to assess the reliability of the evidence derived from digital environments (Sommer 1998). Sommer expands these attributes for more technical types of evidence and presents five main tests designed to assess the reliability of the evidence derived from digital environments (Sommer 1998). 1. Computer’s Correct Working Test Sommer argues that the computer must be shown to be behaving “correctly” or “normally”. In cases where the computer is acting simply as an information store then such a requirement may be easy to satisfy. However if the computer is providing a service such as a database query function and given the investigation is related to precisely that function then it must be tested and shown to be “correct” or “ normal”. 2. Provenance of Computer Source Test The evidence collected that is deemed relevant to the investigation must be proven to be taken from the specific computer and from nowhere else. 3. Content/Party Authentication Test The evidence collected must be relevant i.e. linked to the incident or parties accused in the investigation. 4. Evidence Acquisition Test: The information evidence must have been gathered accurately, must be free from contamination, and must be complete (note this refers back to the three main attributes of non-testimonial evidence). 5. Continuity of Evidence/Chain of Custody Test A full account of what happened to the retrieved evidence after it was extracted must be provided. Frequently, all of the individuals involved in the collection and transportation of evidence may be requested to testify in court. Thus, to avoid confusion and to retain complete control of the evidence at all times, the chain of custody should be kept to a minimum (Casey 2000 cites Saferstein, 1998, p 58)

    “• Log Forensics provides indexing and "Google-like" search algorithms for near-instant data retrieval, searching terabytes of data in seconds in order to find critical information for investigations and legal proceedings.” http://en.wikipedia.org/wiki/Computer_forensics Computer forensics is application of the scientific method to digital media in order to establish factual information for judicial review. This process often involves investigating computer systems to determine whether they are or have been used for illegal or unauthorized activities. Mostly, computer forensics experts investigate data storage devices, either fixed like hard disks or removable like compact disks and solid state devices . Computer forensics experts: Identify sources of documentary or other digital evidence Preserve the evidence Analyze the evidence Present the findings http://computer-forensics.safemode.org/ What is Computer Forensics? Computer forensics, sometimes known as Digital Forensics , is often described as "the preservation, recovery and analysis of information stored on computers or electronic media". It often embraces issues surrounding Digital Evidence with a significant legal perspective, and is sometimes viewed as a Four Step Process . http://en.wikipedia.org/wiki/Digital_evidence Digital evidence or electronic evidence is any probative information stored or transmitted in digital form that a party to a court case may use at trial .

    Challenges with log forensics…

    “ Computer Records and the Federal Rules of Evidence”, Orin S. Kerr, USA Bulletin, (March 2001) http://www.usdoj.gov/criminal/cybercrime/usamarch2001_4.htm Challenges to the authenticity of computer records often take one of three forms. First, parties may challenge the authenticity of both computer-generated and computer-stored records by questioning whether the records were altered, manipulated, or damaged after they were created. Second, parties may question the authenticity of computer-generated records by challenging the reliability of the computer program that generated the records. Third, parties may challenge the authenticity of computer-stored records by questioning the identity of their author. E.g. Computer records can be altered easily, and opposing parties often allege that computer records lack authenticity because they have been tampered with or changed after they were created. For example, in United States v. Whitaker , 127 F.3d 595, 602 (7th Cir. 1997), the government retrieved computer files from the computer of a narcotics dealer named Frost. The files from Frost's computer included detailed records of narcotics sales by three aliases: "Me" (Frost himself, presumably), "Gator" (the nickname of Frost's co-defendant Whitaker), and "Cruz" (the nickname of another dealer). After the government permitted Frost to help retrieve the evidence from his computer and declined to establish a formal chain of custody for the computer at trial, Whitaker argued that the files implicating him through his alias were not properly authenticated. Whitaker argued that "with a few rapid keystrokes, Frost could have easily added Whitaker's alias, 'Gator' to the printouts in order to finger Whitaker and to appear more helpful to the government." Id. at 602. The courts have responded with considerable skepticism to such unsupported claims that computer records have been altered. Absent specific evidence that tampering occurred, the mere possibility of tampering does not affect the authenticity of a computer record. See Whitaker , 127 F.3d at 602 (declining to disturb trial judge's ruling that computer records were admissible because allegation of tampering was "almost wild-eyed speculation . . . [without] evidence to support such a scenario"); United States v. Bonallo , 858 F.2d 1427, 1436 (9th Cir. 1988) ("The fact that it is possible to alter data contained in a computer is plainly insufficient to establish untrustworthiness."); United States v. Glasser , 773 F.2d 1553, 1559 (11th Cir. 1985) ("The existence of an air-tight security system [to prevent tampering] is not, however, a prerequisite to the admissibility of computer printouts. If such a prerequisite did exist, it would become virtually impossible to admit computer-generated records; the party opposing admission would have to show only that a better security system was feasible."). Id. at 559. This is consistent with the rule used to establish the authenticity of other evidence such as narcotics. See United States v. Allen , 106 F.3d 695, 700 (6th Cir. 1997) ("Merely raising the possibility of tampering is insufficient to render evidence inadmissible."). Absent specific evidence of tampering, allegations that computer records have been altered go to their weight, not their admissibility. See Bonallo , 858 F.2d at 1436.

    2 Favorites

    FIRST 2006 Full-day Tutorial on Logs for Incident Response - Presentation Transcript

    1. Logs in Incident Response Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA Director of Security Research LogLogic [email_address] Mitigating Risk. Automating Compliance.
    2. Who is Anton?
      • Dr. Anton Chuvakin [ formerly ] from LogLogic “is probably the number one authority on system logging in the world ”
      • SANS Institute (2008)
    3. Outline - I
      • Incident Response Process
      • Logs Overview
      • Logs Usage at Various Stages of the Response Process
      • How Log from Diverse Sources Help
    4. Outline - II
      • Log Review, Monitoring and Investigative processes
      • Standards and Regulation Affecting Logs and Incident Response
      • Incident Response vs Forensics
      • Case Studies
      • Log Analysis Mistakes
    5. Incident Response Methodologies: SANS
      • SANS Six-Step Process
        • Preparation
        • Identification
        • Containment
        • Eradication
        • Recovery
        • Follow-Up
    6. Incident Response Methodologies: NIST
      • NIST Incident Response 800-61
        • Preparation
        • Detection and Analysis
        • Containment , Eradication and Recovery
        • Post-incident Activity
    7. Other IH/IR Frameworks and Methodologies
      • Process from “Incident Response and Forensics”
      • Company-specific Policies and Procedures
      • etc
    8. Why Have a Process?
      • It helps…
        • Predictability
        • Efficiency
        • Auditability
        • Constant Improvement
      • It shrinks…
        • Indecision
        • Uncertainty
        • Panic! 
    9. From Incident Response to Logs
      • From Incident Response to Logs
    10. Terms and Definitions
      • Message – some system indication that an event has transpired
      • Log or audit record – recorded message related to the event
      • Log file – collection of the above records
      • Alert – a message usually sent to notify an operator
      • Device – a source of security-relevant logs
      • Logging
      • Auditing
      • Monitoring
      • Event reporting
      • Log analysis
      • Alerting
    11. Log Data Overview
      • Audit logs
      • Transaction logs
      • Intrusion logs
      • Connection logs
      • System performance records
      • User activity logs
      • Various alerts
      • Firewalls/intrusion prevention
      • Routers/switches
      • Intrusion detection
      • Hosts
      • Business applications
      • Anti-virus
      • VPNs
      What data? From Where?
    12. What Commonly “Gets Logged”?
      • System or software startup, shutdown, restart, and abnormal termination (crash)
      • Various thresholds being exceeded or reaching dangerous levels such as disk space full, memory exhausted, or processor load too high
      • Hardware health messages that the system can troubleshoot or at least detect and log
      • User access to the system such as remote (telnet, ssh, etc.) and local login, network access (FTP) initiated to and from the system, failed and successful
      • User access privilege changes such as the su command—both failed and successful
      • User credentials and access right changes , such as account updates, creation, and deletion—both failed and successful
      • System configuration changes and software updates—both failed and successful
      • Access to system logs for modification, deletion, and maybe even reading
    13. “ Standard” Messages 10/09/200317:42:57,146.127.94.13,48352,146.127.97.14,909,,,accept,tcp,,,,909,146.127.93.29,,0,,4,3,,' 9Oct2003 17:42:57,accept,labcpngfp3,inbound,eth2c0,0,VPN-1 & FireWall-1,product=VPN-1 & FireWall-1[db_tag={0DE0E532-EEA0-11D7-BDFC-927F5D1DECEC};mgmt= labcpngfp3;date=1064415722;policy_name= Standard],labdragon,48352,146.127.97.14,909, tcp,146.127.93.145,',eth2c0,inbound Oct 9 16:29:49 [146.127.94.4] Oct 09 2003 16:44:50: %PIX-6-302013: Built outbound TCP connection 2245701 for outside:146.127.98.67/1487 (146.127.98.67/1487) to inside:146.127.94.13/42562 (146.127.93.145/42562) PIX 2003-10-20|15:25:52|dragonapp-nids|TCP-SCAN|146.127.94.10|146.127.94.13|0|0|X|------S-|0|total=484,min=1,max=1024,up=246,down=237,flags=------S-,Oct20-15:25:34,Oct20-15:25:52| Oct 20 15:35:08 labsnort snort: [1:1421:2] SNMP AgentX/tcp request [Classification: Attempted Information Leak] [Priority: 2]: {TCP} 146.127.94.10:43355 -> 146.127.94.13:705 SENSORDATAID="138715" SENSORNAME="146.127.94.23:network_sensor_1" ALERTID="QPQVIOAJKBNC6OONK6FTNLLESZ" LOCALTIMEZONEOFFSET="14400" ALERTNAME="pcAnywhere_Probe“ ALERTDATETIME="2003-10-20 19:35:21.0" SRCADDRESSNAME="146.127.94.10" SOURCEPORT="42444" INTRUDERPORT="42444" DESTADDRESSNAME="146.127.94.13" VICTIMPORT="5631" ALERTCOUNT="1" ALERTPRIORITY="3" PRODUCTID="3" PROTOCOLID="6" REASON="RSTsent"
    14. Example 1 FTP Hack Case
      • Server stops
      • Found ‘rm-ed’ by the attacker
      • What logs do we have?
      • Forensics on an image to undelete logs
      • Client FTP logs reveals…
      • Firewall confirms!
    15. Using Logs at Preparation Stage
      • Verify Controls
      • Ongoing Monitoring
      • Change Management Support
      • “ If you know the cards, you’d live on an island” 
      • In general, verifying that you have control over your environment
    16. Using Logs at Identification Stage
      • Detect Intrusion, Infections and Attacks
      • Observe Attack Attempts, Recon and Suspicious Activity
      • Perform Trend Analysis and Baselining for Anomaly Detection
      • Mine the Logs for Hidden Patterns, Indicating Incidents in the Making…
      • “ What is Out There?”
    17. Using Logs at Containment Stage
      • Quickly Assess Impact of the Infection, Compromise, Intrusion, etc
      • Correlate Logs to Know What You Can [Still] Trust
      • Verify that Containment Measures Are Working
      • “ What Else is Hit?”
    18. Using Logs at Eradication Stage
      • Preserving the Log Evidence from Previous Stages
      • Confirming that Backups are Safe (Using Logs, How Else?)
      • “ Is it Gone?
    19. Using Logs at Recovery Stage
      • Increased Post-Incident Monitoring
      • Watch for Recurrence
      • Watch for Related Incidents Elsewhere
      • “ Better Safe than Sorry”
    20. Using Logs at Follow-Up Stage
      • Train Analysts, Responders and Administrators
      • Create Management Reports ( Don’t You Love Those!  )
      • Verify and Audit Newly Implemented Controls
    21. So, What Logs are Useful for Incident Response?
      • Security Logs vs “Non-Security” Logs
      • Witness confusion in the NIST guide on log management ….
      • Let’s quickly go through various logs and see how they help (and helped in specific cases!)
    22. 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!)
    23. NIDS Logs in Incident Response
      • Attack, Intrusion and Compromise Detection
      • Malware Detection: Worms, Viruses, Spyware, etc
      • Network Abuses and Policy Violations
      • Unauthorized Access and Access Attempts
      • Recon Activity
      • [NIPS] Blocked Attacks
    24. Server Logs in Incident Response
      • Confirmed Access by an Intruder
      • Service Crashes and Restarts
      • Reboots
      • Password, Trust and Other Account Changes
      • System Configuration Changes
      • A World of Other Things 
    25. Database Logs in Incident Response
      • Database and Schema Modifications
      • Data and Object Modifications
      • User and Privileged User Access
      • Failed User Access
      • Failures, Crashes and Restarts
    26. Proxy Logs in Incident Response
      • Internet Access
      • Malware: Spyware, Trojans, etc
    27. Client Logs in Incident Response
      • FTP Client: Remote Connections and File Transfers
      • Other client software: usually no logs, but usually leave other traces
        • E.g. web browser cache
    28. Antivirus Logs in Incident Response
      • Virus Detection and Clean-up (or lack thereof!)
      • Failed and Successful Antivirus Signature Updates
      • Other Protection Failures
      • Antivirus Software Crashes and Terminations
    29. “ Back to the Process” 
      • Main idea…
      • Log everything
      • Audit little
      • Monitor a bit
      • During the incident you’d be grateful you did!
    30. Log Management Process
      • Collect the log data
      • Convert to a common format
      • Reduce in size, if possible
      • Transport securely to a central location
      • Process in real-time
      • Alert on when needed
      • Store securely
      • Report on trends
    31. Log Management Challenges
      • Not enough data
      • Too much data
      • Diverse records
      • Time out of sync
      • False records
      • Duplicate data
      • Hard to get data
      • Chain of custody issues
    32. Monitoring or Ignoring Logs Before the Incident?
      • How to plan a response strategy to activate when monitoring logs?
      • Where to start?
      • How to tune it?
    33. Monitoring Strategy
    34. Value of Logging and Monitoring
      • Monitoring
      • Incident detection
      • Loss prevention
      • Compliance
      • Logging
      • Audit
      • Forensics
      • Incident response
      • Compliance
      • Analysis and Mining
      • Deeper insight
      • Internal attacks
      • Fault prediction
    35. “ Real-Time” Tasks
      • Malware outbreaks
      • Convincing and reliable intrusion evidence
      • Serious internal network abuse
      • Loss of service on critical assets
    36. Daily Tasks
      • Unauthorized configuration changes
      • Disruption in other services
      • Intrusion evidence
      • Suspicious login failures
      • Minor malware activity
      • Activity summary
    37. Weekly Tasks
      • Review inside and perimeter log trends and activities
      • Account creation/removal
      • Other host and network device changes
      • Less critical attack and probe summary
    38. Monthly Tasks
      • Review long-term network and perimeter trends
      • Minor policy violation summary
      • Incident team performance measurements
      • Security technology performance measurements
    39. Logs and Laws, Rules, Standards, Frameworks
      • Logs and Laws, Rules, Standards, Frameworks
    40. Logs in Support of Compliance
      • Application and asset risk measurement
      • Data collection and storage to satisfy auditing of controls requirements
      • Support for security metrics
      • Industry best-practices for incident management and reporting
      • Proof of security due diligence
      • Example regulation include: HI PAA , SOX, GLBA, FISMA …
    41. Regulations Recommend Log Management
      • ISO 17799
      • Maintain audit logs for system access and use, changes, faults, corrections, capacity demands
      • Review the results of monitoring activities regularly
      • Ensure the accuracy of the logs
      • NIST 800-53
      • Capture audit records
      • Regularly review audit records for unusual activity and violations
      • Automatically process audit records
      • Protect audit information from unauthorized deletion
      • Retain audit logs
      • PCI
      • Requirement 10
      • Logging and user activities tracking are critical
      • Automate and secure audit trails for event reconstruction
      • Review logs daily
      • Retain audit trail history for at least one year
      • CobiT 4
      • Provide adequate audit trail for root-cause analysis
      • Use logging and monitoring to detect unusual or abnormal activities
      • Regularly review access, privileges, changes
      • Monitor performance
      • Verify backup completion
    42. COBIT 4.0 is Leading IT Controls Framework
      • (Re-)released in Dec 2005
      • Four (4) Goals for IT
        • Align IT with business
        • Maximize IT benefits
        • Use IT assets responsibly
        • Manage IT risks
      • 34 IT Processes
      • Most used framework for SOX compliance
    43. Log Data Evidences COBIT 4.0 Controls Identity and Access DS5.3 Identity management DS5.3 User account management PO7.8 Job change and termination User Activity PO4.11 Segregation of duties AI2.3 Application control and audit ability Change AI6.1 Change standards and procedures DS9.3 Configuration integrity review Security DS5.2 IT security plan DS5.5 Security testing, surveillance, monitoring DS5.10 Network security DS11.6 Security requirements for data mgmt
      • IT Infrastructure
      DS1.5 Monitoring of service level agreements DS2.4 Supplier performance monitoring DS3.5 Monitoring of performance and capacity DS13.3 IT infrastructure monitoring DS10.2 Problem tracking and resolution Business Continuity DS4.1 IT continuity framework DS4.5 Testing of the IT continuity plan DS11.5 Backup and restoration
    44. Compliance Drives New Controls SOX GLBA HIP AA Patriot Commercial Diversified Ins - Mutual Ins - Stock Savings Securities PCI 1386/1950 Basel 2 Financial Services Services Pharma Biotech Healthcare Energy Govt Telco Retail F&B F1000 21CFR/Annex EU/DPD Japan Privacy COBIT FFIEC NIST ISO17799 General
    45. Logs and Forensics
      • What Makes Your Investigation a “Forensic” Investigation?
      • Incident Response vs Forensics
      • … and is the ‘vs’ really appropriate?
    46. Forensics Brief
      • “ Computer forensics is application of the scientific method to digital media in order to establish factual information for judicial review. This process often involves investigating computer systems to determine whether they are or have been used for illegal or unauthorized activities (Wikipedia)”
    47. 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
    48. 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?
    49. Logs Forensics Challenges
      • What? You think this is evidence? Bua-ha-ha-ha 
      • “ Computer Records and the Federal Rules of Evidence “
      • “ First , parties may challenge the authenticity of both computer-generated and computer-stored records by questioning whether the records were altered, manipulated, or damaged after they were created.
      • Second , parties may question the authenticity of computer-generated records by challenging the reliability of the computer program that generated the records.
      • Third , parties may challenge the authenticity of computer-stored records by questioning the identity of their author.”
    50. Example 2 Scan of the Month Challenge #34
      • Honeypot hacked
      • All logs available
      • In fact, too many 
      • Analysis process
    51. Example 3 Sysadmin Gone Bad
      • Service Restarts Out of Maintenance Windows
      • Correlated with Some Personnel Departures
      • Information Leaks Start
      • Log Analysis Reveals Unauthorized Software Installation
    52. Example 4 Spyware Galore!
      • System Seen Scanning – Firewall Logs
      • Analysis of Logs Shows Antivirus Failures
      • VPN Logs Help Track the Truth
      • Full Forensic Investigation Confirms the Results of Log Analysis
    53. Example 5 Compromise Detection
      • Miscellaneous Examples of Detecting Compromised Machines Using Logs
    54. Anton’s Five Log Mistakes
      • How many have you committed? 
      • Not looking at logs
      • Not retaining long enough
      • Not normalizing logs
      • Not prioritizing actions on logs
      • Only looking at known bad
    55. Conclusion
      • Turn ON Logging!!!
      • Make Sure Logs Are There When You Need Them (and need them you will  )
      • Include Log Analysis into the IH Process
      • Avoid Above (and Other) Mistakes
      • 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’ 
    56. More information?
      • Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA
      • anton@chuvakin.org
      • Chief Logging Evangelist
      • LogLogic, Inc
      • Author of “Security Warrior” (O’Reilly 2004), “PCI Compliance” (Elsevier, 2009) and other security books
      • Blog: www.securitywarrior.org
      • See www.info-secure.org for my papers, books, reviews and other security resources related to logs
    57. Thank You Q & A

    + Anton ChuvakinAnton Chuvakin, 1 month ago

    custom

    393 views, 2 favs, 1 embeds more stats

    Outline:
    Incident Response Process
    Logs Overview
    Lo more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 393
      • 364 on SlideShare
      • 29 from embeds
    • Comments 0
    • Favorites 2
    • Downloads 0
    Most viewed embeds
    • 29 views on http://chuvakin.blogspot.com

    more

    All embeds
    • 29 views on http://chuvakin.blogspot.com

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories

    Tags

    -->
    Search
    RSS Feed
    What's new?

    © 2009 SlideShare Inc. All Rights Reserved