Forensic Data: How to Acquire and Retain Vital Evidence

This article was originally published in the InfoSec Survival Guide: Orange Book — Incident Response. Read it free online HERE, or grab it on the Spearphish General Store (free digital download or a $1.25 physical copy, your call). | While "digital forensics" and "incident response" often appear together (as in the acronym "DFIR"), they represent two distinct disciplines. What's in a Name? The American Heritage Dictionary defines forensics as "The use of science and technology to investigate and establish facts in criminal or civil courts of law." Contrast this with IBM's definition of incident response: "Incident response [...] refers to an organization's processes and technologies for detecting and responding to cyberthreats, security breaches or cyberattacks." Note the absence of any reference to legal proceedings—it simply describes the process by which an organization detects, halts, and recovers from an incident. Legal Considerations Although most incidents never end up in court, all should be treated as if they might. Taking the proper steps before, during, and after response ensures that any data collected can be admissible as evidence. It's important to know the rules of evidence for relevant jurisdictions. Global corporations should consider each jurisdiction they have locations in when developing standard operating procedures (SOPs). Always include legal counsel when developing your organization's SOPs. Data Preservation A common rule for digital evidence is the retention of data in its "original state." This is accomplished by using validated hardware and software to create an exact bit-for-bit copy of a piece of digital media. Yet during incident response, it is rare that full forensic images are created—typically, only a small subset of data is collected from victim devices for analysis. Before any action is taken, consult legal advisors to decide whether to collect full forensic images. A good practice is to create a folder for the original data, generate and document a hash of its contents, and then create a working copy in a separate folder. Only perform analysis on the working copies of your data to preserve the integrity of the original data. Documentation Documentation is critical when handling potential evidence. A chain of custody (CoC) records details about what the data is, where it came from, who collected it, whom it was transferred to, a brief description of what was done to it, and so forth. The National Institute of Standards and Technology (NIST) provides a sample CoC here: https://www.nist.gov/document/sample-chain-custody-formdocx Each person working with the data must keep detailed notes: record dates, times, and any actions taken. Binary files often need to be parsed by special tools to make their data human-readable—include any tool names and versions. The same should be done with human-readable data, such as text-based log files. While you likely don't need to document the version of Excel used to read a log file, if you added a column to show UTC date/time stamps in local time, that is worth noting. The gold standard for documentation is this: notes should be detailed enough that someone with a similar background can recreate your steps and produce the same results. This is the scientific method part of digital forensics. Processes need to be repeatable and generate the same results. Tool Validation Procedures Before an incident occurs, verify that your hardware and software are working. Test write blockers to ensure they do not alter the evidentiary media. Validate that your forensic software functions correctly (it's not unheard of for new versions to report the wrong date/time stamps when parsing binary data). While there is no set standard for validation processes, some guidelines exist to help you develop validation SOPs. Validation SOPs guidelines: NIST: https://www.dhs.gov/science-and-technology/nist-cftt-reports SWGDE: http://cet4861.pbworks.com/w/file/fetch/120024474/4861.2014-09-05_SWGDE_Recommended_Guidelines_for_Validation_Testing_V2-0.pdf Additional Considerations for Incident Handling When managing incidents, also consider: - What are the data retention policies of your Endpoint Detection and Response (EDR) tools? - How is your cloud data preserved? - Who has access to sensitive or personal data? These factors often depend on your license agreement with providers. Make sure data can be maintained in a secure, long-term manner, as it can take years until an incident makes it into the courtroom. Implement processes to export incident data from systems and services while preserving integrity and meeting long-term storage requirements that protect its availability and confidentiality. Access to confidential information must always be managed carefully. Remember: Involve your legal team, validate your tools, work from copies (never original data), document everything meticulously, and maintain chain of custody. Explore the Infosec Survival Guide and more… for FREE! Get instant access to every issue of the Infosec Survival Guide, as well as our self-published infosec zine PROMPT#, and exclusive Darknet Diaries comics — all available at no cost.