it.ucsf.edu

UCSF Incident Investigation Procedures

Policy Type

Procedure

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.
  • 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, networks, and systems controlled by the University.

This includes any incidents where data traverses over any University controlled network or system. 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.

S&P – UCSF Security & Policy.

Electronic Information Resource (EIR) – A resource used in support of UCSF activities that involve the electronic storage, processing, or transmitting of data as well as the data itself. Electronic Information 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.

Electronic Information Resource Custodian – The department that has physical or logical control over an Electronic 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 Electronic Information Resource Proprietor.

Electronic Information Resource Proprietor – The Proprietor of Electronic 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 Electronic 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 Electronic Information Resources are University resources, and Electronic 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 statues, 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)

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 Remedy 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

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 Classification

Although all incidents should be considered serious in nature, different actions may be taken when information about the incident is discovered during an investigation.

Incidents should be classified based upon these UCSF Remedy incident classification categories:

1.Brute Force - exhaustive attacks that use various methods in order to find legitimate authentication credentials (e.g. username, password)

2. Compromise - a suspicion of unauthorized access by a program or person to a UCSF computer

3. Denial of Service - an attack on a network or device that prevents legitimate users form accessing information or services

4.Lost / Stolen - UCSF lost or stolen devices/media including PC, laptop, PDA, text pagers, cell phones, cell phones with cameras, home computers, a dictation devices (GO MD), CD, floppy disk, memory sticks, jazz drives, and any other removable storage devices.

5. Password Compromise - accidental exposure of password, sniffed password, key logger capture

6. Phishing/Credential Theft - phishing attempts, both successful and unsuccessful, identity theft, credential (other than password) theft

7. Port Scan - attempts to learn about the weaknesses of a computer or a network edge device by repeatedly probing it with requests for information

8. Top Attacker - UCSF computer identified as a top attack source

9. Unacceptable Use - violation of UCSF Acceptable Use policies

10.Malicious Code - a computer infected or suspected of being infected with a specific virus, worm, or Trojan (e.g. Phatbot, Sasser)

11. Wireless - reports of unauthorized or attacking Wireless Access Point

11. Incident Investigation Procedures

A. Lost or Stolen (non Restricted Data system)

If a lost or stolen computing system does NOT contain Restricted Data, the incident is classified as a property loss.

1. User Actions

a. Immediately report the loss or theft to UCSF PD (1+415+476-1414).

b. Identify resources as lost or stolen.

c. Identify additional users and external sites that may be affected by the loss or theft.

d. Confirm that no restricted data involved.

e. Change any compromised user credentials.

2. UCSF PD Actions

a. Create a police report of the incident.

b. Notify S&P of the loss.

c. Determine if additional police action is necessary.

3. S&P Actions

a. Log the incident and any related correspondence into UCSF’s Remedy system.

b. Confirm with owner that no Restricted Data information was on the system.

c. If the device contained restricted data, notify the UCSF Privacy Office, CHR, associated UCSF Security Control Points, Associate Vice President David Ernst (in writing upon discovery as well as when the incident is closed) and the Affected Department where appropriate.

d. Coordinate communication with external sites/users if necessary.

B. Lost or Stolen (Restricted Data system)

1. User Actions

a. Immediately report the loss or theft to UCSF PD (1 (415) 476-1414)

b. Identify resources lost or stolen.

c. Identify additional users and sites that may be affected.

d. Identify Restricted Data on system.

e. Change any compromised user credentials.

2. UCSF PD Actions

a.Create a police report of the incident.

b. Notify S&P of the loss.

c.Inform S&P that system had Restricted Data.

d.Determine if additional police action is necessary.

3. S&P Actions

a. Log the incident and any correspondence related to the incident into UCSF’s Remedy system.

b.Contact the responsible party of the lost property to determine all items lost and verify the type of data (restricted or not) stored on the device(s).

c. If the device contained restricted data, notify the UCSF Privacy Office, CHR, associated UCSF Security Control Points and the Affected Department where appropriate.

d. Verify compromised user credentials are changed.

e. Coordinate communication with external sites/users if necessary.

f. Provide user awareness training if the system contained PII or ePHI.

4. UCSF Privacy Office Actions

a. Coordinate with S&P to determine if Restricted Data was appropriately protected from disclosure

b. Update appropriate UCSF Security Control Points on their findings of their investigation.

c.Coordinate notification process with Affected Department.

5. Affected Department

a. Responsible for any required notifications.

b. Responsible for costs associated with any required notifications.

c.Coordinate notification process with UCSF Privacy Office and S&P.

C. Suspected Compromise (non Restricted Data system)

1. User Actions

a. Do NOT remove power from the system or shut it down.

b. Stop using the system and quarantine it.

c. Place a sign on it warning other users not to use the system.

d. Immediately report the incident to UCSF ITS Customer Support at 1+415+514-4100.

e. Unplug the system from the network only if you are unable to contact Customer Support.

f. Do not power the system down, reboot the system, or shut it down.

f. Confirm system did not contain any restricted data without logging into the system.

2. Customer Support Actions

a. Customer Support enters the information into Remedy in the INTERNAL work log.

b. Customer Support assigns a Remedy ticket to S&P.

3. S&P Actions

a. Verify with owner no Restricted Data was stored on the system.

b. Determine whether incident is a user level or admin level compromise.

c. Determine the cause of the incident if possible.

d. Document incident handling procedure.

e.Provide additional training if necessary.

D. Suspected Compromise (Restricted Data system)

1. User Actions

a. Do NOT remove power from the system or shut it down.

b. Stop using the system and quarantine it.

c. Place a sign on it warning other users not to use the system.

d. Immediately report the incident to UCSF ITS Customer Support at 1+415+514-4100.

e. Immediately report the loss or theft to UCSF PD at 1+415+476-1414.

f. Unplug the system from the network only if you are unable to contact Customer Support -do not power the system down, reboot the system, or shut it down.

g. Identify the type of Restricted Data on system.

2. Customer Support Actions

a.Customer Support enters the information into Remedy in the INTERNAL work log.

b. Customer Support assigns Remedy ticket to the S&P.

c. Customer Support notes on Remedy ticket the presence of suspected Restricted Data.

3.      S&P Actions

a.Verify with user Restricted Data information on system - if the system contained ePHI, notify the Privacy Office, Medical Center IT, CHR, UCSF Security Control Points where appropriate and Associate Vice President David Ernst (in writing upon discovery as well as when the incident is closed).

b. Determine the cause of the incident if possible.

c. Determine whether user level or administrative level compromise

d. Identify additional systems (external and internal) that may be affected.

e. Notify additional users and affected departments if necessary.

f. Coordinate communications with any externally affected sites.

g. Document incident handling procedures.

h. Verify notification process if Restricted Data was PII.

4. Privacy Office Actions

a. Oversee the review of the incident.

b. Facilitate contacting the following as appropriate:

i. Affected Department’s Manager, Department Chair, Associate Director, Dean, or other appropriate management

ii. Human Resources

iii. Individual(s) whose ePHI or personal information may be affected

  1. Office of the Associate Vice President, Information Resources and Communications at UC Office of the President

5. Affected Department

a. Responsible for any required notifications

b. Responsible for costs associated with any required notifications

c. Coordinate notification process with UCSF Privacy Office and S&P

12. Incident Resolution

Incident resolution occurs in parallel with incident handling. One of the goals of incident handling is to minimize the impact of the incident on affected users.

A. Lost or Stolen System

1. Restoration of lost data to a suitable replacement system can occur immediately.

a. The Affected Department is ultimately responsible for finding a suitable replacement system.

b. The Affected Department is responsible for restoring lost data.

2. User Credentials for all affected users must be revoked and re-issued.

a. These include credentials used to access remote sites that may have been stored on the system and offsite credentials that were used to access the stolen or lost system.

b. The Affected Department will confirm with S&P that all user credentials have been changed.

B. Compromised System

1.User Credentials for all affected users must be revoked and re-issued.

a.These include credentials used to access remote sites that may have been stored on the system and offsite credentials that were used to access the stolen or lost system.

b. The Affected Department will confirm with S&P that all user credentials have been changed.

2. Before a compromised computing system that houses Restricted Data will be allowed to reconnect to the UCSF network, the following must be completed:

a. Rebuilt from the original media, and then all patches must be applied

b. Brought into compliance with UCSF Minimum Security Standards

c. Obtain authorization from S&P to reconnect the computing system

i. Scanned for vulnerabilities by S&P. To request a vulnerability scan:

a. Contact Customer Support at 1+415+514-4100

b. Customer Support will create a scan request and assign it to S&P Compliance.

i. When all known vulnerabilities have been removed from the machine, S&P will authorize the (re)connection of the computing system to the UCSF network.

13. Notification Procedure And Process

A. Systems Containing PII

Incidents involving systems containing PII require additional handling as mandated by SB1386.

These steps will be taken by S&P to determine if further notification is necessary:

1. Determine if criteria for notification are met. (Refer to SB1386)

2. Proceed with notification process if criteria are met.

3. If criteria for notification are not immediately met, then the UCOP guideline “Determining the Threshold for Security Breach Notification” must be used - http://www.ucop.edu/irc/itsec/securitybreach.html

a. If the incident meets the intention of the requirement, then notification should be sent to the potentially affected individuals.

b. If the incident does not meet the intention of the statutory requirement, document the decision process in the associated Remedy ticket.

4. Process for Notification

a. A meeting is held between the Affected Department head, UCSF Privacy Office (when ePHI is disclosed), S&P, Campus Counsel, and any others if needed, to determine whether notification to the potentially affected individual(s) is appropriate.

b.The following steps must be taken when it has been determined that notification is required:

i. The head of the Affected Department will develop a notification letter.

ii. The letter should include an email address for recipients to communicate with the Affected Department by email.

iii. Campus Counsel will advise on any additional language that may be needed.

iv. If needed, the Affected Department will coordinate with ITS to create a special Notify email account for the department.

v.The Affected Department is responsible for sending out notification letters.

vi. The cost of notification will be the responsibility of the Affected Department.

vii. A temporary phone number in the Affected Department for notification recipients can be arranged in coordination with Enterprise Network Services (contact Customer Support at 1+415+514-4100 to create a Remedy Change request).

5. As appropriate, S&P will facilitate the additional education of the user(s) involved.

B. Systems Containing ePHI

1. Determine if criteria for notification are met.

2. Proceed with notification process if criteria are met.

3. If criteria for notification are not immediately met, then the UCOP guideline for determining the threshold for Security Breach Notification must be used - (http://www.ucop.edu/irc/itsec/securitybreach.html)

4. If the incident meets the intention of the requirement, then notification should be sent to the potentially affected individuals.

5.If the incident does not meet the intention of the statutory requirement, document the decision process in the associated Remedy ticket.

6. Responsibilities

a. Privacy Office

i. Determine if threshold of notification was met.

ii. Determine who needs to be notified.

iii. Facilitate coordination

b. S&P Actions

i. Contact where appropriate

a. Affected Department, Department Chair, Associate Director, Dean, or other appropriate management

b. UCSF Controller’s Office

c. UCSF CIO

d. UCSF Internal Audit

e.UCSF Campus Counsel.

f. UCSFPD Chief of Police

g. CHR

ii. Work with the Affected Department, Department Chair, Associate Director, Dean, or other appropriate management.

iii. Assist the Affected Department as appropriate.

iv. As appropriate, facilitate the additional education of the user(s) involved.

c. Affected Department

i. It is the responsibility of the Affected Department to prepare and send out notifications to affected individuals and entities when deemed appropriate.

14. 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.

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

15. Additional Resources

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

UCSF HIPAA Information - http://hipaa.ucsf.edu

UCSF SB1386 Information - SB1386

UCOP Determining the Threshold for Security Breach Notification -http://www.ucop.edu/irc/itsec/securitybreach.html