Information Security Incident Management Standard

Title

University of North Carolina at Chapel Hill Information Security Incident Management Standard

Introduction

Purpose

To describe minimum requirements for members of the University of North Carolina at Chapel Hill ("University" or "UNC-Chapel Hill") experiencing a concern that might indicate a Possible Information Security Incident. To specify Information Security Incident authority and role requirements for Information Security Incident Handlers and Information Security Liaisons.

Scope

• Every member of the University community, including students, faculty, staff, and affiliates.
• Groups and individuals (such as Information Security Liaisons) with special responsibilities to handle Possible Information Security Incidents (“concerns”).
• Possible Information Security Incidents, distinct from other types of possible Incidents. Where the type is not obvious, but might be an Information Security Incident, these requirements apply.

Standard

The University has many legal and ethical obligations to respond and minimize harm when certain kinds of Information Security Incidents happen. In order to find out if an Incident has occurred, members of the University Community must report concerns about Possible Information Security Incidents.

If you believe that someone’s life may be in danger, call 911 at once!

Concerns come and go. New kinds appear often. It is important to stay up to date with the University’s required information security training so you will know what might be a concern. Because of the high risks, you must report concerns that might be or might turn into Information Security Incidents. (Note: The University has no way to pay "bug bounties." If you are aware of a possible compromise, you must report it!)

Examples of concerns that require reporting if any University account or data might be affected include:

• a lost or stolen device that holds University information (including personal devices);
• a device or application that is behaving strangely, and Tier 2 or 3 data may be affected (possible malware);
• an Onyen or other account or credential that involves University information may have been accessed by someone it’s not assigned to. If you think it might have been hacked, or that someone else obtained the password, or someone may have found another way into the account, it must be reported. This applies to all accounts, such as Carolina Key, SSH (Secure Shell) key, or API (Application Programming Interface) key;
• phishing messages or multifactor attempts that might have succeeded (we have another method to report phishing if you spot it but didn’t act on it. See the University's Safe Computing website for the most current way to do that.);
• funds transfer to the wrong account;
• suspicious screen-share requests that appear to be from Apple, Microsoft, Citrix or another company you trust that might have succeeded;
• unexpected or repeated multi-factor requests (like Duo or Microsoft authenticator);
• gift-card or other scams that seem to come from a University authority, like a supervisor;
• blackmail, extortion, or other threats that involve University systems or data, including ransomware threats; and/or
• any Incident report from a third party that comes to you. For example, if you contract with a cloud service, and they are reporting to you that they experienced a data breach or possible breach, you must report that as a Possible Information Security Incident.

What You Must Do  

Report the Concern

You must do any one of the following as soon as you realize you have a concern:

• contact the Service Desk by phone (919-962-4357/HELP). Ask for a critical incident to be created and sent to the Information Security Office. If you are aware of specific risks (credit card, protected health information, or similar) please ask to note that in the request, but do not go into detail. Supply a contact number and be available at that number. Expect a call within an hour.
• If you know who your unit’s Information Security Liaison (ISL) is, and you are able to contact them directly, at once, talking with them in person or on a call (leaving a message is not enough) and they assure you that they can help you, that counts as reporting.
• Information Security Liaisons with sufficient training and resources to begin a response may do so, but must also report the concern to the Information Security Office as soon as possible.

Your Part in Handling the Possible Incident

• Before you have connected with an ISL or Incident Handler, try not to do anything that will change the device or any evidence you might have about the concern. It’s best to leave everything as it is and just not touch the device/account/system/data. Do not try any added communication with an attacker. 
• You must respond when an Incident Handler contacts you.
• Cooperate with the people handling your report.
• You must provide the information you have about your concern. No one expects that you are an expert, just tell the expert what you experienced and what raised your concern.
• Work with the Incident Handler to get them access to the device (including personal devices) or system involved, or any material they may need for the investigation.
• Report to any other responsible authority the Incident Handler tells you to or that you might need to (for example, a lost device may need to be reported to local law enforcement; A possible breach of Protected Health Information would need to be reported to the Institutional Privacy Office; an issue with subject data may need to be reported to the Institutional Review Board (IRB)). 

Help as Needed to Resolve the Incident if One is Identified

• If an Information Security Incident is identified and the University has required responses to it, cooperate quickly and fully with that official response until it is entirely resolved. For example, if the University must determine the extent of a data breach, report it to one or more agencies, and notify affected people, you must take part as needed until the University’s response is completed.

Campus Authority for Information Security Incidents

The Chief Information Security Officer (CISO) and Chief Information Officer (CIO) are the primary University authorities for Information Security Incidents.

The CISO ensures that an Incident Management Plan is in place to address all concerns, events, possible Incidents, and identified Information Security Incidents that the University is required by law to address.

The CISO and CIO make sure that Information Security Incidents that are also Incidents of kinds covered by another campus authority are handled cooperatively with those authorities. Examples include:  

• The Office of University Counsel, as needed, addresses reportable incidents including reporting to the State Controller for PCI (Payment Card Industry) incidents.
• The Responsible Individual under the GLBA (Gramm Leach Bliley Act) Safeguards Rule for required reporting and other coordination.
• The Institutional Privacy Office for concerns that may involve protected health information under HIPAA (Health Insurance Portability and Accountability Act) or personally identifiable information subject to the Identity Theft Protection Act, and other Privacy domain compliance.

Exceptions

Information Security Incidents may also be other types of Incidents. If you are following a University requirement to report another Incident type (such as a possible exposure of Protected Health Information), and you can confirm that the authority you are working with has already started an Information Security report by bringing in an Information Security Incident Handler, you do not need to make a separate report.

The School of Medicine has its own Information Security staff. Students and staff of the School of Medicine may follow the School of Medicine's procedure for immediate reporting of IT security concerns.

If you have found a Phishing message but have not interacted with it in a way that might compromise your account, you can report the message using the tools provided (see the University's Safe Computing website for the most current guidance) and do not need to do more than that. This only applies to generic phishing email messages, not targeted scams or any event involving impersonation of another member of the University. Be vigilant following receipt of any phishing message!

Definitions

Incident Handler: Designated staff in the ITS or School of Medicine Information Security Offices responsible for managing potential and identified Information Security Incidents, or other individual designated by the UNC-Chapel Hill Chief Information Security Officer.

Possible Information Security Incident: Something that may put University data or systems integrity, confidentiality, or accessibility at risk soon. Or a violation of law or University policies involving information technology.

Related Requirements

Failure to follow this standard may put University information assets at risk and may have disciplinary consequences for employees, up to and including termination of employment. Students who do not adhere to this standard may be referred to the UNC-Chapel Hill Office of Student Conduct. Contractors, vendors, and others who do not adhere to this standard may face termination of their business relationships with UNC-Chapel Hill.  

External Regulations and Consequences

• N.C. General Statutes, Chapter 75, Article 2A - Identity Theft Protection Act
• U.S. Department of Health & Human Services, HIPAA Security Rule
• U.S. Public Law 106-102, Gramm-Leach-Bliley Act (GLBA); particularly the "Safeguards Rule"
• U.S. Department of Education, Family Educational Rights and Privacy Act (FERPA)
• N.C. General Statutes § 143B-920 - Reporting Stolen or Misused State Property to the SBI
• Federal Contracts Privacy Act of 1974
• Federal Information Security Management Act (FISMA)
• PCI Security Standards Council, Payment Card Industry Data Security Standards (PCI DSS)
  • American Express - Data Security Operating Policy
  • MasterCard - Account Data Compromise Event Management Best Practices
  • Visa - Responding to a Data Breach
  • Visa - What To Do If Compromised

University Policies, Standards, and Procedures

• Information Security Policy
• Data Network Policy
• Acceptable Use Policy
• Policy on Terms of Use for Administrative Systems
• Information Classification Standard 
• Information Security Liaison Standard 
• Safe Computing at UNC-Chapel Hill - Definition of Sensitive Information 
• Data Governance at UNC-Chapel Hill
• Protocol for Responding to Breaches of Protected Health Information (PHI)
• Policy on Reporting Actual, Attempted, or Suspected Misuse of University Resources
• Office of Human Research Ethics SOP 1401: Promptly Reportable Information
• Finance Procedure 603.2 - Procedure on Reporting Equipment Missing or Stolen During Normal Operations
• Finance Policy 107 - Customer Financial Record Safeguards
• Finance Policy 308 - Policy on Merchant Card Services
• Workplace Violence Policy
• Emergency Management Policy
• Other Resources for Reporting Concerns at UNC-Chapel Hill

Contact Information

Document History

• Effective Date and title of Approver: 6/30/2010 VC for Information Technology and CIO
• Revision and Review Dates, Change notes, title of Reviewer or Approver:
  • 9/19/14 Revised template, VC for IT and CIO
  • 10/13/2015 Review only, CISO
  • 10/17/2016 Review only, link added to references CISO
  • Retirement of Policy, superseded by Standard (see document change and date log in policy repository)