Responding to a Customer's Security Incidents, Part 4: Processing Incident Data
- Processing Security Incident Data—A Monumental Task
- Authenticating the Incident Data
- Preserving the Incident Data
- Analyzing the Incident Data
- Article Series
- References and Links
- Third-Party URLs
- Acknowledgments
- About the Author
- Ordering Sun Documents
- Accessing Sun Documentation Online
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
During or after an incident, collecting, processing, and developing evidence for law enforcement or for internal use is one definite goal for any security incident response team. Even if you choose not to report the incident, processing the incident data contributes to learning from the incident and preventing future incidents. In addition, one of the many encouraging aspects of the worldwide incident response community has been its willingness to share technical ideas and information from similar or past incidents among teams and individuals. This information, if stored and processed diligently, can be extremely helpful in possible future incidents.
The first three articles in this series discussed establishing a computer security incident response team (CSIRT) and policy, executing the policy, and following up after an incident, which included acquiring incident data. This fourth article focuses on authenticating, preserving, and analyzing the incident data. Here, only the salient points for best practices that should be executed in processing the incident data are discussed. These practices are typically preceded by a recovery phase and are only starting points for a more detailed analysis for building a policy with the associated processes and procedures. The scope of best practices described in this article is limited to computer and network systems data that is related to security incidents.
Security Incident Response (SIR) is the combination of resulting processes and actions an organization takes in responding to a security incident. It should be obvious that each and every security incident response program will contain unique elements that exist and make sense only for that organization.
Before you read this article, you should be familiar with the concepts described in the first three articles. This article is intended for computer security managers, security policy developers, system administrators, and other related staff, who are responsible for the creation or operation of a computer security incident response policy and service.
Processing Security Incident Data—A Monumental Task
A massive amount of information is gathered by the incident response teams. It could be collected from incident triage; interviews; conversations with the affected people; electronic discovery process; if the analysis is conducted by legal means; and various kinds of analysis of computer networks and systems at the constituent's site. Tools for entering, accessing, and tracking information and events can greatly facilitate, and at least partially automate, data manipulation and searches. Such tools can support the staff of any organization and its VCSIRTs in helping to establish, for example, the identification of the following:
New events such as incidents and service requests (for example, from constituents or other CSIRTs)
Current events that are tracked separately, but might have some relationship to the incident at hand, and ongoing corroborations between them, as deemed necessary
Information directly related to current events (for example, captured images of the compromised systems or a set back in the litigation process)
Information directly related to a previously closed event or to an incident that is similar to the current one (such as, a rootkit found on the compromised system)
How to gather, store, and retrieve all of this information is a topic of research by itself and will not be covered in this article. However, at this point, you should know that in addition to the tools that help in performing the types of tasks listed above, it is expected that a servicing organization should promote the use of de facto standards, such as incident tracking numbers, standard reporting forms, and preregistration of needed contacts, for incident processing by the VCSIRTs that the servicing organization deploys. In addition, it is important to work in harmony with the external CSIRTs (national or international) so that the standards used for incident data processing by a VCSIRT are in tune with those of the other response teams. For example, to track incidents, both the CERT/CC (http://www.cert.org) and the DFN-CERT (http://www.cert.dfn.de/) response teams allocate integer numbers within an agreed upon integer range.