Responding to Customer's Security Incidents--Part 3: Following Up After an Incident
- Understanding Key Points of the Follow-Up Phase
- Acquiring the Evidence
- Authenticating, Preserving, and Analyzing Incident Data
- Conducting Post-Incident Activities
- Using Legal, Investigative, and Government Recourses
- Article Series
- References
- 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
The pressure of working and reacting in Internet time and protecting organizational or personal assets is constantly mounting on all of us. Adversaries are getting more sophisticated as the Internet is maturing. Both Nimda and CodeRed are recent examples of the advanced nature of threats combining software vulnerabilities and spreading of multiple vectors of infection. Security incidents have become widespread and difficult to contain in some situations. Yet, globally, enterprises working with various private and public security organizations, investigative agencies, IT vendors, governments, and academia must keep abreast of current incidents, plan for future incidents, cooperate in a concerted effort, and respond to incidents effectively.
The first article in this series discussed establishing a computer security incident response team (CSIRT) and a security policy. The second article discussed executing the policy. 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 third article, you should be familiar with the concepts described in the first two articles.
This third article focuses on following up after an incident. In this article, only the salient topics for best practices that can be executed in the follow-up phase are presented. These topics include acquiring incident data, resorting to legal actions when deemed necessary, and post-incident activities, such as taking inventory of the affected assets, assessing the damage, and capturing the lessons learned. The best practices presented in this article are generally 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.
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.
Understanding Key Points of the Follow-Up Phase
Why is follow-up so important to have an article dedicated to it? The follow-up, to a large extent, provides the closure on the incident by analyzing it, taking action against the cause of the incident, recording it in detail, and learning from it to improve the processes and procedures that are in place for the organization. Some unexpected or unusual questions might come up:
If the incident information was received sooner, would the outcome be different?
What would the staff do differently next time?
Did management (at the customer site or at the organization providing the service) prove to be part of the problem and/or part of the solution? If yes, how?
On the other hand, a simple people communication issue might surface in the follow-up phase. For instance, a few years ago, in response to a local incident, a European CSIRT contacted the U.S. National level CSIRT (CERT/CC) before contacting its own national CSIRT. This was a procedural or execution-level lapse due to miscommunication among the teams in the same country. In another instance, at the U.S. federally funded agency, CIAC (http://www.ciac.org/ctac/), failures were reported in noting telephone numbers and email addresses of those who reported an incident. This procedural gap was spotted and fixed in the follow-up phase meeting.
Social Sciences
From a broad perspective, the integration of social sciences into incident response is critical for forming, applying, and reusing the skills of a CSIRT. The human aspects of social sciences can make or break a case. They involve the victims, the workers at the affected customer's site, the executives, and the perpetrator(s).
Take, for example, insider attacks, which are not uncommon. There are three important aspects that a CSIRT and the geo-based security officer must remember about these attacks:
Everyone at the site is a suspect because the perpetrator is still part of the affected customer's enterprise.
An insider attack could cause stress to many employees.
The way the incident is processed will reflect on the reputation of the CSIRT and its parent organization and enterprise.
Peripheral Aspects
During the follow-up phase, several peripheral aspects that are beyond the security incident itself need attention. The investigators employed by the worldwide security team for an incident being handled by a virtual CSIRT (VCSIRT) must consider the possible media exposure, the customer's state of behavior, and reaction to the incident. In addition, attention must be paid to the visibility of the case within law enforcement, the interaction with external attorneys, such as those from the district attorney's office, and the interaction with the suspect's attorney. Lastly, the political aspects of the incident, particularly if it is a high-visibility case, cannot be ignored.
Documentation
Throughout the security incident response (SIR) follow-up phase, the responsible geo-based security officer must ensure that the answers to the following are properly captured in a document: what, when, who, why, and how. The documentation should include a chronology of events that can form a basis for prosecution, if needed, a postmortem analysis, and a lessons learned document so that security policies can be improved. The geo-based security officer should maintain this critical information for possible future use.
Incident Classes
Security incidents do not fall into a single, expected pattern. However, the analysis of an incident must address the scope of the incident very clearly. There are two general classes of incident analysis to consider:
Intra-incident analysis
Inter-incident analysis
The most common types of intra-incident analyses involve a specific incident. For instance, the analysis might involve items such as log files, artifacts left by the intruder (such as rootkits), software environments, and web-of-trust (that is, which person trusts which person, and which component trusts which component in a customer's infrastructure within an incident).
Inter-incident analysis involves relationships between incidents. This is aimed at finding symmetries between separate incidents that might indicate equivalent or related sources of intruder activity. For example, in the same week, if there are multiple attacks on the sites of an organization, it makes sense for the investigating VCSIRT to correlate log data from firewall and intrusion detection systems (IDSs) at these sites and to search for similarities between security events. A series of log entries qualifying as an event might contain several attack patterns.
Evidence
One general meaning of evidence that applies to security incident response is testimony—facts in support of something. The legal meaning that is more applicable in the context of this article is information given personally or drawn from documents, tending to establish fact. This explains what is required of the incident data if it needs to be used in a court of law. Without a doubt, security incident data that is gathered as evidence can make or break a case if a customer wants to prosecute the perpetrator. Note that there are options to prosecution. Throughout the investigation, vigilant collection of circumstantial evidence and use of a chain of custody is important. The evidence might be needed in a grand jury hearing or a trial, but remember that the definition of permissible evidence is not the same in every country.
Chain of Custody
The chain of custody is accomplished by having verifiable documentation indicating the sequence of individuals who have handled a piece of evidence and the sequence of locations where it was stored (including dates and times). For a proven chain of custody to occur, the evidence must be accounted for at all times, and the passage of evidence from one party to the next must be fully documented. If your organization has policy for preserving and proving chain of custody, ensure that your actions are in keeping with this policy. In reality, the concept of chain of custody in the context of a crime is well-known to law enforcement personnel, but not to field engineers or administrators of a VCSIRT or a servicing organization at the customer site. In addition, country-level laws differ for the handling of evidence. Thus, training of the legal implications of custody of the evidence collected during an incident must be provided to the worldwide security team. The aim of a carefully crafted chain of custody is not only to protect the evidence, but also to make it difficult for a defense attorney to find a weakness in the custody process.
Scope
FIGURE 1 shows the scope of activities during the follow-up phase. The acquisition, authentication, preservation, analysis, response plan determination, and post-incident activities occur in almost every case. Legal and investigative activities occur only in specific cases. The VCSIRTs or security officers involved should determine the need for legal and investigative activities, based on the requirements of the customer affected by the incident.
)
FIGURE 1 Follow
Up Activities
The following sections highlight the salient points of the various activities of the follow-up phase, as shown in FIGURE 1.