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 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: August 28, 2024

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

Back to Top

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

Back to Top

UBIT Help Center: 716-645-3542

UBIT Information Security Office: 716-645-6997

VPCIO Office: 716-645-7979

UBIT Organization & Contact Information: http://www.buffalo.edu/ubit/about/our-people.html

UB University Police (Emergency): 716-645-2222 (off campus, dial 911)

UB University Police (Non-emergency): 716-645-2227

UB Hazardous Materials: 716-829-3301

UB Emergency Information and Alerts: http://emergency.buffalo.edu

UB Human Resources: 716-645-7777

UB Student Judiciary (Student Conduct and Advocacy): 716-645-6154

UB Alumni Office: 716-645-3312

UB Legal (President’s Office): 716-645-2901

SUNY General Information: 518-320-1100 (SUNY CISO: Ken Runyon)

NY State Incident Reporting Site: https://its.ny.gov/incident-reporting

REN-ISAC General Information: 812-856-0717 (Contact Info: https://www.ren-isac.net/contact/index.html)

Back to Top

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.

Back to Top

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.

Back to Top

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.

Back to Top

This plan aligns with:

• Data Risk Classification Policy
  
• Protection of University Data Policy
• VPCIO Organization Continuity of Operations 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.”

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)

Back to Top

Information security incidents are considered in-scope if they substantively and negatively affect confidentiality, integrity or availability of the university’s:

• Operations, finances, or reputational standing
• Ability to comply with regulatory or legal requirements
• Information technology assets, systems, or data  

Examples of possible in-scope incidents, depending on severity and impact:

• 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

Examples of out-of-scope incidents:

• Complaints of copyright violation
• Computer assets not containing university data and not owned by the university
  
• 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

Back to Top

• 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

Back to Top

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

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 significant 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 (e.g., system-wide outage). This includes devices that are used to administer network and other computer systems as indicated above.

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.

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

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

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  

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 

Regular: Time to recovery is predictable with existing resources

Supplemented: Time to recovery is predictable with existing and 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 informational 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.

Back to Top

Security is everybody's job. Employees should immediately report any suspected or confirmed information security incident to the UBIT Help Center at buffalo.edu/ubit/help or 716-645-3542. The UBIT Help Center will escalate the notification on your behalf to the ISO. 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, informational impact, and recoverability effort of the incident
2. Activates response:
   • For Major Risk incidents, activate the UBIT-IRT.
   • 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.

Back to Top

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 affected parties
  
• 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.

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

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

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

Back to Top

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

Back to Top

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

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

Back to Top

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

Roles and responsibilities depend upon the specifics of the incident.

Back to Top

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

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 skill sets.
• 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- 
  https://www.sans.org/information-security-policy/?page=3

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 (Defender, 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

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

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.
  • Two phases within the short-term containment:
    • Quarantine (containment to the UB network/keep UB from attacking anyone else).
    • Isolation (keep the affected system from attacking any other systems at UB).
      
    • Information gathering, including affected (or potentially affected) individuals and systems.
• Long-term containment, including making changes to the production system.

• 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.
• Notify individuals, entities, and/or organizations as per the university's legal, regulatory, or affiliation agreement obligations.
  

The goal of the Remediation Phase is to clean a system and make it operationally ready to resume service. Remediation may extend beyond the resolution of the incident. 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

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

• Handle incident resolution (complete steps required to close out the incident).
  
• 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.
• Schedule after-action analysis.
• Close the incident
• Under the direction of the ISO, a contingent/representative from the ISO's office works/coordinates with the affected area/unit to identify and recommend changes to business, operational, or functional processes in order to reduce the risk of incident recurrence.
  

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 (reduces risk)
  
• Security posture
• Production operations
• Incident response procedures
• Security control effectiveness and efficiency
  

Back to Top

• Documentation should be collected and organized throughout the incident response.
  • Do not wait until after the incident is handled to begin the documentation process.
  • Time/date stamp documentation and organize sequentially.
• Use UBIT Help Center ticketing system, unless another method is agreed upon by ISO and VPCIO.
• As applicable, include:
  • Exact commands entered into systems
  • Results of commands
  • Actions taken (e.g., logging on, disabling accounts, applying router filters, etc.)
    
  • 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.

Back to Top

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.

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:

(1) Allows an attacker to conduct information gathering activities or

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

Back to Top

Data Risk Classification Policy

Information Security: Data Access and Security Policy

Protection of University Data Policy

Social Security Number Policy

UB CIO Organization Continuity of Operations Plan

UB Minimum Security Standards for Desktops, Laptops, Mobile, and Other Endpoint Devices

UB Minimum Server Security and Hardening Standards

UBIT Major Incident Process Design

University Security Breach Protocol

Emergency Management Program Policy

UB Alert

UB Emergency Management

UB Emergency Management: Emergency Procedures-Cyber

Federal Trade Commission Red Flags Requirements

Gramm-Leach-Bliley Act

Health Insurance Portability and Accountability Act (HIPAA)

National Institute of Standards and Technology Computer Security Incident Handling Guide

NYS Breach Notification Procedure

NYS Business Law

NYS Cyber Incident Response Standard

Payment Card Industry Data Security Standards

SANS Institute: Sample Incident Handling Forms

U.S. Department of Education: Data Breach Response Checklist

U.S. Department of Education: FERPA

Back to Top

Critical Log Review Checklist for Security Incidents

Linux Intrusion Discovery Cheat Sheet

Security Incident Survey Cheat Sheet for Server Administrators

Windows Intrusion Discovery Cheat Sheet

Back to Top

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

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.

1. Immediately contact the UBIT Help Center and alert your manager/supervisor who will then contact the ISO in the event that the Help Center is not available.  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.

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.

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)
9. Review autostart services: chkconfig --list (Linux)
   
10. Review running processes: ps aux (Linux, BSD), lsof +L1
11. Review recently-modified files: ls –lat /, find / -mtime -2d –ls

Back to Top

Security is everybody's job.

Employees should immediately report any suspected or confirmed information security incident to the UBIT Help Center at buffalo.edu/ubit/help or 716-645-3542. The UBIT Help Center will escalate the notification on your behalf to the ISO.

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, activate the UBIT-IRT.
   • For Moderate Risk and Minor Risk incidents, the ISO and VPCIO determine if UBIT-IRT 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 instances.
   

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.

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.

Back to Top

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

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

Back to Top

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

1. Notify the Help Center.
   
2. Help Center notifies the ISO.
3. ISO logs the incident in the ticketing system.
4. ISO contacts VPCIO and UBIT-IRT.
5. ISO conducts an initial incident risk classification.
6. Local support staff begins to or continues to mitigate the incident, depending on the nature of the incident.
7. Begin documentation. Templates are available here: https://www.sans.org/information-security-policy/?page=3
   
8. Begin to develop and implement communication plan and strategy.

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. 

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.

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.

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.

[Close the incident response: Resume normal operations]

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.

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.

Back to Top

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?

Back to Top

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.

Back to Top

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.

Back to Top

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

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

• 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

• 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

• 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

Back to Top

Executive Representation

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

Functional Representation

• Office of General Counsel
• UBIT-IRT and ISO

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

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

Evaluate for breach notification and breach notification requirements.

Executive Representation

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

Functional Representation

• Office of General Counsel communicates breach information to the state
  
• UBIT-IRT and ISO

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

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

Back to Top

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

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.
  

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

• Leads the incident response communication strategy and plan.
  

• Collects relevant incident documentation. This function may be performed by the team lead or delegated.
  

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.
  

Back to Top