alphaspirit - Fotolia
When your system is compromised, you generally have one chance to get the response right. Any mistakes made in the early moments of a cybersecurity incident can have a negative, cascading impact that will be difficult -- if not impossible -- to recover from. Initial actions often determine whether the outcome is manageable, or chaotic and destructive. Having a predetermined plan is critical to avoiding those mistakes and mitigating damage.
There are several elements that should be included when developing and implementing a cybersecurity incident response plan. How you complete these steps is dependent on numerous variables, including your company's unique cybersecurity vulnerabilities and regulatory compliance needs. But generally, your plan can be built by following these steps.
1. Develop goals: Carefully describe the overarching goals of the plan. Having goals for each section will help those assigned to deliver on the plan understand the context of their assignment, and the reason for their actions.
2. Determine the people involved: Be sure those expected to act are not just identified but fully informed and trained on their role in cybersecurity incident response. Describe, by role, who will do what in the event of an information security incident or data breach. Some additional recommendations:
- A single point of contact should manage policies and procedures. This person should be assigned in advance, and be tasked with ensuring that your organization has plans in place that are current and viable.
- Establish a Computer Security Incident Response Team (CSIRT). The team's job is to quickly and effectively respond to and manage high-level incidents. CSIRT members should be empowered to make decisions and execute in the event of an incident. The CSIRT should also have the ability to assign smaller strike teams to assess the severity and potential impacts of an individual incident.
3. Identify discovery mechanisms: Be sure to identify systems, activities and events that can be monitored or reviewed on a regular basis. Constant review to identify potential information security incidents quickly is critical.
4. Determine cybersecurity incident response triggers: Identify as many common events that will trigger an investigation as you can. You don't need to cover them all, but being thorough will help others to understand what they should look for and how to respond. Some possible triggers include:
- Theft or loss of a computing device
- Many failed attempts to gain system access
- Attempts to use old credentials
- Access attempts that are outside of normal business hours
- Unauthorized access to a system containing protected data
- Employee snooping or information capture
- Discovery of installed malware capable of data exfiltration or credential capture
5. CSIRT activation: Identify how, when and what levels of staff are to be activated depending on the type of information security incident. Loosely describe incidents that could require a response from an individual employee, a small cyber strike team and/or the full CSIRT. In smaller organizations, this may also be decided by executives on a case-by-case basis. The following are examples of moderate to severe information security incidents, and the appropriate response:
- Virus infection that only impacts one machine or host (individual with report going to CSIRT).
- Virus that impacts more than one machine or host (strike team of assigned individuals with report to CSIRT).
- Possible malware infection with data exfiltration capabilities (strike team with potential to expand to the full CSIRT).
- Known severe malware database infection/attack that is believed to have resulted in significant data exfiltration or destruction (full CSIRT with assigned strike teams based on needs).
6. Define breach determination methodology: Describe the methodology of how you will determine if protected data was compromised based on the type of attack identified and the classification of the potentially breached data. For example, determine if there was a probability of compromise using the four-factor risk assessment methodology required for healthcare data. This method is helpful for all companies, not just those in healthcare. Furthermore, it's important to remember that if there is a compromise then you have likely violated state and federal regulations. The four-factor test, according to HIPAA definitions 45 CFR 164.402, assesses:
- The nature and extent of the protected information involved, including the types of identifiers and the likelihood of re-identification;
- The unauthorized person who used the protected information and/or to whom the disclosure was made;
- Whether the protected information was actually acquired or viewed; and
- The extent to which the risk to the protected information has been mitigated.
7. Define triggering events: Determine what will trigger a breach notification based on regulatory and contractual obligations. These could be notifications to contract partners, employees, consumers, law enforcement and regulatory bodies.
8. Activate the breach response team: This will include members of the CSIRT but also any additional staff needed to respond in a breach's aftermath. These staff members can be both internal and external, and could include technical staff, vendor representatives, legal and compliance officers, public relations and marketing.
9. Outline notification actions: Notification requirements vary by federal statute, state law and data class. It is important to know the requirements for each class of data and their associated laws. Because there are so many different requirements, it is important to examine each carefully. It is strongly recommended that the basic process and contents be drafted well in advance. Some guidelines on the type of data to include:
- The organization's name and that of others associated with the breach, as well as contact information.
- The exact date and duration of the breach, as well as details on the type of breach that occurred.
- The number individuals affected, and what data classes and quantity is thought to have been breached.
- The known and potential threats to the consumer or patient, and mitigation steps to limit damage.
- Information on how impacted individuals can review their credit reports.
10. Detail remediation efforts: After an incident, there will often be remediation work required to return your organization to normal operations. This could involve reinstalling applications, rebuilding databases or host machines, changing network configurations and adding new monitoring services. Remediation should start as soon as possible to help prevent additional incidents triggered by the vulnerability, policy or procedure that allowed the incident to occur in the first place.
11. Develop reporting and documentation: It is critical that you produce accurate and complete documentation of the events, actions and results that occur during a security incident. Be sure to spend time to accurately record exactly how the incident occurred and the company's response. Keep copies of all communications and notifications, and document any and all activity related to the breach.
12. Review policy and procedures: A significant security incident or breach is a great opportunity to improve data protection policies and procedures. Take the opportunity to consider what happened to allow the breach and how the company responded. Then consider and document ways to improve both.
13. Train and update staff: Once you have created your cybersecurity incident response plan, you should train your staff consistently on their role in bringing it to fruition. If staff members are either unaware of or not familiar with the plan, you might as well not have one. A lack of training can lead to inaction, delays and mistakes that are avoidable and incredibly costly. Empower your employees to be confident and ready to act when the inevitable occurs.
Check out our list below for the 13 steps to develop the best cybersecurity incident response plan.
(You can also download the image by right-clicking here and selecting Save As.)
Merge cyberincident response with business continuity and disaster recovery planning
What should a security incident response process look like?