Computer forensics in the age of compliance

Breaking down the process for FISMA, PCI and HIPAA

In previous articles, I've discussed log management and incident response in the age of compliance. It's time to cover a separate topic that has connections to both log analysis and incident management, but is different enough to justify its own article: digital forensics.

Digital forensics is the process of using the scientific method to examine digital media in order to establish facts for legal purposes, especially judicial review. It involves the systematic inspection of IT systems, especially data-storage devices, for evidence of a civil wrongdoing 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 "," you might assume that John Smith is responsible for that traffic. That deduction might be good enough for an informal investigation, but it will certainly not be sufficient in court.

Not just about hard drives

A common 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, including network gear, desktops and servers, mobile devices, and databases.

Review of data produced by these IT components can, for example, 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, what, where, when and how of user and system activities.

(Of course, using logging for forensic ends assumes that the log data itself is immutable and that its confidentiality, integrity and availability are protected. If not, who is to say that the time stamp is truthful or that 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've previously discussed to see 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. In addition, 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 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 data-preservation techniques. For example, forensic analysis that requires queries of logs across many systems might be significantly slowed by the chosen storage medium.

The Health Insurance Portability and Accountability Act of 1996 (HIPAA)

NIST SP 800-66, An Introductory Resource Guide for Implementing the HIPAA Security Rule, details 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.

Like FISMA, HIPAA discusses the importance of secure auditing and logging activity so that there are records in the event of an investigation. Rule 800-66 also mandates the development and deployment of specific incident-response measures, which are necessary (even though often not sufficient) to ensure 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").

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 user activity are clear in the case an event must be investigated. Also, PCI requirements 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 regulations 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.

* * * * * * * *

Previous " the age of compliance" articles:

Anton Chuvakin, GCIA, GCIH, GCFA is a recognized security expert and book author. His current role is chief logging evangelist at LogLogic, a log management and intelligence company. He is an author of Security Warrior and a contributor to Know Your Enemy II, Information Security Management Handbook, Hacker's Challenge 3 and PCI Compliance. Chuvakin also published numerous papers on a broad range of security and logging subjects and has several blogs.

Copyright © 2007 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon