The dos and don'ts of a successful incident response program
Many organizations have adopted a herd mentality by assigning the security incident responsibility to the Chief Information Officer (CIO) or senior security official (CISO). Unfortunately, this myopic approach is a prescription for the organization to make serious errors and delay responding based on two key observations. First, not all security incidents result in a breach of confidential data, nor do all breaches start with a security incident. Second, all incidents require human interaction at some point early in the process. Since the fog of uncertainty is thickest at the start, the first individuals at the scene do not typically have access to enough data to determine if the incident will result in a security or privacy issue. For these reasons, any incident response process should address all types of security and privacy incidents, as well as engage key stakeholders from many disciplines.
Discussion
By now, all organizations that create or store sensitive information should be aware that they are vulnerable to many types of security and privacy incidents. As organizations respond to these incidents, they must consider their legal, regulatory, and contractual obligations. While disaster recovery plans are designed to perform a technical recovery, there are other obligations beyond a technical recovery that must be considered including government, client, and/or individual notifications.
Many of the security and operational frameworks published by the National Institute of Standards and Technology (NIST), International Standards Organization (ISO) — as well as industry-specific regulations, such as Health Insurance Portability and Accountability Act (HIPAA) — require organizations to implement policies and procedures to address security incidents. Implementation first implies a process has been developed and documented, and then all key stakeholders have received meaningful periodic training in their roles. Training is most effective when the key decision makers participate. If an organization were to experience a major ransomware attack, the CIO can expect at a minimum the CEO, CFO, COO, and HR to all be impacted. Many others are needed to help with recovery and communications, including procurement, HR, public affairs, and IT. Finally, the General Counsel and the compliance team are needed to analyze information from many sources and recommend decisions.
Key Lessons
- Incidents can happen very quickly (e.g., ransomware attacks can infect vulnerable systems in less than an hour). Therefore, organizations need to designate a primary and backup decision maker that has the authority to act quickly, as there may be little time to locate the key executives.
- If an organization anticipates potential litigation, certain elements of the investigation may need to be protected by attorney-client privilege. This decision needs to be made as immediately as possible, as any action taken prior to getting the attorney’s advice or direction cannot later be protected.
- Avoid premature use of the term “breach” by limiting authority on who may determine if an incident is a breach.
- Assign a scribe to document all decisions and take accurate minutes. Memories fade with fatigue, but the documentation will be needed at some point in the future.
Following any incident, organizations must identify and mitigate the vulnerabilities that caused the incident. For example, in healthcare the HIPAA Security Rule further requires organizations to “[I]dentify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity; and document security incidents and their outcome.” The security incident implementation specification supports the requirement that not all security incidents are technical in nature. Both the theft of a laptop and the theft of a paper record containing unsecured protected health information may cause harmful effects to the patient.
During the initial discovery of an incident, it may be difficult to determine what type of sensitive data has been compromised. Rather than attempt to define multiple response processes, it is prudent to only have one incident response policy and use it for all circumstances. Many types of sensitive data come with reporting obligations to meet federal, state, and local regulations, as well as contractual clauses with partners and vendors. An incident response policy should be scoped broad enough to address all requirements.
Key Lessons
- Part of the incident response process is to identify and document all root causes, so they can be remediated with new controls. Failure to take action is a symptom of a weak risk management process.
- An after-action report — containing details of what happened, a timeline, the sensitive data compromised (if applicable), and the decisions made — will be needed, either for the insurance company, regulators, and/or attorneys who may need to defend against litigation.
- A separate root cause analysis will be required to determine what caused the breach (technical, human, or process). Then the organization must implement new controls to ensure that the weakness is not exploited again. If an organization concludes a breach did not occur, a detailed analysis should be prepared for potential sharing with the management team.
- Specific to healthcare, the HIPAA Omnibus Rule changed the original rule by defining a protected health information breach as being greater than a low probability of compromise. It also defined four factors that should be used to determine the probability of compromise. The Office for Civil Rights (OCR), in its recent random audits, required the targeted organizations to provide evidence of this analysis for previous events. Other industries may have similar requirements.
If there is one positive outcome from the rash of recent malware and ransomware incidents, it is that impacted CIOs and CISOs are starting to understand they cannot respond to a security or privacy incident without assistance from the rest of the organization.
Conclusion
With the increase in the frequency of ransomware attacks, all organizations need to take a hard look at their incident response preparedness. There is plenty of evidence that the negative impacts of an attack can be mitigated through quick reactions, but as long as a human is in the decision loop, ransomware has the potential to cause significant damage. In a recent incident, the ransomware was able to crawl through an organization’s network, including the remote sites, to infect vulnerable systems in under an hour. Recovery times have taken significantly longer (i.e. weeks), which has kept both the primary functions and supporting operations off-line as well.
The bottom line is while ransomware attacks are getting a lot of headlines, these are just one type of incident. Organizations must also prepare for other manmade and accidental incidents, such as the fires in California and hurricanes in Texas, Florida, and Puerto Rico. It is not a matter of if they will happen, but rather it is a matter of when it will happen. It is imperative to plan for the worst by having an incident response policy in place. Only when prepared can organizations truly hope for the best.