Since we are going to be learning in future blog posts the specifics of Digital Forensics & Incident Response (DFIR), we first need to establish a foundation of basic knowledge from which we will build upon. The easiest way I know how to do that (without writing an entire book) is to define the common terminologies in use and provide additional context as necessary. (If you are looking for a good book on DFIR I would highly recommend this one: [I have no affiliation with the owner/author/seller] Incident Response & Computer Foresnics.)
What is DFIR?
DFIR (pronounced: “dē-’fər”) stands for Digital Forensics & Incident Response.
Digital Forensics & Incident Response is a sub-specialty of Cyber-security that deals with identifying, investigating, and restoring from a security related incident or compromise on a computer network.
In my experience, typical DFIR teams are usually composed of various key members of the larger business model (IT department, Security Operations Center, Forensic Examiners/Analysts, Legal Department, C-Suite representatives, Human Resources, etc.) The DFIR team can be either full-time or part-time depending on the size and needs of the business.
What is digital forensics?
According to NIST, digital forensics is defined as, “In its strictest connotation, the application of computer science and investigative procedures involving the examination of digital evidence - following proper search authority, chain of custody, validation with mathematics, use of validated tools, repeatability, reporting, and possibly expert testimony.”
What is “Incident Response”?
According to the Incident Response & Computer Forensics Third Edition, “Incident Response is a coordinated and structured approach to go from incident detection to resolution.”
Incident Response is a set of processes and procedures used to detect, identify, analyze, and remediate security incidents.
The next few definitions come from “RFC’s.” RFC’s are documents that have been reviewed, approved, and published by the Internet Engineering Task Force (IETF) and are the de facto manual for regards to policy, protocol, and technical documentation.
What is a “Security Incident”?
Defined in RFC 4949 as, “A security event that involves a security violation.”
What is a “Security Intrusion”?
Also defined in RFC 4949 as, “A security event, or a combination of multiple security events, that constitutes a security incident in which an intruder gains, or attempts to gain, access to a system or system resource without having authorization to do so.”
For the sake of simplicity, we will consider a security incident and a security intrusion as one and the same. That is, bad or potentially bad activity that was detected in the environment and warrants further investigation by properly trained individuals in accordance with the current best practices and procedures.
What is digital evidence?
Digital evidence is data that is stored or transmitted digitally and may be relied upon in a court of law or other legal proceeding.
What standards govern the collection of digital evidence?
Specifically, RFC 3227, is the document that deals with the collection of digital evidence and the order of volatility. See RFC 3227 - Guidelines for Evidence Collection and Archiving”.
Please take the time to read RFC 3227 as this will be a foundational reference for all of our future work.
Before we begin with learning how to collect digital evidence we first need to talk about “scope.” Scoping is a very selective process by which we narrow our investigation to the most important evidence to be collected and analyzed first. We want to narrow our focus to only those system(s) with the highest probability of collecting the evidence we need in our incident. Initial reporting of an incident or suspected incident usually occurs in one of two ways:
Information provided to the DFIR team from monitoring practices:
System Event Logs
Network Logs
Alerts from Intrusion Detection Systems or Intrusion Prevention Systems (IDS and/or IPS)
Alerts from Endpoint Monitoring Tools
Alerts from Antivirus/Malware software scanners.
Threat Hunting teams working to identify malicious activity on the network
Information reported by humans:
Calls or complaints to the Help Desk from employees
Calls or complaints to the Help Desk from customers
Tips from Law Enforcement
Security researchers reporting through responsible disclosure.
Common Vulnerabilities and Exposures (CVE’s)
Armed with the above information and conducting additional interviews of the parties involved will help guide us to the most important system(s) that we need to focus on first. During the analysis of these initial system(s), the evidence may lead us to additional systems that will need to be collected. This process of being selective with our initial collection process is necessary to keep us from being overwhelmed with data and falling victim to “analysis paralysis.” During the scoping process we need to ask very specific questions that answer the important “Who, What, When, Where, and Why” questions.
Who are the parties involved?
What happened? Specifically, what happened or what was observed?
When did this occur or when was it first observed? Date and Time matters.
Where are the systems located? (Local/On-site? Another location? Cloud based?)
Why? The least important question but still relevant to try and figure out.
Some other special considerations that you need to keep in mind are: What is the legal authority? Search Warrant; Consent; Legal or HR authorization? You need to document the legal authority and understand what you can and cannot do. If your examination takes you into a new or unexpected direction not covered by your original search authority, make sure you stop the examination, document this full stop, and consult with Legal/HR/Case Agent for guidance on how to proceed.
One really important step that should never be overlooked or ignored in the field of digital forensics is documentation. Documentation is absolutely *KEY* to be able to troubleshoot and find the important answers in your examination. Specifically, notes that are in chronological order of step 1, step 2, step 3, etc., will help you to see where you have been, what tools you have used, and the results you arrived at. It will help you to remember where you left off in a case after a long weekend or holiday. It helps you to retrace your steps when you venture off down a deep rabbit hole of some obscure artifact you thought may turn out to be related. This will also help you to troubleshoot your case and provide context to your investigative process when undergoing an internal peer review process, to cross examination, and everything in between. Case notes can and will help you become a better forensic examiner. I don’t care how you keep your notes - handwritten in a journal, a simple text document inside of Microsoft’s notepad, an Excel spreadsheet, whatever works for you. Be consistent and intentional with documenting as much as you can. Finally, detailed documentation will help you with your report writing. (You do know that you have to write a report right? Tool generated reports don’t count. If you want to do quality forensic work you need to learn to write quality reports.)
Coming up in the next blog post:
How to properly acquire Digital Evidence:
Forensic Triage of Windows based systems and the forensic tools and software needed to do the job:
Belkasoft Live RAM Capturer
Magnet RAM Capture
KAPE Forensic Triage
FTK Imager
We will then learn how to process the triage collection with some of these tools:
Autopsy
Eric Zimmerman’s suite of tools
KAPE
And others…
Spoiler Alert - I am in the process of writing a python program that will allow an examiner or analyst to keep a forensic notes log from the command line terminal complete with the ability to take screenshots to help document the forensic process along the way. Stay tuned to the blog for more details. Please, leave a comment below and share this post with others in your network.
No comments:
Post a Comment