FIRST 2006 Full-day Tutorial on Logs for Incident Response
•
9 j'aime•1,621 vues
Outline: Incident Response Process Logs Overview Logs Usage at Various Stages of the Response Process How Log from Diverse Sources Help Log Review, Monitoring and Investigative processes Standards and Regulation Affecting Logs and Incident Response Incident Response vs Forensics Case Studies Log Analysis Mistakes
![Logs in Incident Response Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA Chief Logging Evangelist LogLogic [email_address] Mitigating Risk. Automating Compliance.](https://image.slidesharecdn.com/first2006presologsincidentpublic-091006011213-phpapp01/85/FIRST-2006-Full-day-Tutorial-on-Logs-for-Incident-Response-1-320.jpg)
![Who is Anton? ,[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à FIRST 2006 Full-day Tutorial on Logs for Incident Response
Similaire à FIRST 2006 Full-day Tutorial on Logs for Incident Response (20)
Plus de Anton Chuvakin
Plus de Anton Chuvakin (20)
Dernier
Dernier (20)
FIRST 2006 Full-day Tutorial on Logs for Incident Response
- 1. Logs in Incident Response Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA Chief Logging Evangelist LogLogic [email_address] Mitigating Risk. Automating Compliance.
- 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"
- 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
- 57. Thank You Q & A
Notes de l'éditeur
- 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.