Top 5 Incident Management Issues
The CERT Division of the SEI has a history of helping organizations develop, improve, and assess their incident management functions. Frequently we discover that an organization's primary focus is on security incident response, rather than the broader effort of security incident management. Incident response is just one step in the incident management lifecycle. In this blog post, we look at five recurring issues we regularly encounter in organizations' Incident Management programs, along with recommended solutions. By discovering and resolving these issues, organizations can attain a better cybersecurity posture.
Incident Management Lifecycle
The incident management evaluation process we use is based on a number of known standards and guidelines from government and industry, such as the National Institute of Standards and Technology (NIST) Special Publications (SP) 800-61 Rev. 2 and 800-53 Rev. 4, DOD guidance, and our own internal research. Currently we evaluate organizations against a phased incident management lifecycle with associated categories and subcategories as described below.
- PLAN focuses on implementing an operational and successful incident management program.
- DEFEND relates to actions taken to prevent attacks from occurring and mitigate the impact of attacks that do occur as well as fixing actual and potential malicious activity.
- IDENTIFY includes proactively collecting information about current events, potential incidents, vulnerabilities, or other incident management functions.
- ACT includes the steps taken to analyze, resolve, or mitigate an event or incident.
- MAINTAIN focuses on preserving and improving the computer security incident response team (CSIRT) or incident management function itself.
The Top 5 Issues in Incident Management
Based on our Incident Management Evaluations, we have discovered the most common issues encountered by organizations with deficient incident management programs. Understanding these problems can provide insights into better management of incidents before they become major security concerns.
(1) No list or database of critical assets
An absence of a database or list of critical assets is typically due to a lack of asset management processes and procedures. Not having documentation of critical assets and data would decrease the ability to defend and protect them from potential attackers and other threats.
Develop an inventory of all critical assets and data. It is also important to establish and document processes for the management of lists, to include processes for updates, reviews, and storage.
(2) No insider threat program
The risk of a successful insider exploit in the organization will increase without an insider threat program. The loss or compromise of critical assets, personally identifiable information (PII), sensitive information, and other valuable assets from insider fraud, theft, sabotage, and acts of violence or terror may produce irreparable damage.
Develop a formalized insider threat program with defined roles and responsibilities. The program must have criteria and thresholds for conducting inquiries, referring to investigators, and requesting prosecution. For more information, see the Common Sense Guide to Mitigating Insider Threats, Fifth Edition.
(3) Operational exercises not conducted
Organizations without operational exercises will not be able to practice standard operating procedures (SOPs) in a realistic environment. Gathering lessons-learned, improving IM operations and procedures, and validating operations may also suffer.
Develop a formal process to perform operational exercises, create lessons learned, and incorporate them into future exercise objectives and operational SOPs. Doing so will benefit the organization tremendously. For more information, see the NIST SP 800-84 and NIST SP 800-61 Rev. 2.
(4) No operational security (OPSEC) program
Not having a formal operational security program can reduce awareness of sensitive information and operations. This lack of knowledge can lead to unintentional exposure of data about processes and procedures, along with the inability to properly handle, store, and transport sensitive data.
Establish a formal OPSEC program that covers sensitive information. The program should include policies for identifying, controlling, and handling sensitive information. The organization should also implement a policy for the storage, transport, and release of sensitive data. For more information, see NIST SP 800-61 Rev. 2 and NIST SP 800-53 Rev. 4.
(5) Documented plans and policies not developed
Not having developed plans and policies, such as an Incident Management Plan or a Communications Plan, can cause a number of problems. These issues include a delayed response time due to the lack of stakeholder and staff contact details and improper escalation of incidents or creation of new issues.
Develop an Incident Management (IM) Plan that all stakeholders review during updates. Organizations should develop related policies and procedures, such as a Communications Plan and Information Management Plan. Specifically, they should develop, maintain, distribute, and test an organization-wide communications plan that lists groups (e.g., Information Technology, Human Resources, Legal, Public Affairs, and Physical Security), individuals, and the details of their functional roles and responsibilities as well as relevant contact information. The Information Management Plan should contain a schema of classification and appropriate labels. The plan should include policies or guidance on media relations and acceptable use. For more information, see Executive Order 12958 Classified National Security Information.
My next blog post will talk about how to develop an Incident Management Plan and a Communications Plan. These plans are part of any productive Incident Management Program. In the meantime, check out the SEI's recently released Incident Management Capability Assessment. The capabilities it presents can provide a baseline or benchmark of incident management practices for an organization. Organizations can use the benchmark to assess its current incident management function. You can also learn more about the SEI's Incident Management Resources and our work in this area.