Steps of Incident Response tutorial
I've noticed quite a few recent posts in the forums inquiring about incident response or forensic investigatory techniques.
Since I have a (small) bit of experience working incident responses, and have had the pleasure of taking graduate-level courses in the subject, I thought I'd whip up a quick overview of the steps involved to help those interested in the topic.
Anyway, I'll paste the tutorial in here and attach a .rtf as well. Note: I cited a reference which served to help correctly order some of my thoughts. A few very loose paraphrases are inevitable, but no material was taken straight from the source. I also don't consider the source to be the best or end-all-be-all in the field...but it was on my bookshelf :)
Enjoy!
The Six Steps of Incident Response
Author: <0
Date: 03/02/2004
Sources: Mandia, K., Pepe, M, & Prosise, C.. (2003). Incident Response & Computer Forensics. Emeryville, CA. McGraw-Hill Companies.
Make no mistake- incident response is a process. This process is comprised of well-defined methodologies, which when followed by an investigator, ensure that accurate and simple conclusions are reached at each stage of the overall, governing process. Meaning, the objective of each component is to develop solid and non-subjective reasoning for any subsequent action the investigator may take or suggest be taken. The goal of this article then is to describe the six components or sub-methodologies of incident response: detection of incidents, initial response, and formulation of response strategies, investigation of the incident, reporting, and finally resolution. It should be noted that the 'pre-incident preparation' component is assumed in this article as we are conceding that any and all pre-incident response preparatory work has already been completed.
Naturally, in order to respond to an incident one must first detect that an incident is occurring or has occurred. Firewalls, intrusion detection systems, server event logs, software error trapping, and end-user feedback, are all valid and common sources of incident detection. Furthermore, irrespective of the vector through which the incident detection is reported, a fundamental detail that can not be overlooked is the value of documenting the facts regarding the suspected incident. Here, as the authors of the text point out, checklists are of enormous value. Checklists allow a quick and efficient means of recording facts such as time/date, system(s) involved in the suspected incident, who first reported the incident and their pertinent contact information. The collection of these items permits an investigator, once alerted to the situation, to quickly ascertain whether an incident has truly been discovered, is currently occurring, or if the suspicious activity is actually benign.
Initial response, the second component of the incident response process, can be summarily defined as an effort to collect enough objective data in order to determine what further response is most apropos. As well, it is important to note that this phase is tightly linked to the first in that it usually does not involve interaction with the affected system(s). Rather, the initial response component confines the investigator to interviewing personnel who may have insight into the particulars of the reported incident. For example, an investigator may refer to network diagrams/topology maps to determine the scope of the incident or may interview personnel such as end-users of the affected system(s) or administrators to gain insight into details and/or context of the incident. The importance of this component, of gathering the objective data from sources such as those outlined above, is that it permits the investigator to accurately make a decision as to whether an incident has occurred, is occurring, or if the reported activity is benign. And, if it there is an incident, the above data will enable the investigator to properly decide the best course of further action.
Formulation of an appropriate response is then the third component. Here caution is warranted; factors beyond the technical scope and gathered data from above must be considered when determining what the most correct response strategy is to any given incident. Examples of these factors include technical resources, overall business goals, and/or political climate. Truly, it is the holistic combination of circumstances which should determine the response posture undertaken, not any one single component. Additionally, any possible response should be evaluated vis-Ă*-vis weight of answers to questions such as estimated dollar loss, downtime in scope of the system(s) and user(s), existence of legal obligations to disclose the incident, or even possible results of disclosure on the organization’s public image. Yet, there are a finite amount of responses and therefore a finite amount of actions that can be taken when an incident is identified. Legal actions could be undertaken, termination of employment if internal employees are discovered to be involved, or coordination with outside providers/partners to thwart and attack, are all examples of possible actions. Concurrently, and especially if legal proceedings are deemed appropriate, it is vital that the investigator collect evidence.
Component four, or investigating the incident, involves collecting evidence from a variety of sources and then (forensically) analyzing the data collected. Here, the investigator will employ live response techniques to comb volatile data for evidence before power is severed, in-depth techniques such as forensic duplication to examine non-volatile data after powering down the victim system(s), or even a full-live response which involves gathering all relevant data from a system without cutting the power feed. Specific information that an investigator should target for collection includes (but is not limited to) time/date stamps of the system and affected files, network connections, interface states, and what applications are running. As well, network device logs can be gathered to correlate details or assist in the evidentiary process. Secondly, the evidence must be reviewed and analyzed. This second phase of the investigation can be better explained as a rebuilding process whereby the above collected evidence is reviewed in a more in-depth manner to establish objective, interrelated facts pertaining to the incident. Throughout this component though, it is vital to maintain that the investigator maintain the integrity of the evidence collected. Careful attention should be paid to the sound practice of forensic technique and the chain of custody of said evidence. Additionally, as mentioned previously, the importance of detailed documentation cannot be stressed enough.
Generating reports is indeed a critical component of the incident response process and should not be underestimated in terms of value. The reports that the investigator produces in response to an incident need not be extravagant; they should instead convey the facts of the incident in a concise, clear, and easily digestible format. This is crucial as the incident response reports are used not only by the investigator him/herself but also will be reviewed by senior management, fellow colleagues, and subjected to dissection during any legal proceedings. Two immensely helpful tactics to be employed by the investigator are to document the facts during the incident response process rather than attempting to recall them after-the-fact and also to employ a standard format (similar in intent but not structure to the checklist mentioned early in this article). These habits will facilitate accurate and succinct reporting which then prepares the investigator to make recommendations for resolving the incident.
Resolution, in the context of the sixth component of incident response, should not be confused with the earlier phase of response formulation. The two are distinct, different components. This is true because resolution involves examining the incident after objective data has been collected and taking steps to: a.) curtain the incident from expanding in scope, b.) solving the incident, and finally c.) identifying and implementing countermeasures to ensure the incident does not repeat. These three steps will certainly involve technical safeguards in regards to both individual hosts and networks but also will involve updating/creating relevant policies and procedures. Moreover, resolution is not something that the investigator will necessarily develop rapidly and/or haphazardly. Hasty deployment could hide or destroy vital incident evidence and actually facilitate further incidents. Therefore, the wise investigator will allow any resolutions to undergo a review and consideration process to ensure the resolution is inline with business objective, with the scope of the incident itself, and also inline with policies and procedures.
Again, incident response is a whole which is defined by distinct, individual subparts. It is by adhering to these subparts, these methodologies that the investigator will be able to determine if an incident is taking place, how to respond appropriately, investigate the incident and take action, create concise reports of what occurred, and then offer lasting, cost-effective resolutions. Deviation from these components is an invitation for disaster as the amount of data being processed is enormous and possibility of mistakes may prevent the objective collection of evidence. The investigator must at all times keep the goal of the incident response process in foreground of his/her mind; unerring and swift detection, containment, analysis, and resolution of computer-related incidents.
