Information Security Incident Response Plan

Policy Number: 3349-OP-203
Effective Date: 07/01/2017
Updated: 12/01/2019
Reviewed: —
Responsible Department: Information Technology
Approval Authority: Vice President, Administration and Finance

A. Purpose

To maintain the Confidentiality, Integrity and Availability of University Data and Systems, assist in the identification, reporting and response to Security Incidents, and comply with federal and state law and contractual obligations.

B. Scope

Any event, actual or suspected, which may negatively impact the Confidentiality, Integrity, and/or Availability of NEOMED’s Information Security.

C. Definitions

1. “Availability” refers to the ensuring of timely and reliable access to and use of Data or Systems. A loss of availability is the disruption of access to or use of Data or Systems (e.g., hard drive failure, destruction of a System, System unresponsiveness, denial of service attack).
2. “Confidentiality” refers to the preservation of authorized restrictions on Data access and disclosure, including means for protecting personal privacy and proprietary Data and Systems. A loss of Confidentiality is the unauthorized disclosure of Data (e.g., compromised by hackers; released or published publicly without Authorization).
3. “Data” refers to any instance of information, regardless of form or storage medium, that is categorized by an organization or by a specific law or regulation.
4. “Data Stewards” refers to University employees who are responsible for the management and oversight of University Data within their area(s) to provide authorized Users with such Data that is easily accessible in a consistent manner.
5. “Information Security” refers to the protection of University Data and Systems from unauthorized access, use, disclosure, disruption, modification and destruction with the intent to provide Confidentiality, Integrity and Availability to such Data and Systems.
6. “Insiders” refers to current or former University employees, contractors, or business partners who have access to University Systems and/or non-Public University Data and may use their access to threaten the Confidentiality, Integrity or Availability of such Systems and Data.
7. “Integrity” refers to the guarding against improper Data or System modification or destruction and ensuring authenticity and non-repudiation in the use of Data or Systems. A loss of Integrity is the unauthorized modification or destruction of Data or Systems where such resources can no longer be trusted for use, are not complete, or incorrect.
8. “Private University Data” refers to University Data used to conduct University business for which access must be guarded due to legal, regulatory, administrative, and contractual requirements, in addition to proprietary, ethical, or privacy considerations.
9. “Restricted University Data” refers to University Data that requires the highest level of protection due to legal, regulatory, administrative, contractual, rule, industry standards, or policy requirements.
10. “Security Incident”, also referred to as “Security Incident” or “Information Security Incident”, refers to an adverse event that results in a suspected or known unauthorized disclosure, misuse, alteration, destruction, or other compromise of University Data or Systems.
11. “Service Provider” refers to any person or entity that receives, maintains, processes, or otherwise is permitted access to University Data and/or Systems through its provision of services directly to NEOMED.
12. “System” refers to an information technology resource that can be classified, may have security controls applied, and are organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of University Data.
13. “System Stewards” refers to University employees who are responsible for the management and oversight of University System(s) within their area(s) to provide Authorization and support to Users.
14. “University Data” refers to Data that is created, collected, stored and/or managed in association with fulfilling the University’s mission or its required business functions.
15. “Users” refers to, in respect to this Policy, individuals or Service Providers that have received Authorization, if applicable, to access, use, transmit, dispose of, or receive University Data and/or Systems that may be affected by an Security Incident.

D. Policy Statement

1. NEOMED Information Security Incident Response Plan Overview
   1. The NEOMED Information Security Incident Response Plan (“NISIRP”, and also referred to as “the Plan”) is documented to provide a consistent, well-defined and organized approach for handling Security Incidents, including when an Security Incident at an external organization is traced back to and reported to the University.
   2. Because of the variety of potential Security Incidents, any attempt to take into consideration the technical procedures required to remediate each Security Incident would be incomplete. For that reason, NEOMED’s Plan does not attempt to outline the technical procedures associated with Security Incident handling, but provides a framework within which NEOMED employees can work to ensure a complete and consistent approach to Security Incident response.
   3. Any individual who believes a Security Incident has occurred should follow the steps outlined in this Plan.
2. Roles and Responsibilities
   1. NEOMED Information Security Incident Response Team (“NISIRT”)
      1. The NEOMED Information Security Incident Response Team is responsible for activating and following the NEOMED Information Security Incident Response Plan and is authorized to take appropriate steps to contain and remediate a Security Incident.
      2. The objective of NISIRT is to provide a swift, effective, and skillful response to any Security Incident (i.e., negatively impacting the Confidentiality, Integrity, or Availability of University Data and/or Systems).
      3. NISIRT is led by the Chief Information Technology Office (“CITO”) or a designee named by the CITO. NISIRT members will be engaged as necessary based on the scope and severity of the Security Incident.
   2. NEOMED Executive Management Team Representation
      1. Authorizes resources for NISIRT to respond to Security Incidents;
      2. Guides NISIRT assignment and response to High-Risk Security Incidents, including the activation and implementation of Business Continuity Plan or other University emergency response plans; and
      3. Determines if University-wide production services and programs should be taken offline/down until the Security Incident has been remediated.
   3. Chief Information Technology Officer (CITO)
      1. Serves as an Information Technology (“IT”) Security Contact;
      2. Classifies High-Risk Security Incidents according to the Security Incident Classification criteria;
      3. Responds and directly handles High-Risk Security Incidents;
      4. Provides proper training to NISIRT on Security Incident handling;
      5. Coordinates necessary communication between the NISIRT, the Office of the General Counsel, the NEOMED Police Department, the Office of Marketing and Communication, and other external agencies;
      6. Escalates High-Risk Security Incidents to the Executive Management Team for review and guidance, including potential use of the Business Continuity Plan and other emergency response plans;
      7. Ensures appropriate evidence gathering, chain of custody, and preservation of information/evidence by NISIRT; and
      8. Prepares a written summary of the Security Incident, including any corrective actions taken, and leads the debriefs of Security Incident once remediated.
   4. IT Security Contacts
      1. Performs initial Security Incident classification as High-Risk or Low-Risk;
      2. Escalates all High-Risk Security Incidents to the CITO;
      3. Collects and preserves pertinent information regarding the Security Incident;
      4. Works to contain, remediate, resolve and document Security Incidents; and
      5. Determines if localized production services should be taken offline until the Security Incident has been remediated.
   5. University Department and Office Representation
      1. Various University offices and departments will be engaged as necessary based on the scope and severity of the Security Incident, such as Payment Card Industry-related Security Incidents.
      2. In conjunction with the CITO, the Offices of the General Counsel and Marketing and Communication will handle necessary communication between the University, public, and media.
      3. As needed, University departments and offices will support the NISIRT by:
         1. Assisting with proper evidence handling;
         2. Ensuring compliance with University policy and federal, state and local laws; and
         3. Managing disciplinary actions for Security Incidents involving University employees and/or students.
   6. Supporting Roles
      1. Data Stewards, System Stewards and Service Providers
         1. Reports Security Incidents;
         2. Collects and provides pertinent information regarding Security Incidents at the request of the CITO or IT Security Contacts;
         3. Implements controls specified by NISIRT; and
         4. Monitors the affected University Data and/or Systems for signs of attack, unauthorized access or unauthorized disclosure.
      2. Users
         1. Reports Security Incidents; and
         2. Collects and provides pertinent information regarding Security Incidents at the request of NISIRT to help in determining the root cause of the Security Incident.
3. Communications
   1. Information and communication related to Security Incidents and corresponding responses must be treated on a “need to know” basis and will be classified, handled and safeguarded as Private University Data.
   2. Depending on the severity and scope of a given Security Incident, University Systems may be unavailable for use; therefore, status updates regarding Security Incidents and the University’s response to such Security Incidents will be made based upon System Availability and Security Incident severity and scope.
   3. For Payment Card Security Incidents, the Office of Accounting and Budget, in consultation with the Office of the General Counsel, will provide notification and delivery of documentation to the appropriate card processors, banks, and credit card brands based on the scope and severity of the Security Incident (refer to Section 8 for Payment Card Brand Reporting Guidelines).
4. Documentation of Security Incidents and Response Actions
   1. Security Incidents and actions that are performed in response to Security Incidents are expected to be documented throughout the phases of the NISIRP.
   2. All documentation should be chronological, date/time-stamped, include exact commands entered into University Systems, results of such commands, any actions taken (e.g., logging on, disabling accounts, applying network filters, etc.) and any other observations about the University System(s) and/or Security Incident.
   3. All documentation should be provided to the CITO as a part of the Post-Security Incident Activity phase of the NISIRP.
5. NEOMED Information Security Incident Response Plan – Phases
   1. The University will follow a customized version of the Security Incident Response process outlined within National Institute of Standards and Technology (NIST) 800-61 for its Information Security Incident Response Plan.
   2. Based on the investigation, it may be necessary to repeat some of the NISIRP phases; however, once a Security Incident is detected, the NISIRP should be followed through to completion.
   3. Preparation – Phase One
      1. The Preparation phase involves readying NISIRT to handle Security Incidents and preventing Security Incidents from occurring to the best extent possible.
      2. Security Incident handling requires a variety of tools and resources to be effective, including communication tools, University facility space, and analysis hardware and software. NISIRT will have periodic discussions with the Executive Management Team to determine any gaps in tools and resources needed to effectively handle future Security Incidents.
      3. Preventing Security Incidents involves ensuring that University Systems, including networks and applications, are sufficiently secure. This is facilitated by conducting periodic Information Security risk assessments, University System hardening, reviews of network and firewall configurations and University awareness and training related to the appropriate use of University Data and Systems.
   4. Detection & Reporting – Phase Two
      1. Detection
         1. Security Incidents may arise from a variety of adverse events, including, but not limited to:
            1. A violation of IT policies;
            2. The compromise of non-Public University Data, such as cardholder data (from payment cards) and personally identifiable information (PII).
            3. Theft of University Systems and Computing Devices;
            4. Denial of Service attacks;
            5. Social engineering activity and account compromises; and
            6. Other misconfiguration that may lead to unauthorized access to University Data or Systems.
         2. Detection of Security Incidents occurs through a variety of channels, including, but not limited to:
            1. External reports (i.e., agencies, Service Providers, other third parties);
            2. Monitoring of University System logs and vulnerability scans;
            3. Automated alerts/reports to University employees; and
            4. Internal employee detection (i.e., detected deviation from normal operations).
      2. Internal Reporting
         1. Any of the following methods may be used to report a Security Incident:
            1. Phone
               1. CITO and IT Security Contacts:
                  1. Ronald McGrady, CITO, IT Department – 330 325-6799
                  2. Todd Felmly, Manager, Desktop & Infrastructure, IT Department – 330-325-6249
                  3. Jonathan Wagner, Information Security, Training & Compliance Manager, IT Department – 330-325-6243
               2. NEOMED Help Desk – (330) 325-6911
               3. NEOMED Police Department – (330) 325-5911
               4. NEOMED Anonymous Reporting Hotline – (844) 254-3070
            2. Email
               1. itsecurity@neomed.edu
               2. help@neomed.edu
               3. security@neomed.edu
            3. Online
               1. NEOMED Anonymous Reporting Hotline –https://www.neomed.edu/compliance
         2. Upon receival of the report, the receiving party will reply to the individual’s initial report as soon as possible to confirm awareness of the Security Incident. In some circumstances, escalation of Security Incidents is needed:
            1. In scenarios in which a person is not available or does not respond within 15 minutes after reporting, the submitting party should escalate the Security Incident by calling an IT Security Contact if they were not previously contacted (or calling a different IT Security Contact if one was previously contacted and did not respond).
            2. Upon this escalation, if the IT Security Contact is not available or does not respond within 15 minutes after reporting, the submitting party should then escalate the Security Incident again by calling the CITO (or Vice President of Administration and Finance if CITO was already contacted as an IT Security Contact).
   5. Analysis – Phase Three
      1. Upon detection and/or report, IT Security Contacts will perform an analysis of the Security Incident to determine:
         1. The appropriate classification of the Security Incident;
         2. The priority of the response to the Security Incident; and
         3. Whether NISIRT activation is necessary, and if so, the appropriate University personnel to be involved.
      2. Classification and Prioritization
         1. Security Incidents will be classified as either Low-Risk or High-Risk based upon the functional and informational impacts of the Security Incident and whether it resulted in actual compromise.
         2. Security Incidents that meet any of the following criteria will be considered High-Risk Security Incidents:
            1. There is a reasonable likelihood that the Confidentiality, Integrity and Availability of Private or Restricted University Data was/is compromised;
            2. There is a reasonable likelihood the University may not or cannot be able to provide one or more High-Risk (critical) University Systems (e.g., infrastructure, applications or University Data found within such Systems);
            3. There is a reasonable likelihood that the Confidentiality, Integrity and Availability of University Data and/or Systems that are subject to legal, regulatory, contractual, grant, or University policy requirements was/is compromised; and/or
            4. There is a reasonable likelihood that the Security Incident has resulted or may result in financial theft, loss of intellectual property, physical harm to any person or to University property or compromise of additional University Data or Systems.
         3. Security Incidents that do not meet any of the High-Risk criteria will be considered Low-Risk Security Incidents.
      3. Prioritization of responses to Security Incidents will be determined by:
         1. The classification of the Security Incident; and
         2. The level of and type of resources needed to recover from the Security Incident (recoverability effort).
      4. Once the Security Incident is classified and prioritized, the CITO or their designee will determine whether NISIRT activation is necessary, and if so, the appropriate University personnel to be involved. Upon activation of NISIRT, the CITO or their designee will notify the appropriate University employees, departments and offices of their involvement in Security Incident Response, either as a part of NISIRT or as a support role.
      5. If upon discovering evidence of a criminal offense occurring, the NEOMED Police Department will be notified whereupon they may collaborate with other federal, state, and local law enforcement agencies as appropriate. A criminal investigation may be conducted in parallel to, may supersede, or may require further authorization for any additional actions to be taken by the University.
      6. Forensics
         1. Forensic efforts should supplement the analysis of the Security Incident by determining the origination of the Security Incident, the Systems affected, the University Data compromised, and the likelihood of recurrence.
         2. An external forensics vendor or contractor may be engaged dependent on the severity and scope of the Security Incident.
            1. For Payment Card Security Incidents, external forensic contracting may be required by one or more of the affected Payment Card Brands.
            2. External forensic engagement is conditional on the approval by the Vice President of Administration and Finance. Such an engagement can be in absence of or in conjunction with a criminal forensic process.
   6. Containment – Phase Four
      1. NISIRT must contain the Security Incident as soon as possible to limit the exposure to the compromised University Data and/or Systems, preserve potential evidence and prepare for an investigation of the Security Incident.
      2. A Security Incident is considered contained when no additional harm can be caused and NISIRT is able to focus on the remediation of the Security Incident.
      3. Containment consists of three stages:
         1. Initial containment (stopping the progress of the Security Incident/attacker as soon as the Security Incident is first detected);
         2. Information gathering; and
         3. Continuing containment (making changes to the production system to address Security Incident recurrence).
   7. Eradication & Recovery – Phase Five
      1. After the Security Incident has been contained, eradication may be necessary to eliminate elements of the Security Incident (e.g., removing malware, disabling compromised user accounts and/or affected hosts) and to identify and mitigate all vulnerabilities that were exploited. For some Security Incidents, eradication is either not necessary or is performed during recovery.
      2. In recovery, NISIRT will work to restore University Systems to normal operation, confirm that the Systems are functioning normally and remediate vulnerabilities found to prevent similar Security Incidents, if applicable.
         1. This can include restoring University Systems from backups, rebuilding servers and other University Systems from scratch, replacing compromised files with clean versions, higher levels of System logging, installing patches, changing passwords and tightening the University network perimeter security (e.g., firewall rulesets, boundary router access control lists).
      3. The time needed for this phase of Security Incident Response varies depending on the severity of, scope of and effort needed to recover from a Security Incident. Early recovery phases of large-scale Security Incidents will be focused on increasing the University’s overall security with relatively quick, high-value changes while later phases will focus on longer-term changes (e.g., changes to infrastructure controls) to keep the University as secure as possible.
      4. NISIRT may request additional internal and external resources required to carry out the eradication of and recovery from any Security Incident. Such requests may require approval from the Vice President of Administration & Finance.
   8. Post-Security Incident Activity – Phase Six
      1. After eradication and recovery, the CITO or designee will complete a Security Incident Handling Report.
         1. This Report can be used to assist the University in handling similar Security Incidents and should contain a formal chronology of events (including timestamped information, such as log data from University systems) and any organizational and/or financial resources used in response.
      2. Debrief Meetings
         1. Debrief meetings are required after High-Risk Security Incidents and will include all involved parties. Debrief meetings for Low-Risk Security Incidents are optional; however, a meeting should be held if the Security Incident was performed through new attack methods that are of widespread concern and interest.
         2. Debrief meetings will be scheduled and led by the CITO or designee. The meeting will discuss the security controls that failed, review any identified root causes and establish any necessary steps to mitigate the risk of the Security Incident reoccurring.
6. Sanctions
   1. Any individual to have been found willingly, intentionally, or purposefully withholding information related to a suspected or confirmed Security Incident may be subject to disciplinary action and sanctions, up to and including, termination or dismissal.
7. Policy Testing and Review
   1. The NEOMED Information Security Incident Response Plan should be tested annually. The IT Department will collaborate with other offices and departments, such as the Office of Accounting and Budget for Payment Card Security Incidents, to coordinate testing and assess the suitability of the current Plan.
   2. This Policy and Plan will be reviewed annually to ensure its applicability to the current University environment and to address any changes to the University’s technology or organizational environments. Also, upon recovery from High-Risk Security Incidents and following testing of the Plan, this Policy should be reviewed to determine if the NISIRP can be revised to improve future Security Incident response.
8. Payment Card Brand Reporting Guidelines
   1. For Security Incidents involving Payment Cards of Payment Card Brands, please refer to the specific Security Incident response guidance below. In most cases, additional specific requirements will be given by the Payment Card Brands, so follow such requirements as appropriate. Questions regarding such reporting should be referred to the NEOMED Information Security Incident Response Team.
   2. American Express – Incident Response
      1. Notification: 1-888-732-3750 (toll free); 1-602-537-3021; or ENISIRP@aexp.com
      2. Guidance
         1. https://www.americanexpress.com/content/dam/amex/hk/en/staticassets/merchant/pdf/support-and-services/useful-information-and-downloads/DataSecurityOperationPolicyMerchants.pdf*
         2. https://www.americanexpress.com/us/security-center/
      3. Discover – Incident Response
         1. Notification: 1-800-347-3083
         2. Guidance: https://www.discoverglobalnetwork.com/en-us/business-resources/fraud-security/
      4. MasterCard – Incident Response
         1. Notification: account_data_compromise@mastercard.com
         2. Guidance: https://www.mastercard.us/content/dam/mccom/en-us/documents/rules/SPME-Manual-February-2019.pdf*
      5. Visa – Incident Response
         1. Notification: 1-650-432-2978 or usfraudcontrol@visa.com
         2. Guidance: https://usa.visa.com/support/small-business/data-security.html

Download the Policy*