Information Security Incident Management Guidelines

Transcription

1 Information Security Incident Management Guidelines INFORMATION TECHNOLOGY SECURITY SERVICES Version #1.0, June 21, 2006 Copyright 2006 by The Regents of The University of Michigan All rights reserved. This document may be reproduced or reprinted, in whole or in part, without permission as long as the above copyright statement and source are clearly acknowledged. This publication or any reproductions may not be sold. Copyrights, trademarks, and service marks referred to in this documentation are the property of their respective owners.

2 Table of Contents Purpose and Scope...3 Objectives...3 Guidelines...4 Incident Management Processes...4 Incident Management Database...8 Protection of Incident Information...8 Retention of Incident Information...9 Roles and Responsibilities...9 References...9 Appendix A: Information Security Incident Management Standards...10 Incident Severity Definition...10 Incident Data Fields...11 Incident Types...13 Page 2 of 13

3 Purpose and Scope This document provides University wide guidelines for reporting and managing information security incidents across the University and supplements the Information Security Incident Reporting Policy (SPG xxx). The guidelines clarify the responsibilities and the process for information security incident reporting and management and specify standard information that needs to be gathered to support an effective incident management process. Additional University wide and unit level procedures will be established to address specific aspects of the incident management process. Definitions of terms used in this guideline are provided in the Data Management and Protection Common Definitions guideline (TBD). These guidelines apply to all users of the University information resources on all campuses as well as to users accessing University information resources from outside the campuses. The guidelines apply to users regardless of the ownership and administration responsibilities of the computers that they use. Information security incidents covered under these guidelines are incidents that meet the definition provided in the SPG xxx. Objectives The University of Michigan is committed to free and open exploration of knowledge and to providing its community with access to local, national, and international sources of information. Increased reliance of the community on information technology resources, combined with an increase in the number of incidents that threaten the security of these resources, require members of the University community to assume an active role in detecting, reporting, and properly handling information security incidents. A growing number of federal, state, and industry regulations require formal procedures for security incident reporting and for timely notification of potential security breaches to affected individuals. While information security incidents are not always preventable, appropriate procedures for incident reporting and handling, combined with increased awareness and education of members of the University community, will substantially minimize the adverse effects of information security incidents on the operation of the University. The objectives of these guidelines, in conjunction with the Information Security Incident Reporting Policy, are to: Minimize negative consequences of information security incidents and improve the University s ability to promptly restore operations. Enable prompt incident response decisions to be made by appropriate stakeholders. Proactively reduce the exposure of the University to information security incidents by employing consistent incident management processes that incorporate lessons learned from past incidents. Satisfy federal, state, and industry regulations that require improved protection of sensitive and private information and timely disclosure of potential breaches to affected individuals. Page 3 of 13

4 Establish a framework and appropriate metrics for consistently prioritizing information security investments across the University. Promote awareness and education of the University community relevant to incident avoidance, detection, reporting, and handling. Guidelines Incident Management Processes Processes within the scope of incident management can be generally categorized into two groups: Incident life cycle processes, including incident detection, triage, response, and mitigation Incident management sustaining processes The incident life cycle processes are depicted in Figure 1. They include the following processes: Incident Detection and Initial Reporting The incident detection process involves observation of malicious or anomalous activity, and gathering of information that provides insight into security threats or risks. Reports of threats from sources external to the University may also trigger an incident report. Incident detection involves (but is not limited to) the use of intrusion detection systems (IDS) and network monitoring at the unit level or at the Network Operations Center (NOC). Risks, threats, and vulnerabilities that meet the SPG xxx definition of information security incidents are forwarded to the designated Unit Information Security Coordinators. Information security incidents that are detected by any users of the University information resources (including computer theft or loss) are also reported to the Unit Information Security Coordinators per SPG xxx. As noted in the SPG, incidents should be reported to the Unit Information Security Coordinators as soon as possible but no later than 24 hours from the time they are initially detected. Incident Severity Classification Using the standards provided later in this document, the Unit Information Security Coordinator categorized incidents based on their severity as Serious, Medium or Low. Incidents that meet one or more of the criteria listed under Severity = Serious must be centrally reported as required by the SPG and as indicated in the Responsibilities section of this guideline. Incidents that are clearly categorized as having severity of medium or low are handled by the unit using unit level procedures for incident response, which include incident tracking and monitoring using any automated or manual tool selected by the unit. Page 4 of 13

5 Figure 1 High Level Incident Life Cycle Processes Page 5 of 13

6 Incident Reporting (Serious Incidents) As required by SPGxxx, serious incidents that involve protected patient information are reported to the University HIPAA officer. Serious incidents involving human subject information are reported to the Office of Vice President for Research (OVPR). All other serious incidents, including incidents where the Information Security Coordinator is not sure whether the incident is serious or what type of information might be involved, are reported to ITSS/NOC. Any serious incidents that are reported or forwarded to ITSS/NOC must include the data fields that are specified in the Standards section of this document. Reporting of serious incidents to ITSS, the HIPAA Officer, or OVPR must occur as soon as possible but no more than 24 hours from the time the incident was reported to the Unit Information Security Coordinator. Incident Response (HIPAA or OVPR) The University HIPAA Officer or the designated OVPR staff member, depending on the type of data involved in the incident, respond to incidents reported to them according to their applicable procedures. They also inform ITSS of the incidents in a timely way, providing the data fields specified in the Standards section, with the exception of the IP address of the target of the attack. Incident Logging Serious incidents reported to NOC are immediately logged in the Incident Management Database and reported to ITSS. Incident Response and the CSIRT The ITSS incident response coordinator, in conjunction with the unit Information Security Coordinator, convenes the Computer Security Incident Response Team (CSIRT). In addition to the ITSS incident response coordinator and the unit Information Security Coordinator, the CSIRT consists of ad hoc team members as appropriate to the type and severity of the incident. The CSIRT may include unit IT service providers, business owners, DPS, User Advocate, OGC, Office of the Vice President for Communications (OVPC), Data Stewards (if sensitive or nonpublic information is potentially disclosed), compliance officers (such as HIPAA or GLBA) and others. Additional security experts (from ITSS or from other units) may be called upon to assist in forensics and in incident resolution. The incident response process is conducted by the CSIRT and involves several activities including: Planning and prioritizing response strategy and actions Incident analysis (historical database of incident trends may be accessed) Containing the incident this may include unplugging affected computers from the network, changing passwords, etc. Incident eradication determining and removing the cause of the incident and performing additional vulnerability analysis Page 6 of 13

7 Reassignment of actions to areas outside of the incident management process, if applicable Providing technical, management, and legal response, which can involve actions to contain, resolve, or mitigate incidents and actions to repair and recover affected systems Communications with internal and external parties (see Special Considerations below) Restoring and recovering affected systems Disclosure of potential breaches to affected individuals, if required by law and as indicated by applicable data stewards or compliance officers Incident closure, including updating the incident management database with additional information about the incident and logging incident closure Communication of lessons learned Special Considerations Contacting Law Enforcement If a security incident involves a suspected criminal activity, the CSIRT will include law enforcement, Department of Public Safety (DPS) and the University Office of Legal Counsel. Examples of situations that may require DPS involvement are listed in the Incident Severity Definition table in Appendix A. Responding to External Attacks In responding to external attacks, the CSIRT should not engage in counter attack methods, but rather, work with law enforcement and data service providers, as appropriate. Handling Requests to Cooperate In Investigations University staff must report requests to participate in an information security investigation (made by entities other than the unit information security coordinator or ITSS) to the unit information security coordinator before proceeding to cooperate with the request. The unit information security coordinator, with appropriate unit management, will determine whether the participation is warranted and is requested by an authorized party. Computer Crime Investigation When evidence shows that a unit has been victimized by a computer or communications crime, a thorough investigation must be performed. The unit information security coordinator will coordinate with ITSS to conduct forensic investigation, when necessary. Network hardware, software or data may be considered evidence and should be preserved for presentation to law enforcement, if necessary. Employee Investigation The unit information security coordinator will inform unit management of incidents involving improper conduct by employees, or cases where employees interfere with Page 7 of 13

8 incident response process. Unit management will work with the office of Human Resources to determine appropriate actions involving employees. Incident Management Sustaining Processes The incident management sustaining processes involve putting into place the necessary staff, infrastructure, policies and procedures for incident management activities to occur in a timely, coordinated and effective manner, to establish metrics and periodic University wide reports, and to continuously improve the processes based on lessons learned. They include the following activities: Plan and implement an initial incident management or CSIRT capability Improve an existing capability through lessons learned and evaluation and assessment activities Implement changes to the computing infrastructure to stop or mitigate an ongoing incident or to stop or mitigate the potential exploitation of a vulnerability in the hardware or software infrastructure Implement infrastructure protection improvements resulting from lessons learned or other process improvement mechanisms Evaluate the computing infrastructure by performing such tasks as proactive scanning and network monitoring, and by performing security and risk evaluations Feed the Incident Detection process with any information about ongoing incidents, discovered vulnerabilities, or other security related events that were uncovered during the evaluation Provide periodic statistical reports representing the University wide security state and any trends Promote awareness and education of the University community in relevant technologies and potential threats Incident Management Database A comprehensive University wide repository of current and historical information about security incidents will be maintained and made available to authorized personnel to assist in incident response and mitigation. The database will track the incident information (listed in the Standards section) that will be provided for serious incidents, as described in this document. The database will not contain the content of the information that might have been compromised by the incident, such as protected health information or other sensitive personal information. Protection of Incident Information Due to the sensitivity of incident related information, strict authorization and access controls will be maintained to ensure information is available only to authorized users. Unit information security coordinators will have access to information relevant to their units as well as to deidentified statistical information that will provide them with University wide trends, vulnerabilities, and previous resolutions, without identifying the units where the incidents Page 8 of 13

9 occur. The Chief IT Security Officer and a small group of ITSS and IT Communications staff will have access to all information in the database to allow necessary follow up with the units. Retention of Incident Information Standards for retention of incident related information in the incident management database will be determined, and appropriate purge processes will be implemented. Roles and Responsibilities For roles and responsibilities of members of the CSIRT, please refer to Incident Response Operating Level Agreement (OLA). For other information security roles and responsibilities, please refer to Data Management and Protection Roles and Responsibilities. References Standard Practice Guide TBD Information Security Incident Reporting Policy Standard Practice Guide Proper Use of Information Resources, Information Technology, and Networks at the University of Michigan Standard Practice Guide Institutional Data Resource Management Policy Data Management and Protection Roles and Responsibilities Information Security Incident Response Operating Level Agreement Page 9 of 13

10 Appendix A: Information Security Incident Management Standards This section defines University wide data standards that will be used to consistently categorize information security incidents and specify the minimum information to be tracked for serious incidents. Incident Severity Definition 1. Data classification Reasonable expectation of data acquisition by an unauthorized person (select data types involved) 2. Legal issues and violations Examples of situations that may require DPS involvement Severity = SERIOUS Data designated as sensitive per SPG , or otherwise protected (see checklist tbd) including: >Social Security Number >Credit Card Numbers >Driver License Number >Bank accounts and other sensitive financial information >Protected Health Information (PHI) Security related data (passwords, risk assessments, etc.) Data restricted by legal contracts, MOU, other agreements Data whose disclosure to unauthorized users will cause harm to an individual, a group or the institution. Other sensitive or protected data >Child Sexually Abusive Material (Child Porn) >Soliciting a Minor for Immoral Purposes (internet predators) >Larceny or theft of any amount >Malicious Destruction of Property >Computer Access Crime (key loggers, successful hacking, person to person intrusion, malicious compromised account) >Embezzlement >Harassment/threats >Placement of eavesdropping devices (key loggers, as well as hidden web cams) >Stalking >Fraud or fraudulent activities 3. Magnitude of service disruption Impacts UM mission critical services 4. Threat potential Severity = MEDIUM (data not classified as sensitive or protected) There is a potential of impacting UM mission critical services Page 10 of 13

11 5. Expanse 6. Public appeal Severity = SERIOUS IT resources are being attacked (regardless of whether they are successful or not) Widespread (over 10% of unit or greater than 100 hosts overall across all campuses) Public interest in this incident is likely Severity = MEDIUM There is a potential of IT resources being attacked Somewhat widespread (3 10% of unit or hosts across all campuses) There is a potential for public interest in this incident Severity = SERIOUS if at least one ʺseriousʺ criteria is checked Severity = MEDIUM if no ʺseriousʺ criteria are checked and at least one ʺmediumʺ criteria is checked Severity = LOW if no ʺseriousʺ and no ʺmediumʺ criteria are checked. Incident Data Fields Incident Data Fields Description Required Data Fields for Central Reporting/Tracking of Serious Incidents Contact Information for the Incident Reporter Name, Unique Name Organizational unit department, division, team E mail address Phone number Location mailing address, office room number Incident Details Date/time that the incident was discovered Date/time that the incident was reported Date/time that the incident occurred (if known) Date/time that the incident was closed Type of incident Current status of the incident Source of the incident Host Name IP Address Target of attack Host Name IP Address Description of the incident Description of affected resources Description of affected organizations Estimated technical impact of the incident Response actions performed (summary) Other organizations contacted Incident Severity Cause of the Incident Total hours spent on incident handling Additional non labor costs involved in handling General Comments See Attachment C for the definition of Incident Type New, Active, Resolved, Closed (checklist) List of sources Note: Target of attack will not be provided for incidents involving protected health information e.g., how it was detected, what occurred e.g., networks, hosts, applications, data), including systems hostnames and IP addresses e.g., data deleted, system crashed, application unavailable e.g., shut off host, disconnected host from network e.g., DPS, software vendor; include when contacted See Attachment A for incident severity criteria e.g., misconfigured application, unpatched host Page 11 of 13

12 Incident Data Fields Description Recommended Data Fields for Incident Handling (Maintained by Units) Current Status of the Incident Response Incident Handling Actions Log Include: actions taken; when; by whom Incident Timeline Reconstruction of the events leading up to the incident, including pointers to evidence Contact information for all involved parties List of evidence gathered Incident Handler Comments Page 12 of 13

13 Incident Types Incident Type Compromised User Credentials Compromised System Network Attacks Malware Policy Violation Description The password or credentials of a user have been compromised and possibly used to perform unauthorized activity. An unauthorized user taking control of a machine or resource. Use of the network for malicious activity, including > A denial of service attack which causes legitimate access to University resources to be hindered. > Network scanning, such as portscanning or hostscanning. > Unauthorized packet capture, including grabbing passwords or sniffing wireless segments. Malicious software such as viruses, worms, and trojans A user or system resource violating written or implied acceptable usage policies. Social Engineering Lost Equipment/Theft Sensitive or other non public information obtained by manipulation of legitimate users, including phishing. Lost or stolen equipment, such as laptops, thumb drives, PDAs, which may lead to disclosure of sensitive or other non public information Note: Check all incident types that apply Page 13 of 13