Introduction
This is Part 2 of a 2-Part Article. Part 1 is located here. In this Part, we provide a high-level introduction regarding what each team's responsibilities during a Breach Response. Remember, in any Breach Response you are working with a team of teams. Also, recall why we believe a tech-savvy law firm("TSLF") should function as the general manager ("GM") of this team of teams. We will expand on this proposition herein as well. We have inserted the Definitions section below, as it should prove useful once again for the topics covered in this 2-Part Article.
Teams
The following is not an exhaustive list of teams that would need to participate in a Breach Response because each organization is different. That said, we believe that this list of teams captures a significant percentage of the players that would of necessity need to participate in a Breach Response.
Executive Management Team
The Executive Management Team ("EMT") is obviously the hiring authority. It's the EMT that will make the decision of how the organization's Response will be formulated. Depending on the organization, the "in-house" authority will then be transferred to either in-house counsel or the CO. However, before any such transfer takes place, the EMT will have to be educated regarding Response costs, legal liability, reputation damage and control, etc.
Partners
Your Partners (e.g. Legal, Forensics, Public Relations, Identity Protection, etc.) will play a critical role in your Response. When you operationalize your Plan, by including key partners in pre-Response planning whenever possible, you will generally find your Response to be more effective and efficient, likely saving you tens of thousands of dollars. If your Team works together pre-Response and develops a conceptual "Table Top" Response (i.e. in those areas where Partners will play a critical role), then you can be more cautiously optimistic about the timeliness and productivity encompassed by the Plan.
Legal
We have briefly mentioned why a TSLF should be the general manager ("GM") of your Response initiative. Here we spell out the reasons why a TSLF is the most effective GM for your Response. First all, it's clear that Legal is going to play an important role in any Response, but what may not be apparent to the EMT (or in-house staff) is the scope of the Legal issues that touch almost every facet of the Response. For example, although determining whether Breach Notification is triggered may look like a technical task on its face, Breach Notification requires legal analysis unique to each regulatory regime implicated. Under HIPAA, for example, a three-step analytical legal framework must be traversed.
Compliance
Although your Compliance Team will certainly play a key role in the Response, this team's leader may not be best suited to perform the role of GM. First, in far too many organizations the CO title has been foisted on another employee (e.g. the CIO or the "Office Administrator") that is already wearing too many hats to be effective in this role. Second, this individual usually does not have the "position power" within the organization to make his or her voice heard loud enough to demand the staff and resources required to get the job done.
Forensics
The Forensics Team does the heavy lifting of evidence gathering once the bad guys have infiltrated your network. This team is looking for what got misappropriated once one of potentially hundreds of thousands of "attack vectors" have been penetrated. What has been weaponized, how did the bad guys weaponize it, and what valuable data was taken (e.g. IP, PHI, PII, or the corporate "crown jewels")? This team focuses more on the what and how rather than the who. The team wants to understand the Chain of Custody and all things related to it. The Forensics Team, by definition, deals with a much wider scope problem, then the challenges faced by a typical Information Technology ("IT") department or vendor. The scale of the problem also impacts the skill sets required to deal with it. For example, a forensics team may have to deal with a multiplicity of natural languages, programming languages, tools, databases, and other challenges that rarely occur during the day-to-day operation of IT.
Information Technology
The Information Technology team will play a critical role during a Response-that much is obvious. Depending on the organization, the IT Team will likely be engaged in the following activities: (1) documenting the facts surround the initial trigger event (i.e. Incident) that precipitated the Breach Analysis including the particular type of SD that may have been compromised; (2) identification of the Information System(s) wherein SD may have been compromised; (3) making the initial contact with the GM that is charged with managing the Response; (4) first determination of the kind of encryption that may exist for the Information Systems in question[1]; (5) prepare the list of customers that may have been compromised through database queries and other mechanisms; (6) preserve all network scan reports, application logs, networks logs, and other similar evidentiary materials to be used by the Forensics Team; and (7) take whatever initial remediation steps are within the IT Team's capabilities to effectuate in order to plug the Vector that led to the Breach.
Public Relations
The role of the Public Relations ("PR") Team during a Response cannot be underestimated. It is essential that all Response messaging be directed by one central point of contact (i.e. even though multiple spokespeople may participate). Information to various stakeholders (e.g. customers, regulatory agencies, shareholders, employees, the media, etc.) should be done on a need to know basis. This does not imply that the PR effort should be opaque, it should indeed be fully transparent, within the bounds of not giving the "bad guys" any information that could be used to further damage the organization, or other organizations.
Identity Protection
It is now expected that organizations that experience a Breach will provide identity protection services to the customers whose SD was compromised. Identity protection is not merely a service that an organization purchases but rather a team whose expertise is critical to maintaining the organization's promises as delivered by the PR team. This is a relationship that should be in place as part of an organization's Preparedness planning and some ad hoc "bolt on" that happens after a Breach. A quality Identity Protection team usually offers services that extend beyond the obvious, including but not limited to: (1) assisting in preparedness planning (i.e. this won't be their first rodeo); and (2) printing and mailing letters with address verification. This is of course in addition to fraud detection and resolution.
Customer Service
The role of the Customer Service Team is much greater than simply answering fraud protection questions, although the latter is not trivial. Customer Service should take the lead role in working with the IT and PR Teams to have already designed an Internet presence "ready to go" the moment a Breach happens. Why Customer Service (which here includes the Sales and Marketing teams)? Because these are the employees within your organization best suited to design an Internet presence with the customer in mind. This should not be simply a "throw away" page with 800 numbers and an FAQ. That approach risks the ability to take lemons and make lemonade. Customer Service should design an Internet presence that actually helps customers think through all difficult decisions they may need to make because of the Breach. These decisions will differ by organization, but may include: (1) canceling credit cards; (2) ensuring that PHI is updated; (3) signing up with the identity protection program; (4) patterns to detect fraud and abuse; etc.
Collaboration
It should be clear from the above list of team functions that there's a significant amount of collaboration and coordination that needs to occur in order to produce an effective Breach Response. Imagine the difficulty if the individuals within each team have never met or talked with one another, let alone collaborated on a plan. The role of the TSLF is to bring all these collaborators together before a Breach occurs so that everyone knows their role and the sequence of events that need to happen before their respective tasks are triggered.
This is not unlike FEMA collaborating with state and local governments, NGOs, and others prior to a category five hurricane slamming the U.S. or its territories. In other words, there's a significant amount of planning that goes into a Breach Response. If you have no plan and you are just "winging it" then you can expect Equifax like results. Breach Response is not a job for amateurs. The petulant children that may want to play a role because of their "position power" within an organization need to be respectfully put in "time out." This is serious business.
Why a TSLF as GM?
Our argument is that there is a multitude of legal issues that touch almost every facet of a Breach Response and many have a "technical" component associated with them. For example: (1) identifying when Breach Notification is triggered under a particular regulatory regime; (2) ensuring that the forensic evidence is gathered in a manner that will facilitate eDiscovery production when the inevitable lawsuit is filed; (3) ensuring that the appropriate contracts are in place between your organization and whatever third parties you engage to help you prosecute the Response; (4) advising the BOD and the EMT that they are likely to face legal jeopardy if they start selling shares before the Breach becomes public (e.g. Equifax); (5) working with PR to ensure that they have the correct facts before they start communicating with the public; (6) working with regulatory agencies as they investigate the Breach; and (7) the list goes on and on.
We should clarify what a "technical component" encompasses: (1) the legal and technical expertise to interpret cybersecurity centric regulatory regimes so that your organization responds in a legally appropriate manner; and (2) having sufficient technology experience to effectively interact with technical teams participating in the response. It's a challenge to find the cross-functional expertise to effectively function as a Breach Response GM. Like everything else related to a Breach Response, your organization should seek to establish relationships with GM talent long before a Breach Notification has been triggered.
________________________________________
[1] The Forensics Team will be called upon to make the final determination.
Definitions
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
The term "Privacy Rule" ("PR") shall mean the Standards for Privacy of Individually Identifiable Health Information at 45 CFR Part 160 and Part 164, Subparts A and E.
Protected Health Information
The term ''Protected Health Information'' ("PHI") means individually identifiable 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.
Source: 45 CFR § 160.103; see also 13400 (12) of the HITECH Act.
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 §160and §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.
[2] See the FTC expanding the definition of "Personally Identifiable" circa April 2016.
[3] The NIST Special Publications ("SP") uses Risk Assessment as synonymous with a Risk Analysis. See NIST SP 800-30.
