Computer forensics under regulations

1. 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

2. 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 HIPAA-
related computer forensics requirements and suggestions. Section 164.308 discusses
information system activity review requirements, including the implementation of

3. 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,

4. 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.