In my day job, we often discuss security tools and the respective processes that generate the requirements that demand the use of such tools. Lately, we have been debating incident response tools and processes as contrasted with forensic investigation tools and processes. Obviously, both have differing benefits that they bring to the general discipline of security. They also have differing requirements in terms of the tool sets that they require to execute those processes.
To me, the boundaries between forensic investigation and incident response have always been rather clear. Maybe slightly fuzzy at the exact interface between them, but not a huge gaping canyon of a zone of uncertainty. However, lately, I'm starting to believe that out there in the rest of the community it may not be so clear. I could be wrong...it wouldn't be the first time and I'm sure it won't be the last, especially if you ask some of my close friends.
Job One: Classification
We all know that in the trade of security, the chain of action begins with a security event.
Security Event - "A[n] occurrence in a system that is relevant to the security of the system. (See: security incident.)" [RFC2828] - (ref: http://www.terena.org/activities/tf-csirt/iodef/docs/i-taxonomy_terms.html#Appendix.)Ok, simple enough. Something happened. Is it good, is it bad, or is it somewhere in between? Let's think of this in terms of the kinds of things that a fire department might have to handle. An event might be someone in the back yard that got a bit over-zealous with the charcoal and has their grilled meat flaming and smoking enough to cause concern at the neighbor's house. They might roll out there and take a look, but they certainly aren't going to hose down the drumsticks and the grill with a 3-inch line just because the person likes their grilled meat cooked to a crisp.
Well, that leads us to the next thing. Within the field of incident response, if the event is benign, it is ignored or discounted or simply noted as looked at and dismissed. If it is bad, it get's reclassified as a security incident.
Security Incident - "Any adverse event whereby some aspect of computer security could be threatened: loss of data confidentiality, disruption of data or system integrity, or disruption or denial of availability [NIST-800-3]
Proposition made by Internet Security Glossary [RFC 2828]:
(I) A security event that involves a security violation. (See: CERT, GRIP, security event, security intrusion, security violation.)
(C) In other words, a security-relevant system event in which the system's security policy is disobeyed or otherwise breached. (ref: http://www.terena.org/activities/tf-csirt/iodef/docs/i-taxonomy_terms.html#Appendix.)
Look for Signs of Arson After the Fire is Out
To me, an incident is something that you need to act upon, in some capacity, right now. Let's say instead of a smoking backyard grill we have a house on fire. This is something the local fire department will not only have to roll out and take a look at but will need to take some action and do what they do. Put the fire out and keep the loss of property (and life) to an absolute minimum. In computer terms, this incident response can vary quite a bit from stopping compromised processes, to shutting down the system, to re-imaging back to baseline. Certainly that list isn't exhaustive, but this is remedial info anyway, right? I know you are saying: "Yes....we get this point...do you have a real point?" If you've read this far, stick with me a bit more, it's coming.
Next we have forensic investigations. Security incidents that are really bad and force you to ask questions regarding motive and look at aspects of possible criminality or collusive or intentional behavior become forensic investigations. An investigation requires that you invoke a different level of discipline. In our example of a house fire, this is where the guys with special training come in after the fire is out and look for causes of the fire. Important to note that I said 'after the fire,' because it is all too obvious that you wouldn't be doing such activity while the building is still on fire, as it would be too dangerous.
So it breaks down like this: There are lots of security events. Some security events become incidents. Some security incidents become investigations.
Graphically, it looks something like this:
Malware Analysis: Incident Response or Forensic Investigation?
Yeah, yeah, I know...common knowledge. Here's my point. What about malware analysis (et. al.)? Is it incident response or forensic investigation? Clearly it is on the border or very near the border between incident and investigation.
Here's my argument...if you look at the nature of the discipline that you are using for the task, it becomes a bit more obvious which it is. If you are working on an incident and it involves malware being found on the system, you are going to invoke the discipline of the forensic investigator and not the incident responder. You are no longer putting out the fire, but investigating the cause of the fire. You are not fixing or repairing or mitigating, you are analyzing how to get better or become less susceptible. Within standard incident response methodology, this is a part of or comes after the post-incident analysis phase of your response/investigation. Classically, in a drill or live situation, this is where you extract lessons learned and perform assessment of your response activities. What went well? Where could your response team improve? Where did our defenses fail? Are there any improvements that are required to increase the effectiveness of our security posture?
Trying to determine what makes the malware tick or why it was able to evade your defenses is using the same exacting skill set that forensic investigations uses and likely some of the same tools. With that in mind, I would offer that post-incident analyis happens AFTER the incident is over. After the fire is out. Now, of course, we all know that you could find such a piece of malware somewhere in the middle of the incident and still be putting out fires on a particularly wide-spread incident, but that doesn't mean that the analysis of the malware is part of the incident response and mitigation process, itself. You still are not responding, you are analyzing. Your local policies may dictate that the incident cannot be officially closed until the post-incident analysis, or post-mortem review [i hate that term], is complete, but that doesn't mean such reviews are part of the incident response. Different skill sets used for different activities. Different objectives of the activities.
In conclusion I would simply like to offer that incident response is primarily concerned with stopping whatever bad thing is going on. Forensic investigation or post-incident analysis is concerned with the 'why' in why it happened and supporting evidence (facts) to prove culpability or negligence. When in doubt, look to the logical discipline that you are invoking to know if a particular activity is on one side or the other of the line between incident response or forensic investigation. That will let you know which tools in your kit are best suited to the task.