Computer Forensics In The Age Of Compliance

Computer Forensics in the Age of Compliance Dr. Anton Chuvakin WRITTEN: 2007 DISCLAIMER: Security is a rapidly changing field of human endeavor. Threats we face literally change every day; moreover, many security professionals consider the rate of change to be accelerating. On top of that, to be able to stay in touch with such ever-changing reality, one has to evolve with the space as well. Thus, even though I hope that this document will be useful for to my readers, please keep in mind that is was possibly written years ago. Also, keep in mind that some of the URL might have gone 404, please Google around.

In previous articles, I have discussed log management and incident response in the age of compliance. Now, it is time to cover a separate topic that has connections to both log analysis and incident response, but is different enough to justify its own paper: digital forensics. Wikipedia defined “digital forensics” as the application of the scientific method to digital media in order to establish factual information for judicial review. It involves the systematic inspection of IT systems (especially data storage devices) for evidence of a civil wrong or criminal act. Because of its focus on “facts” and “scientific method,” computer forensics processes must adhere to courtroom standards of admissible evidence, which severely complicates some of the otherwise simple data analysis tasks, such as looking at logs to determine who connected to the system. Thus, forensic investigation of computer evidence is different from a routine review of logs and system data, which often produces “hunch-quality data” and not facts. For example, if you see a source IP address that resolves to “jsmith.example.com,” you might assume that John Smith is responsible here. It might be good enough for an informal investigation, but will certainly not be sufficient in court. A well-known example of a computer forensic investigation is a search for child pornography, during which an investigator removes a hard drive from a computer, loads the disk into a forensics tool, and reviews the contents to find illegal image files that a user is hiding or thought he had deleted. However, digital forensics has a broader reach than this case, and electronic evidence can be collected from a variety of sources, such as network gear, desktops and servers, mobile devices, databases, etc. For example, review of data produced by these IT components can show investigators of a data breach whether company employees have accessed confidential data, what steps they took to obtain the

data and what they did with it. This is where the link between log data and computer forensics becomes most obvious – logs become the first place to look during the investigation. Even though sometimes seen as difficult to analyze, logs are still easier to obtain and review than full disk contents. If logs are generated, they can help to figure out the who’s, what’s, where’s, when’s, and how’s of user and system activities. Of course, using logging for forensic ends assumes that the log data itself is immutable and its C-I-A (confidentiality, integrity and availability) are protected; if not, who is to say that the timestamp is truthful or crucial information about the sequence of events hasn’t been altered, injected or removed? Having control over forensics processes from data gathering to “chain of custody” protection is seen as key by many of the compliance mandates. Thus, we are brought back to the three regulations we have discussed all along to take a look at what they say about computer forensics. Much of the regulatory discussion of computer forensics links back to log management and incident response, because the two concepts are inexorably linked to digital forensics. The Federal Information Security Management Act of 2002 (FISMA) Tying incident response to forensic analysis, NIST 800-53 Recommended Security Controls for Federal Information Systems, requires that federal organizations generate and retain immutable audit records that are sufficient to support after-the-fact investigations of security incidents. This document also describes the need to automate mechanisms to integrate audit monitoring, analysis, and reporting into an overall process for investigation of and response to suspicious activities. Further establishing the link between incident response and computer forensics, 800-53 requires the organization to provide an incident response support resource to offer assistance, including access to forensics services in the handling and reporting of security incidents. Additionally, network forensic analysis tools are described as a way to guarantee intrusion detection and system monitoring capabilities. Thus, even though it is implied that forensics will be performed by the outside consultants, evidence data collection and preservation activities, compatible with the forensic use of such data, are mandated. NIST SP 800-92, Guide to Computer Security Log Management, describes the need for inalterable log generation, review, protection, and management for performing forensic analysis. The guide describes the need of organizations to keep digital forensics in mind when setting log storage requirements and designing a log management infrastructure due to the potential impact of log data preservation techniques; for example, forensic analysis that requires queries of logs across many systems might be significantly slowed by the chosen log storage media. The Health Insurance Portability and Accountability Act of 1996 HIPAA NIST SP 800-66, An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule, details HIPAArelated computer forensics requirements and suggestions. Section 164.308 discusses information system activity review requirements, including the implementation of

procedures to regularly review records of activity such as audit logs, access reports, and security incident tracking. It provides a variety of questions to consider including whether the audit trail can support after-the-fact forensic investigations. Additionally, like FISMA, HIPAA discusses the importance of secure auditing and logging activity so that there are records in event of an investigation. 800-66 also mandates the development and deployment of specific incident response measures, which are necessary (even though often not sufficient!) to assure that the evidence data will end up being useful for extracting “factual information.” Payment Card Industry Data Security Standard (PCI DSS) PCI DSS, which applies to organizations that handle credit card transactions, does not directly address forensic requirements for evidence collection and analysis or forensic processes. Still, it mandates that all service providers with access to cardholder data enable processes to provide for timely forensic investigation in the event of a compromise to any hosted merchant or service provider in Appendix A, Requirement A.1 (“Hosting providers protect cardholder data environment”). Additionally, Requirement 10 (“Track and monitor all access to network resources and cardholder data”) describes a variety of log- and audit-related activities to ensure that trails of authorized and unauthorized user activity are clear in the case that an event must be investigated. Also, PCI requirement for log data protection, such as cryptographic hashing, clearly have forensic use of log data in mind. The above review of regulations shows that recent compliance mandates do keep forensics needs in mind. Specifically, they govern taking steps to preserve forensic quality of data as well as to establish incident response and forensics programs. The key distinction to keep in mind is that the forensics aims to establish facts and not just “good enough” conclusions from data. And as has been the case with log analysis, incident response, and intrusion detection, the goal of the forensics language in these mandates is to ensure yet another facet of regulatory compliance and IT security. ABOUT THE AUTHOR: This is an updated author bio, added to the paper at the time of reposting in 2009. Dr. Anton Chuvakin (http://www.chuvakin.org) is a recognized security expert in the field of log management and PCI DSS compliance. He is an author of books "Security Warrior" and "PCI Compliance" and a contributor to "Know Your Enemy II", "Information Security Management Handbook" and others. Anton has published dozens of papers on log management, correlation, data analysis, PCI DSS, security management (see list www.info-secure.org) . His blog http://www.securitywarrior.org is one of the most popular in the industry. In addition, Anton teaches classes and presents at many security conferences across the world; he recently addressed audiences in United States, UK,

Singapore, Spain, Russia and other countries. He works on emerging security standards and serves on the advisory boards of several security start-ups. Currently, Anton is developing his security consulting practice, focusing on logging and PCI DSS compliance for security vendors and Fortune 500 organizations. Dr. Anton Chuvakin was formerly a Director of PCI Compliance Solutions at Qualys. Previously, Anton worked at LogLogic as a Chief Logging Evangelist, tasked with educating the world about the importance of logging for security, compliance and operations. Before LogLogic, Anton was employed by a security vendor in a strategic product management role. Anton earned his Ph.D. degree from Stony Brook University.