The third in a five-part series, this article focuses on following up after an incident and presents the best practices that should be executed in the follow-up phase. These topics include acquiring incident data, resorting to legal actions when deemed necessary, and conducting post-incident activities such as taking inventory of the affected assets, assessing the damage, and capturing the lessons learned. This article is intended for advanced readers such as 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.

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.