Purpose
The purpose of this document is to clearly describe the processes used by the Office of Information Technology (OIT) at The University of Alabama in Huntsville (UAH) to mitigate the risks from computer security incidents by responding to incidents effectively and efficiently. The primary focus of this document is detecting, analyzing, prioritizing, handling, and recovering from incidents.
Scope
Ensuring the confidentiality, integrity and availability of UAH data and IT resources is a responsibility shared by all members of the UAH community who use UAH networks. As such, this policy applies to all individuals, including faculty, staff, students, and visitors, schools, departments, affiliates, and other similar entities within the UAH community, including employees of contracted or outsourced non-UAH entities.
Terms
Event - any observable occurrence in a system or network. Events include a user connecting to a file share, a server receiving a request for a Web page, a user sending electronic mail (email), and a firewall blocking a connection attempt. Adverse events are events with a negative consequence, such as system crashes, network packet floods, unauthorized use of system privileges, unauthorized access to sensitive data, and execution of malicious code that destroys data. This document addresses only adverse events that are computer security-related and excludes adverse events caused by sources such as natural disasters and power failures.Normal operation of a system or network generates a myriad of events.
Incident - synonymous with the phrase, computer security incident, which is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices. Examples of incidents are but not limited to the following:
- Digital Millennium Copyright Act (DMCA) violation
- A potentially successful “phishing” email
- Malicious Code (i.e. Malware)
- Unacceptable Use
- Unauthorized Use or Access
Important note: It is VERY IMPORTANT that at no time does anyone refer to an incident as a “breach” without prior approval from the UAH CIO, CISO or University Executive Management. This is a reserved legal/privacy term and use of this word can have organizational impact.
The goal of incident response is to restore normal service operation as quickly as possible following an incident, while minimizing impact to business operations and ensuring quality is maintained. In order to facilitate these goals, SOC procedure/process “playbooks” have been established for most common incident types.
Plan
UAH’s incident response process is broken into several phases, from detection and analysis of the event through post-incident recovery of the affected service or system. The major steps involved with UAH incident response are similar to those found in the National Institute of Standards and Technology (NIST) Special Publication 800-61, Computer Security Incident Handling Guide.
1.0 Phase 1 - Detection & Analysis
The incident responder(s) must work quickly to analyze and validate any potential incident; incident playbooks are available for many common incidents and provide a standardized starting point to facilitate incident response. When an incident has occurred or is suspected, the responders should quickly determine the scope of the incident, including which system(s), network(s), and/or UAH service(s) are affected, an initial estimate of who or what originated the incident, and how the incident is occurring (attack methods being used, vulnerabilities being exploited, etc.). This initial information and analysis should be provided to the UAH IT Security Incident Response Team (IT-SIRT) at it-sirt@uah.edu or (256) 824-3333.
The IT-SIRT, under the guidance of the UAH Chief Information Security Officer (CISO), Chief Information Officer (CIO), or other OIT Director shall conduct deeper analysis of the effects of the incident. This analysis should take into account the classification of potentially affected data or assets.
In cases where this analysis indicates a potential reason to believe that compromised information (a) may be used to the injury of the United States or to the advantage of any foreign nation, (b) contains trade secrets involving economic espionage, or involves data or assets belonging to the Federal Government, the UAH Facility Security Officer (FSO) and Information System Security Manager (ISSM) shall be immediately notified.
In other cases, the UAH CIO, CISO, or their designee shall make the determination if/when other entities are notified subject to section 6.0 – Elevated Incident Escalation
1.1 Prioritization of Incidents
When the incident queue length is low and/or increasing at a slow rate, incidents can be worked on the order in which they are received. However, this may not always be feasible. As such, it may become necessary to prioritize incidents to mitigate those with the greatest possible impact first. In such a situation, prioritizing the handling of the incident may be the most critical decision point in the incident handling process. When resources do not allow incidents to be worked simultaneously, incidents should not be handled on a first-come, first-served basis. Instead, handling should be prioritized based on two factors: impact and urgency.
1.1.1 Urgency
The urgency of an incident is concerned with how quickly a resolution is required. This urgency is determined not only by the current effect of the incident but also the likely effects of the incident if it is not immediately contained.
The levels of urgency are:
| High |
Incident prevents university operations, support, or services |
| Moderate |
Incident degrades or impairs business operations, support, or services |
| Low |
Incident partially degrades or impairs business operations, support, or services |
1.1.2 Impact
The impact of an incident considers the scope, type, and identity of resources potentially affected by an incident. The criticality of a resource is based primarily on its data or services classification, visibility, and frequency of use.
The levels of impact are:
| High |
- Prevents multiple users from performing tasks critical to normal operations
- May affect many users in the same or multiple offices
- Affects multiple university executive management
- Pertains to unauthorized access or modification of data classified as “Restricted” in accordance with the UAH Protection of Data Policy
|
| Moderate |
- Prevents or disrupts multiple users from performing tasks; this results in minor impact to normal operations
- A single service is down or severely degraded
- Affects a single member of university executive management
|
| Low |
- A single service is degraded and multiple users may be inconvenienced
- Multiple services are affected for a single user
|
To assign a severity rating for an incident, organizations should consider the urgency and impact of the incident and reference the table below:
| Urgency ↓ Impact → |
High |
Moderate |
Low |
| High |
Critical |
High |
Moderate |
| Moderate |
High |
Moderate |
Guarded |
| Low |
Moderate |
Guarded |
Low |
Incidents that are rated Critical and High on the table above are considered Elevated Incidents and should be given the highest priority due to the nature of their severity.
| Severity Level |
Type of Incident |
| Critical |
Elevated Incident |
| High |
Elevated Incident |
| Moderate |
Normal Incident |
| Guarded |
Normal Incident |
| Low |
Normal Incident |
2.0 Phase 2 - Containment
When an incident has been detected and analyzed, it is important to contain it before it spreads and overwhelms available resources or increases the damage done. Most incidents require containment, so it is important to consider it early in the course of handling each incident. An
essential part of containment is decision-making (e.g., shut down a system, disconnect it from a wired or wireless network, disconnect its cable, disable certain functions, etc.)
Containment also may include the preservation of digital evidence. It is generally desirable to acquire evidence from a system of interest as soon as one suspects that an incident may have occurred. Many incidents cause a dynamic chain of events to occur; an initial system snapshot may do better in identifying the problem and its source than most other actions that can be taken at this stage. From an evidentiary standpoint, it is much better to get a snapshot of the system as-is rather than doing so after incident handlers, system administrators, and others have inadvertently altered the state of the machine during the investigation. Users and system administrators should be made aware of the steps that they should take to preserve evidence. Finally, some incidents may require the involvement of law enforcement. The goal of containment is to limit the scope and magnitude of an incident and to keep it from getting worse.
3.0 Phase 3 - Eradication & Recovery
3.1 Eradication
After an incident has been contained, resolution of the incident may involve steps to eliminate components of the incident, such as deleting malicious code and disabling breached user accounts. For some incidents, eradication is either not necessary or is performed during recovery. The goal of eradication is to mitigate the factor(s) that resulted in the incident.
3.2 Recovery
In recovery, systems are restored to normal operation and (if applicable) hardened to prevent similar incidents. Recovery may involve such actions as restoring systems from clean backups, rebuilding systems from scratch, replacing compromised files with clean versions, installing patches, changing passwords, and tightening network perimeter security (e.g., firewall rulesets, boundary router access control lists). It is also often desirable to employ higher levels of system logging or network monitoring as part of the recovery process, even if only temporarily to ensure a repeat of the incident does not occur.
4.0 Phase 4 - Post-Incident Activity
Post incident activities include completing any documentation that was not completed during the incident, as well as any additional documentation that may be beneficial in future incidents, such as lessons learned. The overall goal is to learn from the incidents that occurred to improve the team’s performance and provide reference materials in the event of
a similar incident.
Based on a post-incident review with the UAH President or his appointed designee, the unit(s) experiencing the incident may be responsible for all costs related to investigations, cleanup, and recovery activities resulting from the compromise, response, and recovery.
5.0 Elevated Incident Escalation
Any elevated incident requires notification to the CISO in addition to the IT-SIRT distribution group. The CISO will immediately share this information with the CIO and OIT Directors. Further, this elevated incident may require the assembly of an Executive Incident Team with concurrence of the UAH President to advise and assist the ongoing investigation and decision making. The nature of the incident and the type(s) of data involved will determine the composition of the Incident Team, and it typically will include the following or their designee:
● Chief Information Officer (CIO)
● Chief Information Security Officer (CISO)
● Office of Counsel
● Provost
● Vice President of Finance and Administration
● Vice President or Dean for the university unit(s) involved
● Office of Risk Management
Depending on the details of the incident that have been uncovered during the initial investigation, other individuals and groups may be notified as necessary for appropriate incident response. These individuals and groups include but are not limited to:
● UAH President
● PCI Committee
● Office of Media and Communications
● UAH Police Department – must be notified if the incident involves a crime or the potential of a crime
● HIPAA Security Officer – must be notified if the incident involves or potentially involves PHI data or other data protected by the Health Insurance Portability and Accountability Act
● UA Systems Office CISO – must be notified if there is a potential cyberinsurance claim, the incident involves sensitive or confidential data as defined by the UAH Protection of Data Policy, or government-owned data or information
5.1 Breach Notification
In all cases, any investigation of an incident that involves state- or federally-regulated data (Personally Identifiable Information (PII), Payment Card Information (PCI) data, Personal Health Information (PHI), data protected by the Family Educational Rights and Privacy Act (FERPA), and similarly protected data, the Executive Incident Team will make Breach Notification determinations in accordance with state and federal legal, contractual requirements, compliance requirements, risk, and outcome of the incident investigation. Likewise, the Executive Incident Team will make all determination regarding official communications about elevated incidents.
Per the UA System Breach Response Summary document, any breach that involves a claim or loss that is reasonably expected to result in claim expenses that will exceed $250,000, the UAH General Counsel, CISO, CIO, or Risk Manager must immediately notify the UA System office of the potential issue.
6.0 Cyberinsurance Claims
Certain incidents may make it necessary to file a claim against the UA System cyberinsurance coverage. The Executive Incident Team will make the determination as to whether a claim will be necessary and will notify the UA System CISO and Risk Management Office. In general, the following scenarios require notification to the UA System:
● Any lawsuit alleging failure to protect confidential information.
● Demand for damages (for example, letter from lawyer, etc.) alleging failure to protect confidential information.
● Regulatory notice or investigation alleging activities (or failures to act) related to our information services (includes OCR notice of complaints related to data breach or other information privacy issue).
● Any event disclosing records containing PHI or PII of 100 or more individuals.
● Network interruption of 10 hours or more triggered by or involving an intrusion or unauthorized access.
● Any significant event that may result in expenses greater than $100,000.
● Any event that is expected to, or does, receive adverse media attention or inquiries.
Review
The UAH CIO is responsible for the review of this procedure every three years (or whenever circumstances require).