Last updated at Wed, 13 Dec 2017 19:02:36 GMT
Synopsis
We are starting series of blog posts: “Incident Response Life Cycle in NIST and ISO standards”. In this series we will review incident response life cycle, as defined and described in NIST and ISO standards related to incident management.
In the first post in this series, we introduce these standards and discuss NIST’s approach to incident response team.
Introduction
NIST and ISO standards are excellent tools that can help organize and manage security incident management in any organization.
If you have any doubts as to how to approach this complex area, just grab a related NIST or ISO document of your choice and you will know how to get started or how to improve what you already have.
These standards or recommendations can be applied to small, medium and large organizations, their language is easy to understand and the recommendations they give are clear.
NIST and ISO standards on incident handling – overview
As for NIST (National Institute of Standards and Technology, an entity of U.S. Department of Commerce), its main publication on information security incident management is NIST Special Publication (SP) 800-61, “Computer Security Incident Handling Guide”. It is classified as “recommendation”. It was last revised in 2012, so it’s still quite fresh and well applicable to current IT and security environments.
As for ISO (International Standards Organization), its main publication on information security incident management is international standard ISO/IEC 27035, “Information security incident management”. Initially it was published as ISO/IEC TR 18044. I had a pleasure of acting as a first project editor of ISO/IEC TR 18044 at ISO/IEC JTC1 SC 27 (Subcommittee 27) for this standard back in year 2000 (yes, ISO was already thinking of structured incident management standard 17 years ago). At the time we prepared table of contents of ISO/IEC 18044 for further work, nobody was even dreaming that security automation would be that advanced. The ISO/IEC 18044 evolved strongly during these years. It joined so called 27000 group of standards (of which main one is ISO/IEC 27001) and it was first published as ISO/IEC 27035 in 2011 and then revised, split into three parts and revision was published in 2016.
We will concentrate on NIST SP 800-61 first and then we’ll move on to ISO/IEC 27035.
Legal requirements – and this is not the fine print 🙂
It is worth noting that FISMA (Federal Information Security Management Act) requires that all civilian federal agencies must create and maintain proper incident management capabilities. They must also report incidents to US-CERT (United States Computer Emergency Readiness Team), which is a part of Department of Homeland Security (DHS). NIST SP 800-61 can directly be used to comply with FISMA. There are also other legal requirements related to incident reporting, e.g. of incidents related to PII (Personally Identifiable Information). We recommend you study all these requirements carefully, consult your legal department and precisely align your incident response policies and procedures with these legal requirements.
Incident response team structure
Before we start discussing the NIST SP 800-61 incident response life cycle (which will happen in next blog posts in this series), let’s have a short look at what the NIST document tells us about incident response team structure.
Considerations on incident response team structure are an important part of NIST SP 800-61. The NIST document mentions three team models:
- central team;
- distributed teams;
- coordinating team.
Main decision factors here will be organization size and geographical spread.
Factors to consider when building incident response team
NIST SP 800-61 gives clear hints as to what factors should be taken into consideration when choosing team model (besides organization size and geographical spread):
- 24/7 availability;
- full-time vs part-time;
- on-site vs outsourced;
- stress level related to incident response work;
- staff cost;
- staff expertise.
These are all very important factors, stress factor often being forgotten and/or neglected.
Let’s look how three of these factors relate to security automation:
- by using security incident processing automation, stress level of incident handling can be lowered – many processing tasks can be automated and relayed to IT systems and tools, lowering amount of human activity and human decision needed;
- staff cost can also be significantly reduced by appropriately planned usage of security incident processing automation – to achieve this, consider each SOP (standard operating procedure) that is used in incident management in your organization, analyze it in detail and ask yourself this question: “can this SOP be executed without human interaction?” (with proper tools, many of incident management SOPs can be fully automated, without human presence or human decision);
- security automation can also be a “substitute” for staff expertise – initial analysis can be relayed to automated processes, where human expertise is substituted for software capabilities and knowledge bases usage (this can even be more effective than human activities, because we humans are more prone to errors and biases).
If you build your incident response team from the scratch (e.g. in a newly formed company), you have excellent opportunity to utilize security automation to the maximum, by aligning the human team and its SOPs with available security automation tools. (And if you build your incident response team and its procedures/tools from the scratch you also have unique opportunity to become compliant with NIST SP 800-61 without the need to change any existing procedures.)
If you already have incident response team and think about optimizing its performance (or about aligning its work with the NIST recommendation), carefully consider all team building factors given in NIST document.
As it is stressed by NIST, incident handling is a complex task. That’s why and that’s were properly used security automation can help.
(In next articles in these series, we will be discussing four phases of NIST SP 800-61 incident response life cycle.)
References and further reading
NIST Special Publication (SP) 800-61 – Computer Security Incident Handling Guide