Essentials of Incident Response: 01. Preparation – Process

14 Jan Essentials of Incident Response: 01. Preparation – Process

This blog series has been updated here.

In this series on the Incident Response Process, I’m devoting at least one post to each of the steps in the PICERL (Preparation, Identification, Containment, Eradication, Remediation and Lessons Learned) method. Preparation is key to the others, so it merits 3 posts. The previous entry [1] covered the People aspect of preparation. This entry will address the Process aspect, and the next will address the Technology aspect.

Process – The role of policies and baselines.

Once the appropriate people are identified, the next question is “what do they do?” The answer to this question will vary based on the security maturity level [2] of the organization. We will cover some of the possibilities in future posts. From a preparation standpoint, however, the most important process question is “Once the team knows and is trained on what to do, how do they know when to do it?”.

The answer requires 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 likely results in lower quality response overall. Better to tackle the devil in the details by proactively creating a formal process for identifying what qualifies as an incident.

According to NIST [3], an event is “an observable occurrence in an information system or network.” 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, a cyber “incident” is defined as a disruptive occurrence, an event which is also “violation of computer security policies, acceptable use procedures, or standard security practices”. So in order to classify something as an incident, you must have policies and procedures which specify behavior which produces “normal” activity on the network.

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/potential incident represents an observation of something out of the ordinary. The only way to determine that a policy has been violated is the observation of anomalous behavior on the network. This means that the organization must know what is ordinary or “normal” for its environment. From the standpoint of preparation, this means that that you need to start with a baseline of activity measurements before making any changes, so you will know what constitutes normal for your environment.

Another way to characterize 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. This is something to be addressed as part of Step 6 – Lessons Learned.)

Once the team has determined that they are dealing with an incident, the next priority is steps 3-5 – containing, eradicating and remediating the incident. The particulars of those steps will depend on the nature of the incident — an organization may have different processes for malware infections (on servers or desktops), unauthorized access (of systems, or databases, in the case of medical records), denial of service attacks, theft or loss of equipment, violation of acceptable use policies, etc. We will cover those steps in future posts.


[2] This term refers to a model similar to the familiar Corporate Maturity Model. The Department of Homeland Security, in conjunction with the National Initiative for Cybersecurity Education, has published a useful document on the subject at Several groups have developed industry-specific guidance based on that document. I plan to cover security maturity in a future blog post.

[3] Cichonski, P., Millar, T., Grance, T., & Scarfone, K. (2012, August). Computer Security Incident Handling Guide. SP800-61 rev2 . US Dept of Commerce.

Copyright 2015, Ray Davidson and Syncurity Networks

No Comments