Why Security Incident Management Is Necessary
Once a security incident occurs, it’s management’s responsibility to minimize loss and destruction. According to NIST SP 800-61,
“An incident can be thought of as a violation or eminent threat of violation of computer security policies, acceptable use policies, or standard security practices” (Grance, Kent, & Kim, 2004, p.2-1).
An eminent threat is defined as a reasonable belief, based on available information, that an incident is about to occur.
When responding to an incident, the first consideration is protection of human life. The second is the restoration of information processing services that were lost or damaged. The final consideration is mitigation of weaknesses that might have been exploited during the incident. An Incident Management program that effectively addresses these areas produces the following benefits for your organization:
- The business impact of each incident is minimized
- The safety of your employees and data is enhanced
- Corporate liability due to lack of due diligence is mitigated
- Regulatory requirements are met
- Your organization’s public image is protected by a fast, professional response
Managing incidents consists of a set of institutionalized policies and processes, which are the product of the steps depicted in Figure 1: preparation, detection and analysis, containment/eradication/recovery, and post-incident activity.
Steps of the Data Management Process
Before an incident occurs, it’s important to do everything you reasonably can to prepare yourself for a quick and effective response. The steps leading to the proper preparation of your organization include:
- Developing an data loss incident management policy
- Forming and training incident response teams
- Developing a communication plan
Develop a Policy
The first step in any data security activity is the creation of a policy that clearly states your objectives. You should include:
- A statement of management commitment to an effective incident management capability
- The business and security objectives to be met
- A statement defining how your organization defines a data loss incident
- An incident management and response organization structure
The organization structure section of the policy is very important. Employees responsible for incident response must clearly understand their roles and the roles of other teams with which they will have to interface. The lack of a clearly defined organization structure can create confusion, resulting in each phase of a response taking longer than necessary. This almost always results in a more severe impact on your business. Some things to consider when planning your incident management teams include:
- The role of each team.
- Clearly defined responsibilities assigned to each team.
- Levels of authority – The chain of command, leading up to a single recovery manager, should be easy to follow. Further, the incident response teams should be given sufficient authority to make decisions necessary to shut down or confiscate systems to protect your information assets.
- Prioritization of incidents – Various types of incidents will occur in your organization. Each type might require a unique response with specific reporting requirements.
- An explanation of reporting requirements. What is each team’s responsibility for reporting, what should be included in the reports, and to whom are the reports submitted?
This policy forms the foundation for the next two steps in data security incident management preparation.
Form One or More Incident Response Teams
Cross-functional Incident Response Teams (IRTs) are your basic weapons against all types of data security attacks. The proper staffing and training of these teams is critical to your success in dealing with security incidents. Whether you need one or ten teams depends on your business environment. In any case, each team should consist of the following:
- A team manager. This person has overall responsibility to ensure business objectives are met during an data incident response activity. In addition, she is responsible for communicating status to senior management.
- A technical lead. The technical lead is charged with assessing the scope of impact of an incident on the technology infrastructure. He’s also responsible for containment and recovery activities as they relate to data processing systems. The technical lead supervises the following members of the IRT:
- One or more network engineers
- One or more programmers
- Public relations. This person is responsible for communicating with shareholders, the press, and other outside entities.
- Security. The IS Security team is usually the first responder to any incident. The members of this team are also responsible for providing oversight during containment, eradication, and data recovery operations.
- IS Support. The support team can:
- Assist with containment
- Establish alternate methods of information processing when primary systems or network paths are disrupted
- Assist with system recovery tasks
- Physical security. Securing the facility and responding to human intrusions and alerts are the responsibility of this role.
- Facilities management. Responsibilities for resolving power issues, locating and coordinating the move to alternate facilities, and structural assessments and repair fall here.
Overall responsibilities of an IRT
Your IRTs have three primary responsibilities.
- To prevent data security incidents
- To respond to incidents when they occur
- To take steps after an attack or outage to improve the organization’s incident prevention, detection, and response capabilities
The prevention of security incidents is essentially an exercise in managing risk in a reasonable and appropriate manner, including:
- Identification of threat/vulnerability pairs through
- Vulnerability assessments
- Penetration testing
- Vulnerability reports from vendors as well as private and government sources
- Assessment of the probability that a threat will exploit one or more vulnerabilities
- Assessment of potential business impact if specific events occur
- Development of action plans, based on sound risk management principles, to proactively mitigate risk
Once a data loss incident occurs, your IRTs must have the skills necessary to quickly react in a way that minimizes business impact. To accomplish this, each team member must understand how to:
- Analyze incident data
- Determine the scope and nature of the incident
- Communicate with other data recovery teams, including the information to be communicated
Recommendations as to how each of these activities should be executed are provided later in this series.
The IRTs’ responsibilities don’t end once they complete recovery operations. As we’ll examine in the following articles, post recovery activities are a very important part of incident management. These activities include understanding how to improve prevention and detection controls, how to further reduce business impact, and the development of an action plan to make the necessary adjustments to incident response teams and documentation.
Develop a Communication Plan
One of the most important facets of data loss incident management and response is communication. Adequate communication for the purpose of data recovery, business impact control, and public relations considerations requires reaching out to various internal and external entities. Figure 2 depicts communication points you should consider during preparation, response, recovery, and post-recovery operations. Your data loss incident management communication plan should include names, phone numbers, and when to contact each entity listed. I’m not going to discuss all of these entities; the following is a look at some of the most critical.
Media – In our description of the member of an IRT, we included a public relations professional. Sending the right message to the media is absolutely essential if you hope to effectively deal with the fears of customers and investors. In addition to the public relations representative, all other members of your IRTs should also be trained on how to respond to inquires from the press.
Law Enforcement – Develop a relationship with local, state, and federal law enforcement prior to the occurrence of an incident. Use this opportunity to understand how each agency can help and how they prefer you process evidence or a potential information security crime scene if data has been stolen. Once an incident occurs, coordinate contact with law enforcement through senior management, human resources, and if appropriate, your legal department.
Incident Reporting Organizations – Although reporting an data security incident to an organization like the United States Computer
Emergency Readiness Team (US-CERT) at https://www.us-cert.gov/, is not necessarily going to improve the quality of your recovery, it will provide information to a central database that law enforcement agencies and businesses can use to identify and mitigate threats or vulnerabilities.
Organization’s ISPs – Your ISPs, or Internet Service Providers, are an important resource during an attack via the Internet. If you’ve taken appropriate steps during preparation activities, your ISPs can assist by quickly blocking suspect traffic. In addition, an ongoing relationship with your ISP can result in frequent reviews of what steps they’re taking to proactively prevent known attack traffic from reaching your network perimeter.
Owners of Attacking Addresses – In many cases, the systems used to attack your network and data may be infected machines on an unsuspecting organization’s network. Make sure at least one person in each IRT knows how to quickly locate the owner of an IP address by using a service like ARIN (https://www.arin.net/). A quick call to the address owner can accomplish two objectives. First, the owner can block all outgoing traffic associated with the attack. Second, the owning organization can take steps to rid their network of the malware; this will help prevent future attacks.
Software Vendors – Before, during, and after an attack, one of the most important communication points is the vendor who supports the target or damaged application or operating system. The vendor can help identify the existence of potential vulnerabilities, recommend critical security patches, translate log entries, provide assistance during an attack, and help with recovery efforts.
Affected External Party – Affected external parties might include customers and suppliers. Your organization has a responsibility to practice due diligence to prevent the effects of an attack or data loss from migrating to entities connected to your network. Notifying IRTs at connected organizations is a good start. Further, you should let your customers and suppliers know if there will be an interruption in service or product delivery. Finally, if the attack involved the potential compromise of regulated or other sensitive information about employees or customers, it’s critical (and in some locations mandatory) to notify all affected parties. Prior to communicating with any external party, be sure to clear the content of the communication through senior management and your legal department.
Data security Incident management preparation might consume significant time and resources. But it provides the foundation necessary to adequately perform the tasks in the remaining incident management steps.
In Part 2, we examine how to detect and analyze a data security incident.
Gano, D. L. (1999). Apollo root cause analysis: a new way of thinking. Apollonian Publications.
Grance, T., Kent, K., & Kim, B. (2004). Computer security incident handling Guide (NIST SP 800-61). Retrieved July 24, 2008 from https://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf
This post is part of the series: Security Incident Management
- The Data Security Incident Management Process: Policies, Teams, and Communication
- Preventing and Containing Data Loss by Detecting and Analyzing Data Security Issues
- Reducing the Damage Caused by Network Security Threats and Identifying Attackers
- Recovering Corporate Data After a Data Security Attack
- Challenges of Managing Data Security: Causes and Effects of Data System Failures