Editor's note: This is part of a series on achieving cybersecurity readiness. Part one of this series looks at...
the concept of cybersecurity readiness and proposes seven elements or objectives as fundamentals for achieving that state. Part two examines the first element on that list: building a cybersecurity plan. Part three focuses on the technology aspects of an information security architecture. Part four covers information security risk management. Part five explores identity management systems. Part six examines authorization and accountability, and part seven addresses the importance of network monitoring.
In part one of this series on cybersecurity readiness, security incident management was described as providing effective responses to incidents ranging from low-level attacks to full-scale network breaches, in addition to lowering the amount of damage done to the organization, while reducing the time and cost of recovery.
Computer security incident response is an inherently technical activity that seeks to detect security incidents and provide a technical response to address the problems. However, security incident management doesn't just include the technical activities done responding to an incident; there are also roles, responsibilities and activities involving business management, legal, human resources, public and investor relations, security and network operations, physical security, and more.
All these roles and responsibilities taken together constitute an organization's security incident management capability. These roles and responsibilities span the organization, and they must be documented in an incident management plan. The most important task for building effective incident management is to create an incident response plan.
What is a security incident management plan?
A basic tenet of computer security incident response is that you can only protect your network against those problems about which you already know, which are principally vulnerabilities. Beyond that, all you can do is be prepared to respond effectively to unknown events.
The key element in preparing for effective response is a security incident management plan, which is a document that guides an organization's efforts in responding to a cybersecurity incident. An incident management plan defines what is considered an incident and documents the policies, procedures, processes, workflows, roles and responsibilities, communication and escalation required to respond to a computer security incident.
Incident management plan value
In a study by the Ponemon Institute and IBM Security, an incident management plan was the single biggest factor in reducing the cost of a data breach. Having an incident management plan supports a consistent response to computer security incidents.
Some organizations may need an incident management plan to comply with regulatory or contractual requirements. An incident management plan is also a necessary security control that can demonstrate due diligence with respect to compliance.
Immediate incident response goals: Stop the problem
When an incident is detected, there are several steps under a security incident management plan to consider. An immediate goal of incident response is to understand the problem well enough to quickly act to reduce the damage that has been done by stopping the incident from getting any worse.
Consider this scenario: A network monitor detects a large amount of data being streamed from a customer information database through the internet gateway to an unrecognized IP address outside the country. In this scenario, an immediate action that could be taken to reduce the damage and stop further loss of customer data could be to set up a firewall block on the IP address that is receiving the data. In its "Computer Security Incident Handling Guide," SP 800-61 R2, the National Institute of Standards and Technology (NIST) calls this "containment."
Short-to-medium term goal: Eradicate
Once the incident is contained, and no further loss or damage is occurring, there is time to analyze and understand the incident well enough to identify exactly what has happened and how to eliminate the components of the incident. NIST calls this "eradication."
During the analysis of the previous incident scenario, it is discovered that customer information is being sent out of the network by an internal database administrator. Further investigation reveals that the database administrator lost control of their login credentials by clicking on a link in a phishing email. The database administrator's single sign-on network login credentials also grant admin access to the database. Analyzing the phishing email, it is discovered that 1,000 users received the same phishing email and 20% of the recipients of the malicious email clicked on the link and lost control of their login credentials. Of these users:
- 15 are administrators of various application systems, including databases and web servers;
- 25 are senior executives and their support staff; and
- 7 are IT staff with privileges enabling control and configuration of firewalls, core routers and critical network services, including the Dynamic Host Configuration Protocol and the domain name system.
This incident scenario includes many different tasks to eradicate this incident: Changing the passwords of the affected users, or perhaps all users; investigating all the assets to which the system administrators, IT staff and business managers have access for signs of compromise; checking for other signs of compromise involving the IP address that was blocked; and checking user credentials for other signs of compromise and identifying any user credentials that may have been maliciously added or changed.
Once a complete understanding of the incident has been gained, and all the components of the incident are eradicated, organizations can move on to the next goal.
Medium-term goal: Recovery
The next incident response goal is recovery or, specifically, returning to normal operations as quickly as possible. Often, the tasks of eradication and recovery are handled together.
In this scenario, one of the biggest challenges for returning to full operating capability is restoring the customer information database by evaluating it for any signs of compromise and ensuring the integrity of the database before it is put back in production.
Long-term goal: Prevent reoccurrence
After normal operations have resumed, the next incident response goal is to prevent the reoccurrence of this type of incident. An evaluation, sometimes referred to as lessons learned or an after-action review, must take place to uncover and study the root causes of an incident. An incident should not be closed until a root cause analysis has been completed. After root causes have been identified, mitigation plans and protection strategies should then be identified, developed and implemented.
In this scenario, access control rules need to be modified so that a user logging into the network is not immediately granted database administration privileges. Perhaps application-level control should be implemented so that two-person integrity is required before a database can be streamed outside the network. Additionally, encryption, which can provide confidentially even if the data is stolen, should be considered.
Stay tuned for the next and final part of this series, which looks at all of the combined elements of a cybersecurity readiness plan.
Get the latest information on security analytics principles for IT professionals
Read more on the importance of mobile application security assessments
Learn how proper SSH key management can protect enterprises from breaches