Introduction
This breach response article is designed to help stakeholders (i.e. organizations of all sizes experiencing a breach) understand the requirements of various federal, state and private regulatory regimes. HIPAA is simply one example. After WannaCry and Petya organizations are starting to realize that it's not a question of "if" they will experience an attack that leads to a breach but simply "when."
Despite this realization most C-Suite participants are at a loss as to how to proceed, given their lack of subject matter expertise and the myriad of options presented to them, from enhancing their cybersecurity fortifications to transferring the risk via insurance.
This article attempts to cover the major components of a Breach Response Plan ("BRP") which, by necessity touches on other pre-existing collateral that an organization should have in place, such as a Disaster Recovery Plan ("DRP"), Incident Tracking Process, a Methodology for rigorous determination as to whether Breach Notification is triggered, etc.
This Article also covers the following key Pieces of the Puzzle:
Preparedness;
Incidents;
Teams;
Testing; and
Post Mortem.
Each key component is broken down into relevant sub-components as required.
Audience
As in almost every other article and/or white paper of this type, we indulge in the conceit that senior management is going to be interested in digesting these components. However, as a practical matter, we understand that the probability of that is low. Instead we are more humbly targeting inside counsel, outside counsel, compliance officers, CISOs, CIOs and an entire laundry list of similar professionals.
It is this audience that will ultimately be responsible for "scrambling" to respond to a breach, with the C-Suite likely in "virtual panic mode" depending on the size and scope of the incident. Given the pressure to respond in a timely manner, stakeholders should pay careful attention to the Preparedness Section of this Article. The only way to mount a coherent and effective response is to plan for it.
Without such a plan, the response is likely to be helter-skelter with the possibility that the liability attached to the breach increases significantly. A well-defined plan executed by a knowledgeable team represents the most effective way to limit both liability and response costs.
As discussed below, a Tech Savvy Law Firm ("TSLF") is best suited to act as your response plan's General Manager, coordinating the efforts of the multiple teams necessary to effectuate the plan.
The objectives of this article are to help prepare your organization to respond to a breach of Personally Identifiable Information, Protected Health Information, or any other sensitive information that may be compromised by either an internal or external threat (collectively "Sensitive Data" or "SD"). Although this article is clearly intended to educate, our objectives are to provide significantly more than the platitudes contained in most white papers. We intend that this article provide your organization with what a robust preparedness plan might look like, as well as sample tasks and the stakeholders responsible for them. The last thing you want to be doing during a response is building a plan on the fly. It is our hope that you will do this well in advance of a breach.
Grammar
Similar to learning a new foreign language, breach response has it own "lingo" that must be mastered before you can even begin to communicate in a reasonable manner with all the required stakeholders, of which, as we discuss below, there are many. Therefore, many of you many find the definition on the right as a useful place to start.
Of course the "lingo" will differ from team to team, but this article focuses on the "generalist" responsible party (at least from the client's perspective), who will need to talk to counsel and coordinate between teams, unless of course this task is left to a TSLF, in which the generalist will mostly communicate with counsel. The client here being the organization that experienced the Breach.
Pieces of the Puzzle
This article addresses the people, processes and platform required to effectively respond to a breach of Sensitive Data. An effective response ("Response") requires the coordination of a disparate set of individuals and teams, the specifics of which we discuss throughout this article. However, any such large endeavor, like the building of a skyscraper or commercial airliner, requires a general manager that can effectively coordinate the activities of all the teams to ensure a high quality timely Response.
Here we make the argument that it is a "Tech Savvy Law Firm" that should function as the General Manager, for the following non-exhaustive list of reasons:
* The ramifications and repercussions of the federal and state laws that may be implicated and compliance with same;
* Speaking with a complete knowledge of the issues to federal and state regulators will be greatly appreciated by the latter, increase the comity between the parties, and possibly lead to reduced liability (e.g. under HIPAA the TSLF's ability to make a compelling argument that a breach occurred despite the fact that the client had made a good faith effort to comply likely get the client out of "willful neglect land"-where the civil monetary penalties ("CMPs") start at $50.000 per violation and max out at $1.5. per identical vi0lation ).
* Even what may appear to be mundane technical activities are likely to have legal consequences (e.g. altering the encryption of the underlying Sensitive Data before the forensics teams has had an opportunity to capture and document the "As Is" environment);
* The fact that the attorney-client privilege may arguably be maintained across all teams if the latter all work at the behest of the TSLF.
The obvious challenge with this recommendation is finding a TSLF that has the technical and organizational "chops" to effectively function as a general manager ("GM"). The fact that lawyers tend to be "technophobic" is an overly used generalization, but like all such generalizations there's more than a little truth embodied within it.
Throughout the remainder of this article we will discuss the teams necessary to get the job done (legal, forensics, information technology, compliance, public relations, administration, identity protection,
insurance, and the executive suite to name a few).
Preparedness
The problem with "preparedness" is that it is too easy to fall into a litany of platitudes that everyone knows that they should do and no one ever does. Well sorry to say that we are not going to disappoint, prepare for some dull, boring, trite platitudes. However, the difference is that we are providing the reader with a set of tools (
commercial product only shipping "soon") that facilitate "preparedness" because at the end of the day there is no escaping it.
Needless to say, you will be forced to develop your own preparedness plan
("Response Plan" or "Plan") or modify ours to suit your needs. Having a Plan, in and of itself, may help you avoid some liability (i.e. to the extent that having a plan allows your legal team to make an argument that "far from being completely negligent, you were attempting to do the right thing".) Most of you understand that although that argument is better than no argument at all, it's only going to take you so far. At the end of the day, you will be forced to provide
visible, demonstrable evidence ("VDE") that you responded in an effective way-that is, that the "boots on the ground" did the right thing.
Any non-trivial Plan must encompass, at a minimum, the following subject matter areas:
- Review and distribution of Breach Response Policy.
- Review, modify, and distribute the Application Sensitive Data Criticality List
- A methodology for determining whether a breach has occurred;
- A forensics analysis to discover technical root cause analytics;
- A legal analytical framework for deciding if the root cause analytics necessitates breach notification under applicable law, both state and federal;
- A review of tools and templates such as executive management/board of directors update; call lists, sample notification letters/communications to stakeholders, press releases
- Incidents
- Ensure Incident gathering and documentation process is in place;
- Ensure that Incident master document has been designed, implemented and routed for approval;
- A communications plan
- Communications to Response partners and the activation of Response teams;
- Communications to regulatory authorities;
- Communications to media, social media, and other organizational news consumption end points;
- Communications to individuals impacted;
- Activation of Call Center for inquiries;
- Activation of identity protection services as required;
- Activation of remediation teams, including working closely with third party technical partners.
- Response Plan Testing
- Test the immediate incident reception and analysis;
- Instantiate and test the Communications Plan;
- Review remediation readiness.
- Response Post Mortem
- Review status of remediation;
- Update the executive management team on remediation progress;
- Implement additional Security Controls that would prevent similar breaches;
- Update Breach Response Plan according to insights gains from post mortem.
Further, the Plan must effectively deal with collaboration and coordination between teams. It is the latter that will likely make the difference between success and failure.
Teams
Almost everything (non-trivial) that happens in the business world, and in many other walks of life, is the
result of a project, as executed by a team. Projects have a well-defined beginning, middle and end. They always require a project plan. The plan not only defines the stages of the project, but also drives its execution. However, we prefer the word mission, rather than plan, because it implies motion and carries a more action-oriented connotation. Breach Response is a mission that the organization embarks upon, one whose importance is often not well understood until after the disaster has struck. Your organization's reputation is on the line.
It is too late to take the proactive measures that you should have taken, but not too late to minimize the liability; something a TSLF is best suited to perform on your behalf. For example, fail to notify your insurance company in timely manner (assuming you have purchased cyber-insurance) and they may indeed refuse to provide coverage and/or a defense in subsequent litigation. This is not the exception but the rule.
That is the insurance industry's business model. You can disregard the "happy talk" during the buying experience; at the end of the day an insurance company is rarely your friend. Even when they do provide coverage, they are notorious "reluctant friends;" often looking for ways to reduce their liability. Any competent law firm will advise you to notify your insurance company as one of the first acts of a Response. However, a TSLF will understand how to use the forensics to ensure that you get all the coverage that you are entitled to. The context matters.
You usually either sign up for the mission of a Response through the economic pressure of "keeping your job" or are "volunteered." For us, signing up to be a member of the Response team results in a much deeper commitment than is apparent on the surface. It means that you will do almost anything within your power to achieve the end game, which is getting your Operational Environment rebooted so that you can effectively serve customers (either directly or indirectly) and to contribute the reduction of liability wherever possible.
Signing up does not necessarily imply consistently working sixty hours a week for the duration of the mission. However, it does imply that you will go above and beyond the call of duty, which often entails some overtime and/or other personal sacrifices at critical junctures. Signing up is a binary proposition; you're either onboard or you're not. There is no acceptable middle ground. It is a (illusory) contract that is signed with the rest of the team. It is mutually binding and cannot be broken without putting the mission at risk.
Although signing up ensures that everyone on the project commits to everyone else by signing the same mutually binding contract, the GM also signs a personalized contract with each team member. This contract is a promise that both individual and specific rewards will accrue to every team member in return for his or her effort during the mission, whether internal or external to the organization. It answers the question: "What's in it for me?" This contract is implicit between the GM and an individual team member, and is not shared with other mission comrades.
It goes without saying that today's Operational Environments are much too complex for any single individual to handle all the tasks of a Response. Hence, the GM is required to select and incentivize team members commensurate with the importance of the mission. The complexity inherent in today's environments ensures that every few years an incident will occur that triggers either the entirety of, or at a minimum, a component of the Response. It's no longer a question of "if" but rather "when."
[1] You can either apply a helter-skelter chaotic Response approach, or have a well thought-out and tested Plan to guide you. For obvious reasons, we believe that the latter is the only viable solution and the only one that makes business sense. It also happens to be the one mandated by almost all the regulatory regimes you are confronted with.
The reality is that for nearly all organizations the Response team is really a team of teams. The GM is still responsible for the overall effort but he or she will be leaning heavy on the team leaders for the non-exhaustive list of subject matter domains discussed herein. The Call List[2] should be initiated by the GM (or alternate backup) if not available to each team lead. Team leads are responsible for calling their team members. In the case where a team lead is not available, the GM calls the team lead backup or the next available team member. Team leaders or individual team members report back to the GM to ensure closure on the Call List.
An article dealing effectively with Breach Response Components lies closer to a white paper than the former. Obviously, this article only represents an introduction to Part II wherein we will provide an overview of each team's respective role and more specifics about what a TSLF can provide...
so stay tuned.
[1] Think WannaCry and Petya on steroids. Everyone knows it's coming, yet most organizations fail to engage in basic preparation. "The risk of large-scale cyber-attacks continues to be considered above average on both dimensions of impact and likelihood. This reflects both growing sophistication...and hype connectivity..."
See Global Risks Report 2015, World Economic Forum.
[2] See the definitions section of this article.
|
|
Definitions
Term
|
Definition
|
Adequate Security
|
The term "Adequate Security" means Security commensurate with the Risk and magnitude of harm resulting from loss, misuse, or unauthorized access to or modification of Sensitive Data.
|
Attack
|
The term "Attack" means any kind of malicious activity that attempts to collect, disrupt, deny, degrade, or destroy Information System resources or Sensitive Data.
|
Authentication
|
The term "Authentication" means verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an Information System.
|
|
|
Breach
|
The term "Breach" means the acquisition, access, use, or disclosure of Sensitive Data
[1] in a manner not permitted under applicable law which compromises the security or privacy of the Sensitive Data.
|
Adversary
|
The term "Adversary" means an individual, group, organization, or government that conducts or has the intent to conduct detrimental activities.
|
Asset
|
The term "Asset" means a thing (tangible or intangible) that accesses, stores, maintains, or transmits Sensitive Data. Examples include networks, PCs, servers, mobile devices, Information Systems, buildings, etc. See Security Object
|
|
|
Availability
|
The term "Availability" means ensuring timely and reliable access to and use of the Sensitive Data.
|
Call List
|
The term "Call List" means a Workforce, Partner, Government, and media contact list (e.g. phone, email, Twitter, etc.) to be used when initiating an incident response.
|
CIO
|
The term "CIO" means Chief Information Officer.
|
Cloud
|
The term "Cloud" means the use of one or more remote servers hosted on the Internet used to store Sensitive Data.
|
CO
|
The term "CO" means Compliance Officer.
|
Compliance Repository
|
The term "Compliance Repository" means the Location where a single version of the truth, pursuant to your compliance initiative, stores documents and other artifacts related to same (e.g. policies and procedures, partner contracts, Workforce sanction documentation, compliance reports, etc.).
|
Confidentiality
|
The term "Confidentiality" means preserving authorized restrictions on Sensitive Data access and disclosure, including means for protecting personal privacy and the Sensitive Data itself.
|
Disclose
|
The term ''Disclose'' and ''Disclosure'' mean the release, transfer, provision of, access to, or divulging in any other manner of information outside the entity holding the information.
|
EHR
|
The term "EHR" means Electronic Health Records.
|
Expresso™
|
The term "Expresso™" means a software-as-a-service ("SaaS") application that builds on NIST's seven (7) step process to perform Risk Assessments.
|
|
|
Impact
|
The term "Impact" means the magnitude of harm that can be expected to result from the consequences of unauthorized disclosure of Sensitive Data, unauthorized modification of Sensitive Data, unauthorized destruction of Sensitive Data, loss of Sensitive Data, or loss of Sensitive Data system availability.
|
Incident
|
The term "Incident" means the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system. This term is not synonymous with Breach.
|
Information Owner
|
The term "Information Owner" is the official with statutory or operational authority for specified Sensitive Data and responsibility for establishing the controls for its generation, classification, collection, processing, dissemination, and disposal.
|
Information System
|
The term "information system" means an interconnected set of information resources under the same direct management control that shares common functionality. A system normally includes hardware, software, information, data, applications, communications, and people.
|
Integrity
|
The term "Integrity" means the process of guarding against improper Sensitive Data modification or destruction that also includes ensuring Sensitive Data's non-repudiation and authenticity.
|
Likelihood
|
The term "Likelihood" means a weighted factor based on a subjective analysis of the probability that a given threat is capable of exploiting a given Vulnerability or a set of Vulnerabilities.
|
Operational Environment
|
The term "Operational Environment" means the physical, technical, and organizational setting in which an Information System operates, including but not limited to: business functions; business processes; threat space; vulnerabilities; enterprise and information security architectures; personnel; facilities; supply chain relationships; information technologies; organizational governance and culture; acquisition and procurement processes; organizational policies and procedures; organizational assumptions, constraints, risk tolerance, and priorities/trade-offs.
|
PCIDSS
|
The term "PCIDSS" or "PCI DSS" means Payment Card Industry Data Security Standard which is an information security standard for organizations that handle branded credit cards from the major card schemes.
|
Personally Identifiable Information
|
The term "Personally Identifiable Information" means information that can be reasonably linked to a person, computer, or device. In many cases, persistent identifiers such as device identifiers, MAC addresses, static IP addresses, or cookies meet this test.
[2]
|
Privacy Rule
|
|
Protected Health Information
|
(1) Except as provided in paragraph (2) of this definition, that is:
(i) Transmitted by electronic media;
(ii) Maintained in electronic media; or
(iii) Transmitted or maintained in any other form or medium.
(2) Protected health information excludes individually identifiable health information in:
(i) Education records covered by the Family Educational Rights and Privacy Act, as amended, 20 U.S.C. 1232g;
(ii) Records described at 20 U.S.C. 1232g(a)(4)(B)(iv); and
(iii) Employment records held by a covered entity in its role as employer.
|
Risk
|
The term "Risk" means net mission impact considering (1) the probability that a particular Threat will exercise (accidentally trigger or intentionally exploit) a specific Vulnerability and (2) the resulting Impact if this should occur.
|
Risk Assessment
|
The term "Risk Assessment" means a process by which an Organization identifies the following:
(1)
Threats to the Organization (i.e., Operations, Assets, or Individuals);
(2)
Vulnerabilities internal and external to the Organization;
(3)
The harm (i.e., adverse Impact) that may occur given the potential for Threats exploiting Vulnerabilities; and
(4)
The likelihood that harm will occur.
The result of a Risk Assessment is an overall determination of Risk for the Organization (i.e., typically a function of the degree of harm and likelihood of harm to occur).
[3]
|
Risk Management
|
The term "Risk Management" is a comprehensive global organizational process that contains the following sub-processes: (1) framing Risk-the purpose of the Risk framing component is to produce a Risk Management strategy that addresses how your organization intends to assess Risk, respond to Risk, and monitor Risk; (2) assessing Risk-See the definition of Risk Assessment; (3) responding to Risk-this component determines how your organization responds to Risk in accordance with your Risk Management strategy by developing, evaluating, selecting, and implementing Risk responses; and (4) monitoring Risk-this component determines how your organization tracks Risks over time by verifying that "reasonable and appropriate" Risk responses have been implemented and determining ongoing effectiveness of these responses vis-à-vis a changing Operational Environment
|
Security
|
The term "Security" means all the administrative, physical, and technical safeguards in an information system that were designed, developed and implemented to protect Sensitive Data.
|
Security Controls
|
The term "Security Controls" is the management, operational, and technical safeguards or countermeasures prescribed for an Information System to protect the Confidentiality, Integrity, and Availability of an Information System and its Sensitive Data. Security Controls can be both technical and nontechnical. Technical controls include, but are not limited to, parts of Information Systems hardware and software. For Example, technical controls include access controls, identification, authentication, encryption methods, automatic logoff and audit controls.
|
Security Objects
|
The term "Security Objects" means a kind of inventory. They contain a categorized and classified list of persons, places, processes, devices and other "things" found within your Operational Environment. You apply Security Controls to Security Objects to reduce Sensitive Data related Risks (e.g. loss, destruction, theft, corruption, etc.) to levels that are "reasonable and appropriate."
|
Security Rule
|
The term "Security Rule" ('SR") shall mean the Standards for Security of Electronic Protected Health Information at 45 C.F.R. parts
§160 and
§164, Subparts
A and
C.
|
Sensitive Data
|
The term "Sensitive Data" means any confidential personal data that is protected by applicable law and whose Breach would trigger a Breach Response under Applicable Law. For example, Protected Health Information, Personally Identifiable Information, and payment data all constitute Sensitive Data which are collectively protected by one or more regulatory regimes.
|
Stakeholder
|
The term "Stakeholder" as used in this document, means a person or entity that has an interest in protecting Sensitive Data.
|
State
|
The term ''State'' means each of the several States, the District of Columbia, Puerto Rico, the Virgin Islands, Guam, American Samoa, and the Northern Mariana Islands.
|
Threat
|
The term "Threat" means the potential for a person or thing to exercise (accidentally trigger or intentionally exploit) a specific Vulnerability: (1) natural threats may include floods, earthquakes, tornadoes, and landslides; (2) human threats are enabled or caused by humans and may include intentional (e.g., network and computer based attacks, malicious software upload, and unauthorized access to Sensitive Data) or unintentional (e.g., inadvertent data entry, deletion, and inaccurate data entry) actions; and (3) environmental threats may include power failures, pollution, chemicals, and liquid leakage.
|
Unsecured Sensitive Data
|
The term "Unsecured Sensitive Data" means Sensitive Data that is not rendered unusable, unreadable, or indecipherable to unauthorized individuals through the use of a technology or methodology.
|
Use
|
The term "use" means, with respect to Sensitive Data, the sharing, employment, application, utilization, examination, or analysis of said Sensitive Data within an entity that maintains such information, or as applicable, with a person or entity authorized by the Information Owner pursuant to same.
|
Vulnerability
|
The term "Vulnerability" means a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security Breach or a violation of the system's security policy: (1) Vulnerabilities, whether accidentally triggered or intentionally exploited, could potentially result in a Security Incident, such as an inappropriate use or disclosure of Sensitive Data; and (2) Vulnerabilities may be grouped into two general categories, technical and nontechnical. Non-technical vulnerabilities may include ineffective or non-existent policies, procedures, standards or guidelines. Technical Vulnerabilities may include: holes, flaws or weaknesses in the development of Information Systems; or incorrectly implemented and/or configured Information Systems.
|
Workforce
|
The term "Workforce" means employees, volunteers, trainees, and other persons whose conduct, in the performance of work for an Information Owner, is under the direct control of said Owner, whether or not they are paid by the Owner.
|
[1] The term "Sensitive Data" as defined and used herein means any personal confidential data, the Breach of which is protected by applicable law.
|