Effective Date: October 1, 2006

1. Purpose

This document provides an overview of computer incident response and investigations procedures at the University of California, San Francisco (UCSF), as mandated in UCSF Policy 650-16 Addendum C: Incident Investigation.

2. Objectives

• Provide procedures for Incident Investigations.
• Determine extent of damage or loss.
• Ensure proper handling of compromises or exposures of restricted data, as defined in BFB IS-3, Electronic Information Security and the UCOP Incident Response Standard.Ensure compliance with federal and state laws and University policies.
• Prevent similar future incidents.

3. Overview and Scope

The following procedures apply to all computing devices, computing environments, networks, and systems controlled by the University or used for University purposes.

This includes any incidents where data traverses over any University controlled network,  system, and/or services provided by UCSF Service Providers as defined in UCSF 650-16 Addendum A. These procedures should be considered a framework for proper incident handling. Incident responders should adapt their response based upon the nature of the incident.

4. Definition of Terms

Affected Department

Department in which the compromise occurred.

Authorized User

Any UCSF faculty, staff, student, or other individual affiliated with UCSF that has been granted authorization to access an Electronic Information Resource or invokes or accesses an Electronic Information Resource for the purpose of performing his or her job duties or other functions directly related to his or her affiliation with UCSF. The authorization granted is for a specific level of access to the Electronic Information Resource in accordance with University policy. An example of an Authorized User is someone who handles business transactions and performs data entry into a business application or someone who gathers information from an application or data source for the purposes of analysis and management reporting.

Compromise

Unauthorized (actual or suspected) access, use, disclosure, modification, or destruction of an Electronic Information Resource in violation of University policies.

ePHI (electronic Protected Health Information)

Protected Health Information (PHI) which is created, stored, transmitted, or received electronically. See the UCSF HIPAA website for more detailed information regarding PHI.

Institutional Information and IT Resources

A resource used in support of UCSF activities that involve the electronic storage, processing, or transmitting of data as well as the data itself. Institutional Information and IT Resources include application systems, operating systems, tools, communications systems, and data – in raw, summary, and interpreted form – and associated computer server, desktop, communications, and other hardware used in support of UCSF activities. Personally owned systems are included in this definition if they connect to the UCSF network or are used to process or store UCSF information.

Institutional Information Resource Custodian

The department that has physical or logical control over an Institutional Information Resource. This includes, for example, departmental system administrators of a local area network and the campus administrator for a campus-wide database. This role provides a service to the Institutional Information Resource Proprietor.

Institutional Information Resource Proprietor 

The Proprietor of Institutional Information Resource is the individual designated by the Chancellor or his or her designee as having the responsibility for determining the purpose and function of the Institutional Information Resource. Such responsibility may include specifying the uses for a departmentally owned server; establishing functional requirements during development of anew application or maintenance to an existing application; and determining which Users may have access to an application or to data accessible via an application. All Institutional Information Resources are University resources, and Institutional Information Resource Proprietors are responsible for ensuring that these Resources are used in ways consistent with the mission of UCSF as a whole.

HIPAA

Health Information Portability and Accountability Act - See the UCSF HIPAA website for further information

Incident

An event that violates or is suspected of violating University Electronic Information Resource access and usage policies.

Intrusive Computer Software

Intrusive computer software (such as a computer virus) is an unauthorized program designed to embed copies of itself in other programs, to modify programs or data, or to self-replicate. Intrusive computer software may be spread via removable storage media or via the network. The term “intrusive computer software” as it is used in these guidelines is intended to encompass the variety of such unauthorized programs, including viruses, bacteria, worms, Trojan Horses, etc.

Personally Identifiable Information (PII)

Information as defined by California Senate Bill 1386 (SB1386). (See below)

Protected Health Information (PHI)

PHI is an individual’s health information or data collected from an individual that is created or received by a health care provider, plan or clearinghouse related to the past, present or future physical or mental health or condition of an individual, the provision of health care to the individual, or the past, present or future payment for the provision of health care to the individual; identifies or could reasonably identify the individual; and is transmitted or maintained in electronic or any other form or medium.

Restricted Data

Data that is considered sensitive to some degree as defined by UCOP BFB IS-3 Information Security. Restricted Data include ePHI and PII data.

SB1386 California Privacy Legislation, (Senate Bill 1386) 

SB1386 legislates notification to California residents of unauthorized exposure of Personally Identifiable Information.

5. Roles And Responsibilities

Refer to UCSF 650-16 Addendum A for Roles and Responsibilities.

6. Incident Reporting

All end users and owners of systems are responsible for reporting any incidents to the appropriate organization to begin an incident investigation. Timely reporting of an incident is essential to containment, minimizing the amount of work disruption and the overall cost associated with an incident. 

Mitigation or notification requirements may differ, depending on the federal or state statutes, the nature of the information at risk in the event of a security breach, or contractual agreement. For example:

• Owners of "computerized data that includes personal information shall disclose any breach of security of the system following discovery or notification of the breach in the security of the data to any California resident whose unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person."
• Licensed UC clinics and health facilities must report to the California State Department of Public Health and affected patients any unlawful or unauthorized access to, use, or disclosure of their medical information no later than five days after activity has been detected.
• A breach of confidentiality of electronic Protected Health Information (ePHI) requires mitigation, to the extent practicable of "harmful effects."
• Business associate agreement may require specific notifications.

Initial Reporting Information

This information should be initially collected from the reporting party by Customer Support:

1. Contact information

2. Physical location of the affected system(s)

3. Date/time of the incident

4. Nature of the data on the system (i.e., whether or not it contained restricted data)

5. Source of the compromise (if known)

6. Type of compromise if known (i.e., worm, virus, credential compromise, root kit, etc.)

7. Brief description of the incident

8. Any relevant logging information (e.g., intrusion detection logs, authentication logs, access logs)

For any lost and stolen incidents follow these requirements in addition to the above:

• The reporting party must call UCSF Police Department to report the lost or stolen device. This is in addition to any report with local authorities if not on UCSF property
• The UCSF Police Department must inform UCSF IT Security of the reported loss/theft through established processes

7. Documentation

Documentation provides a record of the incident and assists in the proper handling of a computer security incident. All documentation regarding an incident should be retained as it can be an invaluable resource in identifying trends, evaluating and modifying incident handling, and in determining proper computer security controls.

For most incidents the UCSF ServiceNow system is available to track and document incidents. In the event of incidents involving restricted data where notification is required, the incident documents must include the process of notification and the completion of notification.

8. Evidence Preservation

A detailed log should be kept for all evidence, including:

1. Identifying information (e.g., the location, serial number, model number, hostname, media access control (MAC) address, and IP address of the device)
2. Name, title, and phone number of each individual who collected or handled the evidence during the investigation (also known as Chain of Custody)
3. Time and date (including time zone) of each occurrence of evidence handling
4. Locations where the evidence was stored

The log should also contain how the evidence was obtained, who obtained it, and when it was obtained. Evidence should be kept in a secure location with limited access.

9. Privacy Considerations

Incident handlers should be aware of privacy considerations during incident response and investigation. Financial loss, embarrassment, or damage to reputations may occur due to inappropriate release of information to unauthorized personnel or external entities. Particular care must be taken during the initial phase of an incident response until it is determined that a compromise has occurred.

10. Incident Investigation Procedures

UCSF IT Security follows the SANS Institute’s Incident Response Framework, PICERL, also in accordance with the UCOP Incident Response Standard. The PICERL framework is an incident response framework that follows 6 phases for major incidents:

1. Preparation – This phase deals with preparing a team to be ready to handle an incident. This would include the proper training, tools, logs, access, documentation, plans, communication, and policy.
2. Identification – This phase deals with identifying and investigating the incident. This phase encompasses the incident detection (targets, attackers, methods), and the identification of the threats and risks (5 Ws and an H; Who, What, Where, Why, When, and How)
3. Containment – This phase deals with containing the incident to limit the damage and prevent further damage from happening.
4. Eradication – This phase deals with the actual removal and restoration of affected systems
5. Recovery – This phase deals with the process to return to a known good state of operations.
6. Lessons Learned – This phase deals with completely documenting the entire incident, all steps that were performed, all investigation outcomes, and short term and long term remediation plans to prevent similar incidents from happening in the future.

Note that not all security incidents will have each of the 6 phases. The depth of a security incident investigation is based on the determined risk, exposure discovered, and impact to UCSF.

Additionally, UCSF follows the UCOP Incident Response Standard https://security.ucop.edu/policies/incident-response.html

The UCSF IT Security Enterprise Incident Response Plan can be found here

UCSF IT Security has the following documentation available upon request for further details regarding incident response processes and procedures:

• Account Compromise Investigation
• Data Compromise Investigation
• Email Threat Investigation
• Host Threat Investigation
• Lost or Stolen Investigation
• Network Threat Investigation
• Major Incidents and Escalations

11. Notification Procedure And Process

See the UCSF Enterprise Incident Response Plan for details regarding notification procedures and processes

12. Incident Handling Evaluation

At the conclusion of the incident, an evaluation will occur of the incident handling process to modify future incident handling procedures as necessary. This is completed as part of the Lessons Learned phase of any major incident which is in accordance with the UCSF IT Security Major Incident and Escalation procedure as well as the UCOP Incident Response Standard.

The evaluation will be used to determine if additional security controls are necessary to prevent similar future incidents.

Incidents are reviewed weekly at the IT Security Incident Response team meetings. Additionally, major incidents are reviewed at least annually at the Committee on IT Security.

13. Additional Resources

UCSF 650-16 Information Security and Confidentiality - Policy 650-16

UCSF HIPAA Information

UCSF SB1386 Information - SB1386

UCOP Determining the Threshold for Security Breach Notification