Last updated at Wed, 13 Dec 2017 19:53:48 GMT
In the series of articles titled “Incident Response Life Cycle in NIST and ISO standards” we review incident response life cycle, as defined and described in NIST and ISO standards related to incident management.
We introduced these standards in the first article in this series.
In previous article in this series we introduced the incident response life cycle as described in NIST Special Publication (SP) 800-61.
In this article we are discussing the first phase of this cycle – preparation phase.
Why preparation is very important
Preparation phase is very important. Proper preparation:
- allows for quicker and more effective incident handling;
- lowers probability of an incident occurring (incident prevention).
Let’s discuss incident prevention first.
Although it is normally not the responsibility of incident response team to secure systems and data to prevent incidents from occurring, this team can and should play an important role in incident prevention.
Let’s follow NIST’s document and divide incident prevention activities into two streams:
- incident prevention directly related to incident handling;
- incident prevention resulting from risk management and security activities.
Incident prevention directly related to incident handling
As we already noted, NIST recommendation states that output from “Post-incident activity” phase should become an input for “Preparation” phase.
It may sound counter-intuitive, because “Post-incident activity” phase is a “future” phase in relation to “Preparation” phase. But we can’t think of incident handling as linear activity. And also, there will be only one situation in which we will not have any data from “Post-incident” activity phase – this is the situation in which the incident handling team will be before handling its first incident. Starting from that moment, there will always be data (at least there always should be data) to use in “Preparation” phase – and these data will be very helpful to directly prevent incidents from occurring or to lower the probability of occurrence.
For example, if an incident resulted from a USB drive attached to a computer (e.g. malware infection), the “Post-incident activity” phase of handling such incident should result a.o. in recommendations on controlling and/or limiting USB drives usage. This can be done by limiting USB ports usage by hardware (configuration) or software means and/or forcing encryption of USB drives. Such recommendation should make its way into “Preparation” phase, and, if implemented correctly will definitely directly lower probability of occurrence of incidents related to USB drives.
As noted above, it will most probably not be the responsibility of incident handling team to implement these security measures, but the incident handling team role in advising the security/IT team is critical.
Incident prevention resulting from risk management and security activities
We all know that the more secure our systems are, it is less probable an incident will occur.
As NIST SP 800-61 states, more incidents mean not only possible direct negative business impact, but also this might lead to problems in proper incident handling, due to inability of incident handling team to properly handle incident flood.
Securing the information processing systems is out of scope of activities of incident handling team. However, it is important to note that such activities are important part of incident handling preparation phase.
NIST recommendation lists and comments shortly on three main “technical areas” of security of IT systems:
- host security;
- network security;
- malware prevention.
It also recommends further NIST publications to be read on these subjects.
An equally important, non-technical area of activities improving incident prevention is user awareness and training. This group of tasks also does not belong to incident handling team. However, similarly to IT security tasks, incident handling team can and should provide ideas and input for user training and awareness activities.
For example, if unencrypted USB drives are still allowed, it is critical that all users are regularly made aware of high security risk of using them outside the organization and that all users are trained in secure methods of using USB drives. The need to increase frequency and/or strength of such trainings might come from higher number of incidents related to USB drives. It is the incident handling team that should pass such need to training department.
What we would like to emphasize the most from this section of NIST SP 800-61 is risk assessment. No technical security measures should be implemented without proper risk assessment that aligns appropriate security measures with high risk areas. Sometimes an organization might not have resources to conduct full-scale risk assessment. In such cases, simplified approach can be used. NIST recommendation lists further NIST publications on this subject. Again here we should apply cyclic approach: risk assessment – security measures – monitoring – risk assessment. Risk assessment and management alone is a wide ranging subject. As for incident prevention, we recommend you remember that risk assessment is a key part of it.
Preparing for quicker and more effective incident handling
The knowledge and experience of incident handling team members are not enough for effective incident handling.
To be effective, the incident handling team needs:
- tools and
Preparing the incident handling tools
NIST SP 800-61 divides the incident handling tools into:
- communications and facilities;
- incident analysis hardware and software;
- incident analysis resources;
- incident mitigation software.
Each of these groups of tools is described and examples are given in NIST recommendation.
If you are organizing your incident handling team, this section of NIST SP 800-61 is an excellent place to learn how to quickly equip your team.
Preparing the incident handling procedures
It is critical for successful incident handling that the team works based on standard operating procedures (SOPs). There might be situations in which activities take place outside these procedures, but these should be exceptions, not the rule.
We published a document on how to create security processes. This might be your starting point when preparing SOPs for incident handling team.
At the beginning it might be hard to predict different cases for which SOPs should exist. The incident handling team team should brain-storm on this and use incident handling standards and recommendations (like NIST SP 800-61 and ISO/IEC 27035) to list these cases and prepare the first list of SOPs. These SOPs should then be tested – and improved after each incident. If an incident occurs for which there is no SOP, such SOP should be added.
Having SOPs in place not only makes incident handling more effective. It also helps if for any reasons members of incident handling team leave and new members are coming.
Ask yourself these questions
- Do you involve your incident handling team in incident prevention?
- Do you use risk assessment to choose security measures?
- Does your incident handling team have, maintain, test and constantly improve SOPs?
Properly used security automation can help automate incident handling procedures (SOPs). Such automation might play key role in enabling incident handling team to take care of large number of incidents.
(In next articles in these series, we will be discussing NIST SP 800-61 incident response life cycle further phases.)