Information Security Incident Response Plan

If an incident is considered illegal or life threatening, contact the UBPD: 716-645-2222.

For suspected or confirmed information security incidents, contact the Information Security Office by emailing sec-office@buffalo.edu or calling 716-645-6997. If the ISO cannot be reached, contact the UBIT Help Center: www.buffalo.edu/ubit/help or 716-645-3542.

The term “information security incident” is used throughout this document.

Introduction

UBIT’s Information Security Incident Response Plan identifies and describes goals, expectations, roles, and responsibilities with respect to information security incident preparation, detection, activation/response, containment, notification remediation, resolution, and after-action analysis. UBIT adopts the National Institute of Health’s definition of “incident” for the Information Security Incident Response Plan. An incident is “an occurrence that (1) actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or (2) constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies.” For more terminology, please refer to the Glossary. The plan is consistent with the National Institute of Standards and Technology (NIST) and the SANS Institute.

Furthermore, the plan:

takes into consideration the sensitivity and value of the affected assets;

is designed to ensure the integrity of UB data while minimizing service disruptions; and,

is intended to meet the university’s legal and or regulatory obligations.

The University at Buffalo (UB, university) relies on information systems and communication networks for its normal operation. Maintenance of the confidentiality, integrity, and availability of these systems and their data is a risk management issue. Malicious entities probe systems in order to expose vulnerabilities. Vulnerabilities are exploited in order to gain unauthorized access to systems and networks. Evolving threats, emerging technologies, and increasingly sophisticated social engineering tactics endanger the university’s information systems and data. The university will continue to experience such incidents, and should prepare accordingly.

UB is committed to collecting, handling, storing, and using data properly and securely. The university creates, transmits, processes, stores, and publishes large amounts of data. Much of this data is sensitive and classified as non-public data in accordance with the university’s Data Risk Classification Policy. The data is valuable to the university and on the open market as intellectual property. University policies ensure that data is protected to safeguard privacy, reduce the threat of identity theft, and maintain compliance with state and federal laws and regulations. UB is subject to HIPAA, NYS Business law, FERPA, Gramm-Leach-Bliley Act, FTC Red Flags Requirements, Payment Card Industry Data Security Standards, and the European Union’s General Data Protection Regulation. Therefore, optimizing regulatory compliance is an important business driver.

Integration with Other Efforts

UB Information Technology

UB Emergency Management's Comprehensive Emergency Management Plan

The plan supplements the UB Emergency Management’s Comprehensive Emergency Management Plan (CEMP). The CEMP documents and describes emergency management concepts and principles as an operational framework. The framework is used to respond to incidents, emergencies, or disasters in order to protect lives and property through effective use of available manpower and resources during emergency operations. More information is available in the section, “Related Documents.”

Information Technology Standards

The plan is informed by and consistent with best practices recommended by:

Common Categories of Information Security Incidents

Unauthorized Access: When an individual or entity gains logical or physical access without permission to a university network, system, application, data, or other resource.

Denial of Service (DoS): An attack that successfully prevents or impairs the normal authorized functionality of networks, systems, or applications by exhausting resources. This activity includes being the victim or participating in the DoS.

Malicious Code: Successful installation of malicious software (e.g., a virus, worm, Trojan horse, or other code-based malicious entity) that infects an operating system or application.

Suspected PII Breach: If an incident involves personally identifiable information (PII), then a breach is reportable by being merely suspected. Suspected PII incidents can be resolved by confirmation of a non-PII determination.

Suspected loss of Sensitive Information: An incident that involves a suspected loss of sensitive information (not PII) that occurred as a result of Unauthorized Access, Malicious Code, or Improper (or Inappropriate) Use, where the cause or extent is not known.

Information Security Incident Classification and Impact

Classification

Incidents are classified according to risk. Classification helps identify the appropriate response and resources required. During an incident response, the risk classification category may be updated. The ISO and or the VPCIO are authorized to adjust an incident’s risk classification. UB adopts a three-tiered classification:

Major Risk (most critical and most urgent)

Moderate Risk

Minor Risk (least critical and least urgent)

Risk classification determines:

How an incident is handled

Persons, roles, resources involved

Potential for required reporting to SUNY and or external agencies

Major Risk Incident Classification Criteria

Incidents meeting any of the following criteria are classified as Major Risk, regardless of number of systems, devices, or individuals affected. Major Risk incidents typically require reporting to external agencies and carry a substantial risk of incurring litigation or external audits. Contact UB CEMP and the coordinator of the UBIT Major Incident Process Design for Major Risk incidents.

Category 1- Restricted Data was accessible to unauthorized individuals as a result of the incident.

The data or systems involved in the incident are subject to state or federal regulation, including but not limited to: HIPAA, GLBA, FERPA, PCI, etc.

The data or systems involved in the incident are supported by external agencies that contain security provisions in the signed grant or contract.

The potential of physical harm to a person(s) or to university property exists as a result of the incident.

It is reasonable to expect that the incident has or may result in theft or financial fraud.

It is reasonable to expect that the incident may constitute a criminal offense.

It is reasonable to expect that the incident has or may result in loss or compromise of intellectual property.

It is possible that the incident has or could result in compromise of additional university systems or data.

It is possible that the incident could affect the integrity or availability of university-wide or departmental mission-critical infrastructure, systems, applications, or data. This includes devices that are used to administer network and other computer systems as indicated above.

Moderate or Minor Risk Incident Classification Criteria

There are not strict delineations between Moderate and Minor Risk incidents. Rather, incidents not considered to be Major incidents are analyzed according the number of systems, persons, accounts, or data records affected. From this analysis, the ISO and VPCIO classify an incident as either Moderate Risk or Minor Risk. The risk classification determines the level and scope of the resources deployed to respond to the incident, as well as the criticality of response.

Exception for Category 2 – Private Data: If it is reasonable to expect that Category 2- Private Data was accessible to unauthorized individuals as a result of the incident, then it is considered a Moderate Risk Incident. It is not necessary to determine whether the university data was actually accessed.

Incident Impact & Effort

This section is adapted from the NIST Computer Security Incident Handling Guide. The following categories can help the ISO classify incident risk, as indicated above:

Functional Impact of the Incident

Information Impact of the Incident

Recoverability Effort of the Incident

Functional Impact of the Incident

None: No effect to the university’s ability to provide all services to all users

Low: Minimal effect; the university can provide all critical services to all users but has lost efficiency

Medium: University has lost the ability to provide a critical service to a subset of system users

High: University is no longer able to provide some critical services to any users

In order to determine the functional impact of the incident, consider:

Current functional impact to affected systems and the university

Likelihood of future functional impact to affected systems and the university if the incident it is not immediately contained and remediated

Information Impact of the Incident*

None: No information was exfiltrated, changed, deleted, or otherwise compromised

Integrity Loss: Sensitive or proprietary information was changed or deleted

*With the exception of the ‘None’ value, the categories are not mutually exclusive.

Information security incidents may affect the confidentiality, integrity, and availability of the university’s information. In order to determine information impact of the incident, consider:

How information exfiltration will impact the university

Whether information exfiltration may also affect other organizations, including third parties or affiliation groups

Recoverability Effort from the Incident*

Regular: Time to recovery is predictable with existing resources

Supplemented: Time to recovery is predictable with additional resources

Extended: Time to recovery is unpredictable; additional resources and outside help are needed

Not Recoverable: Recovery from the incident is not possible (e.g., sensitive data exfiltrated and posted publicly); launch investigation

An incident’s functional and information impact determine the time and resources necessary to recover. Consider recoverability effort and weigh that against the value created by the recovery effort and any requirements related to incident handling. The information above identifies the level of and type of resources required in order to recover from an incident.

If you are unable to reach the ISO, try again after approximately 15 minutes. If you are unable to reach the ISO after the second attempt, then contact the UBIT Help Center: buffalo.edu/ubit/help or 716-645-3542. The UBIT Help Center will escalate the notification on your behalf.

Functional impact, information impact, and recoverability effort of the incident

Activates response:

For Major Risk incidents, UBIT-IRT activation is required.

For Moderate Risk and Minor Risk incidents, the ISO and VPCIO determine if UBIT-IRT activation is required. For Moderate and Minor Risk incidents, components of the UBIT-IRT may be incorporated into the response, depending on the incident details.

Contacts the VPCIO to determine if and when to alert the VPCIO’s leadership team.

Determines the appropriate personnel and roles.

Prioritizes incident response in the event of multiple simultaneous incidents.

Communicating with UB Emergency Management

For Moderate or Minor Risk incidents, the ISO (or designee) may contact UB Emergency Management’s Senior Emergency Planning Coordinator at his or her discretion, depending on the specific nature of the incident.

External Communication

All external communications will be coordinated by University Communications, VPCIO, ISO, and UBIT Communication and Engagement. This group may assign a Public Information Officer (PIO), who will serve as a single point of contact for external communication.

The threshold for external communication depends on a number of factors.

Legal and regulatory issues are taken into consideration when determining the appropriateness of communicating with external entities.

Notification to Insurance Provider Regarding Claim or Loss

The ISO, VPCIO, or designee is obligated to notify the underwriters of any claim as soon as practical, but in no event later than sixty days after incident resolution. This applies to incidents involving:

UBIT Incident Response Team (UBIT-IRT)

UBIT-IRT is authorized to take appropriate steps to contain and remediate an incident.

UBIT-IRT is activated and leads the response for Major Risk incidents.

UBIT-IRT may be activated for Moderate or Minor Risk incidents at the discretion of the ISO and VPCIO.

UBIT-IRT Membership

Executive Representation (VPCIO)

Leads UBIT

Consults with ISO regarding incident response

Responsible for alerting and updating leadership, including the President, Provost, VPs, and affected Deans when appropriate on information security incidents. Responsible for designating an Officer-in-Charge (OIC) as needed.

UBIT-IRT Incident Management Phases

Upon activation, follow the process to completion. It may be necessary to repeat some of the phases.

Preparation

Detection

Activation and or Response

Containment

Notification

Remediation

Resolution

After-Action Analysis

Phase 1: Preparation

The purpose of this phase is to prepare the UBIT-IRT to effectively respond to information security incidents. While not exhaustive, some required preparation categories are:

Team members: Maintain IT staff with required skillsets.

Team communication: Primary communication mechanisms are email, telephone, and instant message (IM). The incident may affect network-based services including but not limited: to UBbox, e-mail, and VOIP telephones. Therefore, it may be necessary to identify alternative communication mechanisms.

Team meeting space: Provide sufficient space.

Team training: Conduct training in order to improve incident response skills.

Phase 2: Detection

Incidents are detected from internal and external sources.

External Detection: If detection originates from outside of the university, verify the individual’s identity and affiliation. Request name, organization/affiliation, main office phone number and call them back.

Internal Detection: UB system administrators and customers should be familiar enough with their systems so they are able to determine if an event implies an information security incident. Good incident detection requires:

Security contacts must analyze all available information in order to understand the scope of an incident and effectively contain and remediate the incident. The incident must be fully diagnosed prior to beginning subsequent plan phases.

While not exhaustive, the following are common indicators that a computer, device, or system may be compromised:

Phase 3: Activation and/or Response

It is at the discretion of the ISO, in consultation with the VPCIO, to activate the UBIT-IRT for Moderate and Minor Risk incidents.

It is mandatory to notify UB Emergency Management for Major Risk incidents.

It is at the discretion of the ISO, in consultation with the VPCIO, to notify UB Emergency Management for Moderate and Minor Risk incidents.

Once activated, UBIT-IRT establishes:

Response update timing and frequency expectations to VPCIO and other constituencies

Goals for breach notification (if applicable)

Phase 4: Containment

The first priority of UBIT-IRT is to contain the incident. An incident is considered contained when no additional harm can be caused and the incident handler is able to focus on remediation. Containment consists of three stages:

Short-term containment to stop the progress of the incident or attacker.

Long-term containment, including making changes to the production system.

Phase 5: Notification

Notify individuals, entities, and or organizations per the university’s legal, regulatory, or affiliation agreement obligations.

Notification requirements depend upon a number of factors. The ISO, VPCIO, legal officer, and UBIT Communication and Engagement should determine what notification is deemed necessary, what the notification should contain, and who should receive the notification.

The Communication plan and strategy should include a section on notification.

Phase 6: Remediation

The goal of the Remediation Phase is to clean a system and make it operationally ready to resume service. These are examples of remediation steps, but the specific actions will depend upon the nature of the incident.

Determine and document the cause(s) and symptom(s) of the incident

Isolating the attack based on information gathered during the detection phase

Glossary

Departments and Personnel

Emergency Management: The UB Emergency Management Program effectively coordinates university, community, and other external resources to protect life and property before, during, and after emergencies. Emergency Management is responsible for the Comprehensive Emergency Management Plan (CEMP).

Public Information Officer (PIO): Coordinates public-facing communication efforts and to satisfy regulatory requirements (as needed) in the event of an information security incident.

System Administrator: A university service provider charged with managing information technology resources.

UBIT-Incident Response Team (UBIT-IRT): A team of subject matter experts assembled to respond to an incident and implement the Incident Response Plan.

Customer: An individual who uses an information technology resource or service.

Vice President and Chief Information Officer (VPCIO): Responsible for alerting and updating leadership, including the President, Provost, VPs, and affected Deans when appropriate on information security incidents. According to the university’s Comprehensive Emergency Management Plan (CEMP), the VPCIO is required to ensure planning for cyber disruptions and provide expertise for technology customers during the activation of an emergency management plan.

Event: Any observable occurrence within an information technology resource.

Exposure: An exposure is a state in a computing system (or set of systems) which is not a universal vulnerability, but either: (1) Allows an attacker to conduct information gathering activities or to hide activities, (2) Allows an attacker to hide activities.

Incident: An occurrence that (1) actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or (2) constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies.

Incident Response: An action plan for handling the misuse of Information Technology Resources.

Malware: A virus, worm, Trojan horse, or other code-based malicious entity that successfully infects a host.

Personally Identifiable Information (PII): Any representation of information that permits the identity of an individual to whom the information applies to be reasonably inferred by either direct or indirect means. Further, PII is defined as information: (i) that directly identifies an individual (e.g., name, address, social security number or other identifying number or code, telephone number, email address, etc.) or (ii) by which an agency intends to identify specific individuals in conjunction with other data elements, i.e., indirect identification. (These data elements may include a combination of gender, race, birth date, geographic indicator, and other descriptors). Additionally, information permitting the physical or online contacting of a specific individual is the same as personally identifiable information. This information can be maintained in either paper, electronic or other media.

Protected Critical Infrastructure Information: Sensitive infrastructure information voluntarily shared with the government for homeland security purposes. For more information: https://www.dhs.gov/pcii-program.

Social Engineering: An attempt to trick someone into revealing information (e.g., a password) that can be used to attack systems or networks.

Third-party Event: An information security incident that occurs external to the university’s information systems or communication networks, but that involves UBITName account credentials.

Threat: The potential source of an adverse event.Vulnerability: A weakness in a system, application, or network that is subject to exploitation or misuse.

Appendix E: Communication Strategy and Plan Worksheet

The Communication Officer, who serves on the UBIT-IRT, is responsible for the incident response communication strategy and plan. The Communication Officer works with the VPCIO, ISO, and University Communication to ensure appropriate and timely messaging about the incident and the university’s response to it. This worksheet helps formulate a communication strategy and plan. It is illustrative, rather than exhaustive. Communicate through channels known to be unaffected by the incident.

Potential stakeholders

SUNY

University Leadership

VPCIO

IT Security Office Staff

UBIT Staff

UBIT-IRT

IT Node Directors

University Legal Counsel

Faculty, Staff, Students, Alumni, Donors

University affiliates or volunteers

Law enforcement agencies

Technical support community

Outside agencies

Vendors

Others

Identify individual who are authorized to communicate about the incident to both internal and external constituencies.

Internal communications channels

Email

Listserv (can be event specific)

Phone/video conferences

Meetings

Office phones

Cell phones

Others

External communications channels

Email

Web, Blogs

Listserv (can be event specific)

Phone/video conferences

Meetings

Office phones

Cell phones

Others

Schedule and frequency of communication

The plan should identify

Information that can be shared outside of the UBIT-IRT, including to what degree stakeholder groups should be provided with varying levels of information about the incident. For example: The VPCIO leadership team may need technical information about the incident that the President’s Cabinet would not need.

It may be necessary to contact an external organization to let them know that a machine under their control may be having a negative impact on the University at Buffalo’s IT systems and networks. The steps provided below are intended to guide communication.

Determine technical and administrative contacts of the source machine.

Determine WHOIS is the contact for upstream provider, if one exists.

Determine if a US-CERT or “abuse” email address exists if the source machine is from a foreign country.

Contact abuse@buffalo.edu to see if other campus sites have been attacked/scanned by the source machine.

Send a concise email to the WHOIS contact of the source machines. Include:

Research Data Security Incidents

If the research data is subject to additional regulatory or legal implications, then the incident response should include representation required for that type of incident.

Executive Representation

VP for Research

Unit Dean/VP where the incident is occurring

VP for Communications

Functional Representation

Office of General Counsel

Unit HIPAA Compliance Officer (if human subjects are involved)

UB HIPAA Compliance Officer

UBIT-IRT and ISO

NYS Breach Notification

Executive Representation

VPCIO

Unit Dean/VP where the incident is occurring

VP Communications

Functional Representation

Office of General Counsel

UBIT-IRT and ISO

HIPAA Breach Incidents

If the incident is determined to include ePHI, then the UB HIPAA Compliance Officer is responsible for conducting the HIPAA-related components of the breach response. The ISO is responsible for conducting a parallel Information Security Incident Response.