Security Notification Breach Notification Policy

An information technology (IT) security incident is an event involving an IT resource at ScaleWP (SWP) that has the potential of having an adverse effect on the confidentiality, integrity, or availability of that resource or connected resources. Resources include individual computers, servers, storage devices and media, and mobile devices, as well as the information, messages, files, and/or data stored on them. Prompt detection and appropriate handling of these security incidents is necessary to protect ScaleWP’s information assets and to preserve the privacy and confidentiality of personal data.

The purpose of this IT Security Information Breach Notification Policy is to provide general guidance to SWP to enable quick and efficient recovery from security incidents; respond in a systematic manner to incidents and carry out the steps necessary to handle an incident; and minimize disruption to critical computing services or loss or theft of sensitive or mission critical information.

The sections below describe: 1) Who to notify upon discovery of an incident; 2) procedures for handling and recovering from an incident in a manner appropriate to the type of security incident; and 3) how to establish a reporting format and evidence retention procedure. This document provides an overview of the process. Any questions about this Policy should be directed to: [email protected].

In the event of a Breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, GDPR Data (“GDPR Breach”), SWP is legally required to assess the risks to data subjects and may be required to notify data protection authorities and affected data subjects.

“GDPR Data” includes any personal information that is transmitted, stored, or otherwise processed by SWP relating to an identified or identifiable natural person that is subject to the European Union (EU) General Data Protection Regulation (“GDPR”). An identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, or an online identifier, or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural, or social identity of that natural person. For further guidance as to which personal information is subject to the GDPR, please consult with SWP’s GDPR Data Protection Officer (the “DPO”).

In order to comply with the requirements of the GDPR, it is critical that all of the steps outlined in this Policy occur within seventy-two (72) hours of the first point at which an incident is discovered. In all cases, regardless of jurisdiction, the process must be completed as expeditiously as is reasonably feasible.

In the United States, state legislatures increasingly have imposed significant privacy-security obligations, especially regarding computerized data. Although the particulars (e.g., type, timing, and target) vary from state to state, all 50 states and the District of Columbia require disclosure of a breach.

Under Missouri’s data breach reporting law, whenever there is a breach of certain types of computerized personal data of a Missouri State resident, the breach must be reported to the affected individuals in the most expedient time possible and without unreasonable delay and also the Missouri Attorney General, Department of State, and Division of State Police must be notified. For more information about the Missouri breach reporting law, see Appendix D. In the event of a potential breach, an analysis should also be performed in consultation with the Office of General Counsel to determine whether the data breach reporting laws of any other states may be implicated.

When a security incident is detected or reported, key first steps are to (1) contain the incident, (2) initiate an investigation of its scope and origins, and (3) decide if it qualifies as a Breach.

1. Incident Handler: This role is filled by IT security staff from SWP IT.
2. System Administrator: This role is filled by the technical staff responsible for deploying and maintaining the system at risk. Also referred to as a “first responder” in the context of this process.
3. System Owner: This role is filled by the staff member or management member who has responsibility for the business function performed by the system. The System Owner is not necessarily the person who paid for the system, but rather the person who has control over it.
4. Network Operations: This role is filled by the technical staff responsible for network infrastructure at the site housing the system at risk. At Washington Square, this is SWP IT Networking Services.
5. PCI Compliance Manager: This role is filled by the person responsible for overseeing SwP’s PCI compliance program.
6. DPO: This role is filled by SWP’s GDPR Data Protection Officer, who may be assisted by designated Data Protection Officers at each of SWP’s Global Sites in the EU.

The identification phase of incident response has as its goal the discovery of potential security incidents and the assembly of an incident response team that can effectively contain and mitigate the incident:

1. Identify a potential incident. The incident handler may do so through monitoring of security sensors. System owners or system administrators may do so by observing suspicious system behavior. Any member of SWP may identify (i.e., detect) a potential security incident though external complaint/notification, or other knowledge of accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, High Risk Data or GDPR Data.
2. Notify: SWP members that suspect an IT system or paper-based files have been subject to accidental or unlawful destruction, loss, or alteration, or unauthorized disclosure or access, must immediately report the situation to [email protected]. Once the incident handler is aware of a potential incident, s/he will alert local system administrators. If an incident is discovered by a member of the Covered Component or Support Component or by a Business Associate, the person should notify GOIS and the relevant Covered Component’s or Support Component’s HIPAA EPHI Security Officer and HIPAA Privacy Officer immediately, and follow GOIS’ instructions on how to proceed. No one should interact with the system, unless approved by GOIS.
3. Quarantine: The incident handler will quarantine compromised hosts at the time of notification unless they are on the Quarantine Whitelist. If they are on the Quarantine Whitelist, the incident handler will promptly reach out to the system administrator or system owner to create a plan to contain the incident. Note that the incident handler may notify on suspicious behavior when s/he is not confident of a compromise; in these cases, they do not quarantine the host immediately, but wait 24-48 hours and quarantine only if the registered contact is unresponsive.

This phase also precedes CIR, and has the primary goal of confirming that the compromise is genuine and presents sufficient risk to engage the CIR process:

1. Classify: The CIR must be initiated if…
   1. The system owner or system administrator indicates that the system is a High Criticality System. The system owner or system administrator asserts that the system contains High Risk Data
   2. or someone of appropriate authority (for example, an SWP IT Associate Vice President or higher) determines that the system poses a unique risk that warrants investigation.
2. Verify: The CIR process should be initiated only if…
   1. The incident handler verifies that the triggering alert is not a false positive. The incident handler will double-check the triggering alert, and correlate it against other alerting systems when possible.
   2. and the type of data or system at risk is verified to be of an appropriate classification, as determined above. The system owner or system administrator should provide a detailed description of the data at risk, including approximate numbers of unique data elements at risk, and the number, location, and type of files it is stored in.

The order of the steps above can vary from incident to incident, but for the CIR process to be initiated the criticality of the asset must be confirmed, and it must be confirmed that the triggering event is not a false positive. In cases where the CIR process is not required, the incident handler can resolve the case as follows:

1. Obtain a written (email is acceptable and preferred) statement from the system owner or system administrator documenting that the system has no High Risk Data or GDPR Data and is not a high-criticality asset.
2. Obtain a written statement from the system owner or system administrator that the system has been reinstalled or otherwise effectively remediated before quarantine is lifted.
3. Obtain a written statement that the access point has been disabled for incidents involving an unauthorized wireless access point.

The containment phase represents the beginning of the CIR workflow and has the following goals:

1. If the host cannot immediately be removed from the network, the incident handler will initiate a full-content network dump to monitor the attacker’s activities and to determine whether interesting data is leaking during the investigation.
2. Eliminate attacker access: Whenever possible, this is done via the incident handler performing network quarantine at the time of detection and by the system administrator unplugging the network cable. In rare cases, the incident handler may request that network operations staff implement a port-block to eliminate attacker access. In cases where the impact of system downtime is very high, the incident handler will work with system administrators to determine the level of attacker privilege and eliminate their access safely.
3. The incident handler will collect data from system administrators in order to quickly assess the scope of the incident, including:
   1. Preliminary list of compromised systems
   2. Preliminary list of storage media that may contain evidence
   3. Preliminary attack timeline based on initially available evidence
4. Preserve forensic evidence:
   1. System administrators will capture first responder data if the system is turned on. The incident handler will provide instructions for capturing this data to the individual performing that task.
   2. The incident handler will capture disk images for all media that are suspected of containing evidence, including external hard drives and flash drives. System administrators will deliver the system to GOIS after the first responder data is captured; disk imaging and analysis will occur at GOIS. The system owner should expect to have it returned within five (5) business days.
   3. The incident handler will dump network flow data and other sensor data for the system.
   4. The incident handler will create an analysis plan to guide the next phase of the investigation.

This is the most time-sensitive and also the most contextually-dependent phase of the investigation. The actions that need to be taken will depend on the uptime requirements of the compromised system, the suspected level of attacker privilege, the nature and quantity of data at risk, and the suspected profile of the attacker. The most important goals of this phase are to eliminate attacker access to the system(s) as quickly as possible and to preserve evidence for later analysis.

Additionally, this is the phase where the incident handler works most closely with system administrators and system owners. During this phase they are expected to take instruction from the incident handler and perform on-site activities such as attacker containment, gathering first response data, and delivering the system to GOIS in cases where host-based analysis is required.

The analysis phase is where in-depth investigation of the available network-based and host-based evidence occurs. The primary goal of analysis is to establish whether there is reasonable belief that the attacker(s) successfully accessed High Risk Data or GDPR Data on the compromised system. Secondary goals are to generate an attack timeline and ascertain the attackers’ actions. All analysis steps are primarily driven by the incident handler, who coordinates communications between other stakeholders, including system owners, system administrators, and relevant compliance officers. Questions that are relevant to making a determination about whether data was accessed without authorization include:

1. Suspicious Network Traffic: Is there any suspicious or unaccounted for network traffic that may indicate data exfiltration occurred?
2. Attacker Access to Data: Did attackers have privileges to access the data or was the data encrypted in a way that would have prevented reading?
3. Evidence that Data Was Accessed: Are file access audit logs available or are file system mactimes intact that show whether the files have been accessed post-compromise?
4. Length of Compromise: How long was the host compromised and online?
5. Method of Attack: Was a human involved in executing the attack or was an automated “drive-by” attack suite employed? Did the tools found have capabilities useful in finding or exfiltrating data?
6. Attacker Profile: Is there any indication that the attackers were data-thieves or motivated by different goals?

The analysis will include an evaluation of the likelihood of risk to data subjects, including, for example, risks related to identity theft or fraud, financial loss, damage to reputation, and discrimination. The analysis should include whether the data has been encrypted, coded, or protected through other technological controls from use by an unauthorized person. The process and facts considered in reaching a determination as to the likely risks to data subjects must be documented.

In the case of a potential breach of Private Information, GOIS will conduct a risk assessment to determine the probability that a “breach of the security of the system” has occurred, which is defined under Missouri law to mean an unauthorized access to or acquisition of, or access to or acquisition without valid authorization of, computerized data that compromises the security, confidentiality, or integrity of Private Information maintained by SWP. Good faith access to, or acquisition of, Private Information by an employee or agent of SWP for the purposes of SWP is not a breach of the security of the system, provided that the Private Information is not used or subject to unauthorized disclosure.

In determining whether information has been accessed, or is reasonably believed to have been accessed, by an unauthorized person or a person without valid authorization, GOIS may consider, among other factors, indications that the information was viewed, communicated with, used, or altered by a person without valid authorization or by an unauthorized person.

In determining whether information has been acquired, or is reasonably believed to have been acquired, by an unauthorized person or a person without valid authorization, GOIS may consider the following factors, among others:

1. indications that the information is in the physical possession and control of an unauthorized person, such as a lost or stolen computer or other device containing information; or
2. indications that the information has been downloaded or copied; or
3. indications that the information was used by an unauthorized person, such as fraudulent accounts opened or instances of identity theft reported.

At the conclusion of the analysis, but before the final report is written, a peer review should be requested of the other GOIS technical staff. Then, the write-up of the notes should be completed, including conclusions, and processed source materials (e.g., grep-results, file-timelines, and filtered flow-records) should be archived. The peer review may result in some issues that must be addressed and some issues that may optionally be addressed. All recommendations should be resolved or acknowledged and deferred. The incident handler’s role is to determine, from a technical perspective, whether there is a reasonable belief that High Risk Data or GDPR Data, including PHI/EPHI, was available to unauthorized persons. The determination of whether the circumstances warrant a Breach notification will be made jointly by the SWP Officials convened upon review of the results of the investigation, the technical opinion of GOIS, and the advice of the Office of General Counsel.

The primary goal of the recovery phase is to restore the compromised host to its normal business function in a safe manner.

1. The system administrators will remediate the immediate compromise and restore the host to normal function. This is most often performed by reinstalling the compromised host; although if the investigation confirms that the attacker did not have root/administrator access other remediation plans may be effective.
2. The system administrators will make short-term system, application, and business process changes to prevent further compromise and reduce operating risk.

The final report serves two (2) main purposes. First, a recommendation is made to the Office of General Counsel and relevant compliance officers as to whether the incident handler and the responsible officials feel there is a reasonable belief that High Risk Data or GDPR Data was subject to accidental or unlawful destruction, loss, or alteration, or unauthorized disclosure or access, and the degree of probability of risks to data subjects or that the security or privacy of any data has been compromised. The report must be made in sufficient time to allow notification, if appropriate, within any legally-mandated time period. As noted, under the EU GDPR, notification to authorities must occur, wherever feasible, within seventy-two (72) hours of discovery of a GDPR Breach. Under the MO data breach reporting law, notification must be made in the most expedient time possible and without unreasonable delay. Second, a series of mid-term and long-term recommendations are made to the owners of the compromised system/files, including responsible management, suggesting improvements in technology or business process that could reduce operating risk in the future.

1. The incident handler will draft the final report after the investigation is complete. Preliminary reports should be avoided whenever possible since working conclusions can change substantially through the course of an investigation.
2. After the draft report is completed, signoff on the content of the report should be obtained from GOIS management. Technical personnel can offer comments now as well, but typically technical issues should be resolved by this stage. Again, a list of issues will be raised which should be resolved or acknowledged/deferred until GOIS management accepts the report.
3. For critical incidents involving payment card data, the PCI Compliance Manager will receive a copy of the report and appropriate entities will be notified in the event that cardholder data is accessed without authorization. The PCI Compliance Manager will be responsible for all communication with the payment card brands and will be responsible for coordinating the activities mandated by the payment card brands with respect to the incident.
4. For incidents involving GDPR Data, the report will address each accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, GDPR Data. The notification procedure outlined in Appendix A will be followed.
5. If appropriate, given the analysis, the incident handler will obtain sign-off from the Office of General Counsel on the report.
6. The incident handler will schedule a meeting to deliver the final report to the system administrator, the system owner, as well as to responsible officials. Although the correct management contact will vary on a case-by-case basis, it should typically be Director-level or above. Do not distribute electronic copies of the report via email.
7. The incident handler will ensure that the final report includes the details of the investigation and mid-term and long-term recommendations to improve the security posture of the organization and limit the risk of a similar incident occurring in the future.

1. The incident handler will archive the final report in case it is needed for reference in the future; reports must be retained for six (6) years.
2.  Incident notes should be retained for six (6) months from the date that the report is issued. This includes the confluence investigation page, processed investigation materials like grepped file-timelines and filtered network-flows, etc.
3. Raw incident data should be retained for thirty (30) days from the date that the report is issued. This includes disk-images, unfiltered netflow-content, raw file-timelines, and other data that was collected but deemed not relevant to the investigation.
4. Request Tracker (RT) tickets from the GOIS ticketing system related to the investigation should be retained for three (3) years.