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. 

Category: Information Technology

Responsible Office: Information Security Office

Responsible Executive: Vice President and Chief Information Officer (VPCIO)

Date Established: August 6, 2018

Last Updated: December 6, 2018

On this page:

Abstract

The Information Security Incident Response Plan (plan) identifies and describes incident handling:

  • Roles
  • Responsibilities
  • Procedures

To facilitate an appropriate response, the plan guides:

  • Incident handling
  • Analyzing incident-related data

Intended Audience

The plan’s intended audience are members of the university, including:

  • Leadership so they understand the plan and its alignment with other university processes
  • Staff who may become aware of incidents
  • System administrators with direct involvement in the identification and resolution of security incidents on the systems, data, and applications that they manage
  • Desktop support staff with direct involvement in the identification and resolution of security incidents on the systems, data, and applications that they manage
  • UBIT Help Center Staff

Incident Response Plan Stewardship

The Information Security Office (ISO) is responsible for the plan and its revision.

  • Review and revise the plan annually and as needed, in order to address evolving technologies, threats, organization, and needs of the university.
  • Review and revise the plan following a Major Risk security incident.

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.

Strategy and Goals

Information security threats constantly evolve. Therefore, dictating prescriptive responses for each incident is not a recommended practice. Instead the plan establishes a comprehensive response that focuses goals, organization, roles, responsibilities, expected outcomes, and procedures.  This approach can help minimize an incident’s potential or actual negative impact.

The goals of the plan are:

  • To provide a consistent response strategy to information security threats that place university data and systems at risk.
  • To protect the confidentiality, integrity, and availability of university systems, networks, and data.
  • To protect the well-being of the university community and to minimize reputational harm.
  • To help the university recover after information security incidents.
  • To implement timely and appropriate corrective actions.
  • To address legal or regulatory requirements.

Integration with Other Efforts

UB Information Technology

This plan aligns with:

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:

  • International Organization for Standardization
  • National Institute of Standards and Technology (NIST)
  • Payment Card Industry Digital Security Standards
  • SANS Institute
  • United States Computer Emergency Readiness Team (US-CERT)

Applicability

In-Scope

Information security incidents are considered in-scope if they negatively affect the university’s:

  • Operations, finances, or reputational standing
  • Ability to comply with regulatory or legal requirements
  • Information technology assets, systems, or data that may negatively impact their confidentiality, integrity, or availability

Examples of in-scope incidents:

  • Denial of Service (DoS)
  • Email or phishing scams
  • Improper or inappropriate usage of the university’s information systems or network resources
  • Malicious code
  • Suspected loss of sensitive information
  • Suspected PII breach
  • Suspected ePHI breach
  • Suspicious computer or network activities, including notification that a system is under attack
  • Unauthorized access to university data or system

Out-of-Scope

Examples of out-of-scope incidents:

  • Complaints of copyright violation
  • Individually-owned computer assets not containing university data
  • Overuse of UB assets, for example, Library data services, network bandwidth, etc.
  • Violation of acceptable use policies or misuse of computer assets or data and any resulting investigations of university faculty, staff, affiliates, or student

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.
  • Improper or Inappropriate Usage: When a person violates acceptable computing policies.
  • 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.

Source: Incident Response and Management: NASA Information Security Incident Management

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.  

  1. Category 1- Restricted Data was accessible to unauthorized individuals as a result of the incident.
  2. 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.
  3. The data or systems involved in the incident are supported by external agencies that contain security provisions in the signed grant or contract.
  4. The potential of physical harm to a person(s) or to university property exists as a result of the incident.
  5. It is reasonable to expect that the incident has or may result in theft or financial fraud.
  6. It is reasonable to expect that the incident may constitute a criminal offense.
  7. It is reasonable to expect that the incident has or may result in loss or compromise of intellectual property.
  8. It is possible that the incident has or could result in compromise of additional university systems or data.
  9. 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

Privacy Breach: Sensitive personally identifiable information (PII) of students, faculty, staff, or affiliated individuals was accessed or exfiltrated

Proprietary Breach: Unclassified proprietary information, such as protected critical infrastructure information (PCII), was accessed or exfiltrated

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.

Reporting and Notification

Immediately report any suspected or confirmed information security incidents to the Information Security Office (ISO) either directly or through the distributed/node IT contact.

Email: sec-office@buffalo.edu

Phone: 716-645-6997

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.

Once notified, the ISO:

  1. Determines initial risk classification through initial incident analysis. The initial incident analysis considers:
    • Data risk classification
    • Number of systems, persons, accounts, or data records affected
    • Functional impact, information impact, and recoverability effort of the incident
  2. 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.
  3. Contacts the VPCIO to determine if and when to alert the VPCIO’s leadership team.
  4. Determines the appropriate personnel and roles.
  5. Prioritizes incident response in the event of multiple simultaneous incidents.

Incident Response Communication

The goals of incident response communication are to:

  • share response activities and procedures
  • update university stakeholders
  • provide appropriate transparency throughout the process to those requiring information
  • reduce conflicting messages and confusion about an event

Communication oversight:

  • All internal communications (emails to stakeholders, campus customers, etc.) should be vetted and approved by VPCIO, ISO, and UBIT Communication and Engagement.
  • All external communications will be coordinated by University Communications, VPCIO, ISO, and UBIT Communication and Engagement. See section, “External Communication” for more information.

Communication strategy should include:

  • Initial reporting of the incident to relevant constituencies
  • Communication with those affected
  • Communication with the university community
  • Communication with external entities as required

Communication plan should identify:

  • Appropriate messaging for each constituency group
  • Stakeholders
  • Individuals authorized to communicate about the incident
  • Communication channels
  • Schedule of communication
  • Procedures for notifying external entities, as required
  • Contact list
  • Response scripts to guide call handling or questions about the incident

Incident response is a team effort and effective communication supports a coordinated response. Therefore, establish and use secure channels to communication with:

  • Affected unit(s), department(s), or business owner(s)
  • UBIT-IRT
  • UB Emergency Management (see section below, “Communicating with UB Emergency Management”)
  • Senior leadership
  • External entities, as required

An incident may imply compromised communication channels. Therefore:

  • Do not share incident details with people outside the team responding to the incident.
  • Avoid sending sensitive data over unencrypted channels.
  • If it is reasonable to believe that the network is compromised, then communicate out-of-band using landline phones, faxes, cell phones, etc.

Confidential Information

  • Despite the need for transparency and ongoing communication, certain factors regarding the incident must be kept confidential within the UBIT-IRT.
  • What is considered confidential depends upon the specific nature of the incident and should be discussed within the context of the communication plan.

Communicating with UB Emergency Management

  • For Major Risk incidents, the ISO (or designee) is required to contact UB Emergency Management’s Senior Emergency Planning Coordinator.
  • 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:

  • Data Breach
  • Security Breach
  • Cyber Extortion Loss
  • Data Recovery Loss
  • Business Interruption Loss
  • Dependent Business Loss

Managing Incident Response

Major Risk Incidents

  • The ISO manages the overall response for Major Risk incidents or when multiple units are involved.
  • The ISO is required to contact the UB HIPAA Compliance Officer if the incident includes protected health information (PHI).

Moderate and Minor Risk Incidents

  • Depending on the nature, urgency, and impact of the incident, the ISO may directly manage or delegate responsibility of moderate and minor risk incidents.

UBIT Incident Response Team (UBIT-IRT)

  • ISO leads the 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.

Team Lead/Information Security Officer (ISO) and Information Security Contact (ISC)

Note: Depending on the nature and severity of the incident, a separate Information Security Contact (ISC) may be assigned in order to support the Information Security Officer (ISO).

  • Leads Information Security Incident Response and UBIT-Incident Response team
  • Classifies incidents according to risk
  • Trains UBIT-IRT
  • Manages communication between the UBIT-IRT, law enforcement, REN-ISAC, NYSERNet and other sites.
  • Ensures appropriate evidence gathering, chain of custody, and information/evidence preservation.
  • Prepares the written incident summary of the incident, After-Action Analysis Report, and corrective actions taken.
  • Collects and preserves pertinent information regarding the incident.
  • Works to contain, remediate, resolve, and document security incidents.
  • Determines if localized production services should be taken offline until incident resolution.

Legal Officer

  • Identifies legal obligations and applicable laws
  • Communicates with legal counsel, as necessary

Communication Officer

  • Leads the incident response communication strategy and plan.

Documentation Liaison

  • Collects relevant incident documentation. This function may be performed by the Team Lead or delegated.

Functional Representation

Provides specific expertise to:

  • Assist with proper evidence handling.
  • Ensure compliance with state and federal laws.
  • Ensure compliance with university policy.
  • Manage disciplinary actions for incidents involving university staff or students.

UBIT-IRT Functional Roles and Responsibilities

Roles and responsibilities depend upon the specifics of the incident.

  • Team leader
  • Assistant managers, supervisors, or group leaders
  • Help Center and/or triage staff
  • Incident handlers
  • Vulnerability handlers
  • Artifact analysis
  • Platform specialists
  • Trainers
  • Technology watch
  • Documentation liaison
  • Communication specialist
  • Support staff
  • Technical writers
  • Network or system administrators
  • Infrastructure staff
  • Programmers or developers
  • Web developers and maintainers
  • Media relations
  • Legal 
  • Law enforcement
  • Auditors or quality assurance
  • Marketing
  • Affected individuals/units

UBIT-IRT Incident Management Phases

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

  1. Preparation
  2. Detection
  3. Activation and or Response
  4. Containment
  5. Notification
  6. Remediation
  7. Resolution
  8. 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.
  • Computing hardware and software: Provide necessary equipment, including but not limited to: forensic harnesses, network traffic sniffers, sandbox and test bed equipment, and portable computing equipment.
  • Incident data: Include, but are not limited to: AV vendor data, web-based AV test sites, OS and application vendor data, AV logs, firewall logs, DNS data, system logs, Arcsight data, and IT staff contact information.
  • Documentation: Maintain local copies of the incident response plan, IT policies, standardized templates and other appropriate documentation.
  • Policy Library: Periodically review and update policies to ensure they are complete and up-to-date since technology, behaviors and compliance requirements change.
  • Other equipment and supplies: Provide telephones, fax machine, blank CD’s and DVD’s paper, pens, etc.
  • Equipment and personnel transportation.
  • Incident Response Templates-  http://UBIT-IRT .sans.org/score/incidentforms/

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:

  • The administrator or customer is familiar with normal operations.
  • Systems are equipped with effective auditing and logging tools.
  • Administrators review systems and logs to identify deviations from normal operations.
  • 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:

  • A machine reported by an ISO Incident report
  • A customer reporting that a machine is “acting strangely”
  • Warnings from a protective tool (Symantec-Endpoint, malware bytes, etc.) reports finding a worm, Trojan, or virus
  • Inability to connect to one or more virus protection vendor sites (sophos.com, symantec.com, mcaffee.com, trend.com)
  • Unexpected accounts or permissions
  • Unexpected programs configured to run at system startup
  • Unexpected running processes or scheduled jobs
  • Unexpected or sudden performance degradation in the absence of reported network or network application problems
  • Altered DNS and ARP tables or changes in the contents of the hosts file
  • Anomalous network configuration settings, connections sessions or ports
  • Unusual events in the system, security, and application logs
  • Unexpected pop-ups
  • Machine independently performing actions – for example: making sounds or screen changes

Phase 3: Activation and/or Response

  • It is mandatory to activate the UBIT-IRT for Major Risk incidents.
  • 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.
  • Information gathering, including affected (or potentially affected) individuals and systems.
  • 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
  • Determining how the attack was executed
  • Remove vulnerabilities/artifacts (e.g., rootkits, compromised applications, drivers, modules) left from the incident
  • Restore data
  • Add additional protective measures

Phase 7: Resolution

During the Resolution phase, normal business operations are restored. Steps include:

  • Handle incident resolution
  • Verify system performance and security before being brought back online
  • Complete tests and compare to baseline system activity (gathered in the Preparation phase) to ensure the system is verified before operations are restored

Phase 8: After-Action Analysis

UBIT-IRT collects and shares relevant After-Action Analysis documentation with stakeholders, as identified by the communication plan and strategy.

The purpose of After-Action Analysis is to document:

  • Incident handling findings
  • Relevant information from affected areas
  • Relevant information from all involved in the incident

The goals of After-Action Analysis are to provide information that supports and improves:

  • Risk assessment
  • Security posture
  • Production operations
  • Incident response procedures
  • Reducing potential ongoing threats

Documentation

  • Documentation should be collected and organized throughout the incident response.
  • Do not wait until after the incident is handled to begin the documentation process.
  • Use UBIT Help Center ticketing system, unless another method is agreed upon by ISO and VPCIO.
  • Documentation should be sequential and time/date stamped.
  • Include exact commands entered into systems, results of commands, actions taken (e.g., logging on, disabling accounts, applying router filters, etc.) and observations about the system and or incident.
  • Document all actions performed throughout the incident handling process.
  • Record all steps performed and all changes made to production systems and observations.

After-Action Analysis Report template is provided in Appendix H.

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

Information Security and Privacy Advisory Committee (ISPAC): Charged with evaluating, developing, and recommending information security and privacy policies, procedures, and operations vital to protecting and sustaining UB’s mission.

Information Security Mandate Team: Part of VPCIO’s Senior Management team who coordinates ongoing information security-related initiatives.

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.

Incident-Related Terms

Breach: Acquiring of information by a person without valid authorization or through unauthorized acquisition. Examples of a breach include, but are not limited to: loss or theft of device or media (e.g., computer, laptop, external hard drive, thumb drive, CD, tape); internal system breach; insider wrongdoing; external system breach (e.g., hacking); or, inadvertent disclosure.

Computer Security Incident: See “incident.”

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 A: Related Documents

University IT Resources

University Emergency Management Resources

External Resources

Incident Response Resources

Appendix B: Incident Response Quick Reference Guide

Information Security Incident Response Execution Phases

  1. Preparation: Identifying the individuals with requisite skills; Establishing communication protocols; Training and familiarization, tool acquisition; Practice
  2. Detection: Intelligence; Identification of anomalous events; Monitoring; Correlation; Analysis; Threat determination; Impact analysis; Damage assessment
  3. Activation and or Response: Activate UBIT-IRT
  4. Containment: Minimize and stop the damage; Preserve evidence.
  5. Notification: Notify individuals, entities, and or organizations per the university’s legal, regulatory, or affiliation agreement obligations.  
  6. Remediation: Remove artifacts left from attacker; Verify integrity; Restore data and systems
  7. Resolution: Return systems to production; Monitor
  8. After-Action Analysis: Document findings; Analyze event and response; and Implement improvements in system, infrastructure, and or application protection

Assessing the Suspicious Event, Machine, or Situation

Suggestions for examining a suspicious system; may help determine incident risk classification.

  1. To retain attacker’s footprints, avoid taking actions that access many files or installing tools.
  2. Look at system, security, and application logs for unusual events.
  3. Look at network configuration details and connections; note anomalous settings, sessions, or ports.
  4. Look at the list of customers for accounts that do not belong or should have been disabled.
  5. Look at a listing of running processes or scheduled jobs for those that do not belong.
  6. Look for unusual programs configured to run automatically at system’s start time.
  7. Check ARP and DNS settings; look at contents of the hosts file for entries that do not belong.
  8. Look for unusual files and verify integrity of OS and application files.
  9. Use a network sniffer, if present on the system or available externally, to observe for unusual activity.
  10. A rootkit might conceal the compromise from tools; trust your instincts if the system just doesn’t feel right.
  11. Examine recently-reported problems, intrusion detection, and related alerts for the system.

If You Believe a Compromise is Likely

  1. Immediately contact the ISO and your manager/supervisor.  The ISO will perform a forensic evaluation of a system without destroying evidence.
  2. Do not panic or let others rush you; concentrate to avoid making careless mistakes.
  3. If stopping an on-going attack, unplug the system from the network; do not reboot or power down.
  4. Take thorough notes to track what you observed, when, and under what circumstances.

Windows Initial System Examination Tips

Useful tools and commands when exploring a Windows OS for Normal Security Incidents:

  1. Review event logs: eventvwr
  2. Examine network configuration using: arp –a, netstat –nr
  3. Review open ports, network connections and related details: netstat –nao, netstat –vb, net session, net use
  4. Review customers and groups: lusrmgr, net users, net localgroup administrators, net group administrators
  5. Review scheduled jobs: schtasks
  6. Review auto-start programs: msconfig
  7. Review processes: taskmgr, wmic process list full
  8. Review services: net start, tasklist /svc
  9. Verify DNS settings and the hosts file: ipconfig /all, ipconfig /displaydns, more %SystemRoot%\System32\Drivers\etc\hosts
  10. Verify integrity of OS files: sigverif
  11. Research recently-modified files: dir /a/o-d/p %SystemRoot%\System32

Windows Explorer should be avoided since it modifies useful file system details. Instead, open a command window and use command-line commands.

Unix Initial System Examination

  1. Review event log files in directories (normally found in one of these, but could be located elsewhere): /var/log, /var/adm, /var/spool
  2. Focus on recent security events wtmp, who, last, lastlog
  3. Examine network configuration: arp –an, route print
  4. Review open ports, network connections and related details: netstat –nap (Linux), netstat –na (Solaris), lsof –i
  5. Review users: more /etc/passwd
  6. Review scheduled jobs: more /etc/crontab, ls /etc/cron.*, ls /var/at/jobs
  7. Check DNS settings and the hosts file: more /etc/resolv.conf, more /etc/hosts
  8. Verify integrity of installed packages: rpm -Va (Linux), pkgchk (Solaris)
  9. Review autostart services: chkconfig --list (Linux), ls /etc/rc*.d (Solaris), smf (Solaris 10+)
  10. Review running processes: ps aux (Linux, BSD), ps -ef (Solaris), lsof +L1
  11. Review recently-modified files: ls –lat /, find / -mtime -2d –ls

Appendix C: Detailed Incident Handling Procedures Checklist

Detection

  1. Notify the Information Security Officer (ISO).
  2. ISO logs the incident in the ticketing system.
  3. ISO contacts VPCIO and UBIT-IRT.
  4. ISO conducts an initial incident risk classification.
  5. Local support staff begins to or continues to mitigate the incident, depending on the nature of the incident.
  6. Begin documentation. Templates are available here: https://www.sans.org/score/incident-forms.
  7. Begin to develop and implement communication plan and strategy.

Activation

  1. UBIT-IRT is activated for Major Risk incidents or other risk levels as deemed necessary by ISO and VPCIO.
  2. ISO communicates with UB Emergency Management’s Senior Emergency Planning Coordinator for Major Risk incidents. 

Containment

  1. If possible, determine the cause of the incident and how the attack was executed.
  2. Remove threat.
  3. Take necessary steps to prevent incident from spreading.
  4. Document containment steps.

Notification

  1. Notify individuals, entities, and or organizations per the university’s legal, regulatory, or affiliation agreement obligations and in keeping with the communication plan and strategy.

Remediation

  1. Perform a vulnerability assessment and remediate vulnerabilities.
  2. Return systems to trusted state. For example, by re-imaging the workstation for a low risk event or restoring the server from a known good backup.

Resolution

  1. Compare system against original baseline gathered during preparation phase.
  2. Business units test the service and or system to verify functionality.
  3. Restore system to production environment.
  4. Perform ongoing system monitoring to ensure system integrity and detect incident recurrence.

After-Action Analysis

  1. Finalize incident response documentation, including the After-Action Analysis Report, and share with appropriate stakeholders as identified in the communication plan and strategy.
  2. Information provided to stakeholder groups and or individuals may vary depending on the need to know specifics of the incident.

Appendix D: Incident Questionnaire and Information Gathering

The following questions are illustrative, not exhaustive. Depending on the nature of the incident, it may be appropriate for additional questions to be considered.

Information Needed about Detection

  • What is the incident type?
  • What time was the incident detected?
  • How was the incident detected?
  • Who detected the infection?
  • What is the incident machine IP address and DNS name?
  • Who is the IT Support for the incident machine?
  • Was a Help Ticket created? What is the ticket number?
  • What time was the initial notification sent?
  • Was network access disabled?
  • Were people contacted? If so, who?

Information Needed from the User

  • Gather user’s contact information. User (name, email, phone #)
  • What is the user’s job function?
  • What is the primary function of this department? Who is the user’s manager/direct-report?
  • Does the user work with Category 1- Restricted Data, Category 2-Private Data, or covered PII data? If yes, what types of data?
  • How much sensitive data? (# of files, GBs?, file types, location)
  • What files did the user access during the time of the incident?
  • Did user work with research data? If so, what types of research data?
  • How much research data (# of files, size?, file types, location)
  • Does the user use university or departmental enterprise systems? If so, what level of access does the user have?
  • Does the user have access to shared network storage?
  • Are the shared drives automatically mounted?
  • Who else shares the data in those folders?
  • Did the user use encryption on files? If so, what kind(s) of encryption and where are the keys? ISO may require access to encryption keys.

Questions about the Incident

  • What was the user doing during the incident?
  • Did the user notice any strange things about the computer around that time?
  • Did the user receive any strange emails, or open any unknown attachments?
  • Did the user enter credentials (username, password) on any sites?
  • Did the user install any software?
  • Did the user receive any software updates?
  • Did the user’s antivirus software complain or alert?
  • Did the user notice a change in computer performance?
  • Did the user receive any strange Instant Messages?
  • Does the user use their computer for non-work related functions?
    • If so, what function(s)? Facebook/social media? Internet Radio? Email? Banking?

Information Needed from Departmental/Node IT Support

  • IT Support contact information (name, email, phone #)
  • Do they have shared drives?
  • Who has access to these drives?
  • What type of data is accessed or used by the system? HIPAA, FERPA, GLBA, University PII, etc.
  • Are they automatically mounted?
  • What types of security precautions have you placed on the system? (AV, Malware Bytes)
  • Is administrative access granted to the user?
  • What types of encryption are used?

Infection Details and Analysis

  • IT person (name, email, phone #)
  • Do they have shared drives?
  • Who has access to these drives?
  • Types of data (see above)
  • Are they automatically mounted?
  • What types of security precautions have been placed on the system?
  • What type of anti-virus is used?
  • Does the user have administrative access?
  • Is there file-based encryption? (think: TrueCrypt)
  • What type of encryption?

Incident Analysis

  • When was the first sign of an infection?
  • Was this sign indicative of the initial infection?
  • What is the confidence level of the initial infection notice?
  • Is a copy of the malware package available?
  • How long was the machine online after the first sign of an infection?
  • How long before the ISO was notified?
  • How many Command & Control (C&C) servers are involved?
  • Where are they located?
  • How much data went to each C&C server?
  • Are other devices on the network communicating with these C&C servers?
  • How much data was transferred between the time of the believed initial infection and when the device was pulled off the network?
  • Who were the top talkers?
  • Are they legitimate top talkers?
  • What other network security alerts were triggered by the device?
  • How much traffic remains for the incident period after the top talkers are removed?

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.

  1. 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
  2. Identify individual who are authorized to communicate about the incident to both internal and external constituencies.
  3. Internal communications channels
    • Email
    • Listserv (can be event specific)
    • Phone/video conferences
    • Meetings
    • Office phones
    • Cell phones
    • Others
  4. External communications channels
    • Email
    • Web, Blogs
    • Listserv (can be event specific)
    • Phone/video conferences
    • Meetings
    • Office phones
    • Cell phones
    • Others
  5. Schedule and frequency of communication
  6. 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.
    • Information that must be kept confidential within the UBIT-IRT.

Appendix F: Notification of External Organizations Involved in an Information Security Incident

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.

  1. Determine technical and administrative contacts of the source machine.
  2. Determine WHOIS is the contact for upstream provider, if one exists.
  3. Determine if a US-CERT or “abuse” email address exists if the source machine is from a foreign country.
  4. Contact abuse@buffalo.edu to see if other campus sites have been attacked/scanned by the source machine.
  5. Send a concise email to the WHOIS contact of the source machines. Include:
    • The source site’s US-CERT
    • Copy for ISO
    • Copy affected department(s) and personnel.
    • Log excerpts in text of e-mail. Do NOT send attachments or HTML.

Appendix G: After-Action Analysis Report Template

Executive Summary

  • Incident summary
  • Indicate if compromise been contained or event mitigated

Context and Background

  • Initial analysis of incident
  • Investigative procedures
  • Individual(s) performing investigation. Identify their roles/functional title.
  • Identify forensic tools used during investigation

Findings

  • Method of event detection: Monitoring, IDS, internal staff, external entity, etc.
  • Identify ALL systems analyzed and why:
    • Domain Name System (DNS) names
    • Internet Protocol (IP) addresses
    • Operating System (OS) version
    • Function of system(s)
  • Classification of data at risk or transaction affected
  • Established cause, mechanism, and source of incident
  • Start time and duration of access, if compromise
  • Any data view, exported, or modified during an intrusion
  • Relevant unknowns
  • Risk classification potential consequences and or damage, and simple explanation
  • Service disruption details and timeframes
  • Remediation steps performed

Notifications Required and Performed

  • Internal notifications: Chain of command, senior leadership, Information Security and Privacy Advisory Committee (ISPAC), and affected individuals.
  • Identify notification method.
    • The following is a recommendation for notification:
      • If fewer than ten individuals affected: email
      • Between ten and one hundred: email and hotline/calls to affected individuals
      • More than one hundred: to be determined by UBIT-IRT
  • External notifications: Law enforcement, government oversight agencies, and public
  • Any notification required by law or regulation

Recommendations for Improved Security

  • Review practices and compare to appropriate policy for data classification affected
  • Identify gaps with respect to normal controls
  • Identify compensating controls
  • Document risk analysis of gaps
  • Recommend controls improvements

Appendix H: Incident Type-Specific Required Representation

General Information Security Incidents (ransomware, malware, etc.)

Executive Representation

  • VPCIO
  • Unit Dean/VP where the incident is occurring
  • VP Communications

Functional Representation

  • Office of General Counsel
  • UBIT-IRT and ISO

GDPR Breach Notification

Executive Representation

  • VPCIO
  • Unit Dean/VP where the incident is occurring
  • VP Communications
  • Data Protection Officer (DPO)

Functional Representation

  • Office of General Counsel
  • UBIT-IRT and ISO

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.

Executive Representation

  • VPCIO
  • Unit Dean/VP where the incident is occurring
  • VP Communications

Functional Representation

  • Unit HIPAA Compliance Officer
  • UB HIPAA Compliance Officer
  • Office of General Counsel
  • VPCIO HIPAA Security and Privacy Officer
  • UBIT-IRT and ISO

PCI Security Incidents

Executive Representation

  • VPCIO
  • Unit Dean/VP where the incident is occurring
  • VP Communications
  • PCI representative

Functional Representation

  • Office of General Counsel
  • UBIT-IRT and ISO