The Role of Preparation and Process in Incident Response

Let’s start at the beginning. The first aspect of the preparation phase is identifying and assigning roles and responsibilities. This will depend on various factors, such as the severity of the incident, the details of the environment, and tools you have available.

Once the appropriate people are identified, the next question is “What do they do?” Or more specifically, “Once the team knows and is trained on what to do, how do they know when to do it?” The answer to this question will vary based on the security maturity level of your organization.

You can begin answering this question by identifying which of the hundreds, or even thousands, of daily security events should be classified as incidents and deserve further attention. Most organizations have not addressed this question explicitly, and approach their followup on an ad hoc basis—depending on the resources and expertise available. While that approach is workable for a while, it doesn’t provide consistent information for review and improvement and will likely result in lower quality response overall. It is better to tackle the devil in the details by creating a formal process for identifying incidents proactively.

What qualifies as an incident?

According to the National Institute of Standards and Technology (NIST), a security event is “any observable occurrence in a network or information system.” Clearly then, the closer you observe your network, and the more sensitive your instrumentation, the more events you will observe or detect. These can range in severity from firewall pings to phishing attempts to exfiltration of data. And depending on your experience and the presence or absence of compensating controls, many of the events can probably be safely ignored. On the other hand, NIST defines a cyber “incident” as a disruptive occurrence and an event which is also in “violation of security policies, security procedures, or acceptable use policies.”

The NIST approach reflects a programmatic management focus. The incident in question represents a violation of standards, whether by an internal or external actor, and the response is dictated by the standard which has been violated. However, from a security analyst’s view, an event or potential incident represents an observation of something out of the ordinary, or anomalous behavior, on the network. Before you can classify something as an incident, you need to start with a baseline of activity measurements, so you know what constitutes normal. From the standpoint of preparation, you must have policies and procedures which specify “normal” activity on your network.

A further way to identify events and incidents is to ask some key questions about the event:

1. Does the event indicate a violation of law or applicable regulation such as PCI/DSS, HIPAA, FERPA, etc.? Are there regulations which require public notification as a result of the event?
2. Does the event indicate a violation of corporate policy? And what is the consequence specified in the policy?
3. Does the event reflect a violation of corporate values and/or ethics? (If you answer yes to 3 but not 2, consider whether there should be a policy in place).

Incident response preparation is challenging, but by formalizing the process on how to identify an incident, you’ll be that much better prepared for the response: containing, eradicating and remediating the incident.

*Adapted from an existing Syncurity blog post.