I can call this standard as «CISO Time!» As far as
computer security incidents are corncerned enough companies act in a
reactive way. We have an incident, let's do something to reduce damage.
Sometimes they thought how to patch vulnerabilities, which leads to some
kind of remediation. And then wait for another incident.
Also there is another way to deal with incidents — proactive way. In
this standard you can find some useful steps how to implement incident
response activities in company's every day life. Almost all
recommendations are obvious, but they are placed together. If you are
going to write incident response plan, you can follow instructions in
this standard and you'll get sufficient plan.
Standard consists of 3 parts. First part is devoted to organizing a
Computer Incident Response (CIR) Capability. In this chapter you can
find useful information about policy and plan elements, also with
obvious advantages of developing CIR plan. Some pages describe how to
effectively communicate within organization and what departments should
participate in incident response activities.
Second chapter was about how to handle an Incident. This activity
consists of 4 steps: Preparation → Detection and Analysis → Containment,
Eradiction, Recovery → Post-Incident Activity.
As far as preparation step is is concerned I can't but mention 3 main activities:
- get all necessary contacts from people with whom you are going to work while CIR;
- all incident analysis hardware and software should be up to date and easy to use;
- incident analysis resources are also important, because using them you have all information about infrastructure in one place.
Detection and analysis is one of the most important part of the plan.
First of all, you should determine attack vectors, indicators and
profile activity in your infrastructure. When you understand normal
behaviour and create correlation and log retention policies you will be
able to prioritize incidents. It is better to make such decision with
colleagues and top-manager, such as CISO. Generally, you can try to
divide incidents by functional or informational impact and
recoverability, but every company can find their own criteria about how
to prioritize incidents.
Containment
and eradication also as a recovery can be much different because of your
organization internal policies. Containment depends on many factors as
impact on SLA, potential damage and so on. Eradiction should be
carefully done, because of possible information lost. Effectiveness on
this step is fully depends on how good detection analysis was performed.
Almost all recovery procedures are held by IT staff. It is their part.
Post-Incident Activities include lesson learned meetings after
incident. On this meetings your CIR team should update CIR policies and
procedures, create chronology and monetary estimate of the amount of
damage. Based on this lessons you can justify fundings, help your IA
department to find incident trends and systemic security weaknesses.
Also measures of success can be renewed. It is always important to
understand when incident is localized and eliminated.
In this chapter you can find CIR handling checklist. It is very brief,
but also helpful to start from. The last part is devoted to coordination
and information sharing. It is also a good start to from your list whom
to call and what to say. Special attention in this standard is paid to
granular information sharing because of business impact. It is better to
speak with law and PR departments before presenting information to some
unauthorized people.
In conclusion, I
would like to say that this standard is not a full guide about CIR. It
is only a brief review. Almost every topic should be expanded with
different technical and administrative measures. But if you don't know
where to start or even you know — it is a good review to check your key
positions. Great job, NIST!
