[BreachExchange] The dos and don'ts of a successful incident response program

[Audrey McNeil]

http://www.securityinfowatch.com/article/12401337/the-dos-
and-donts-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
was 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20180305/2e005929/attachment.html>