Unit: Office of Information Technology (OIT)
Effective Date: 07/01/2013
Revision Date: 03/04/2024
Contact: Taylor Anderson, Chief Information Security Officer
Purpose
All information security incidents and suspected incidents should be reported and analyzed to determine the scope and severity. Evidence of an unauthorized intrusion of a system via an individual or malicious code must be carefully reviewed especially if that system contains any regulated, confidential or sensitive information.
Regulatory requirements and security best practices require an Incident Response Plan for appropriate oversight, management, remediation, recovery and documentation of all security incidents. The University of Alabama (UA) Information Security Incident Response Procedures meet that requirement.
Procedures
Introduction
All incidents at The University of Alabama should be reported and investigated to determine if the information exposed is managed in compliance with any regulation, law, contract or security best practice. Failure to report could result in individual disciplinary action, additional fines from regulatory entities, and/or loss of trust in the University by the community at large. To report an incident, contact the OIT IT Service Desk at itsd@ua.edu or 205-348-5555. An incident can be any unauthorized access to confidential or sensitive data through:
- Email: An attack executed via an email message or attachment—for example, exploit code disguised as an attached document or a link to a malicious website in the body of an email message
- Improper Usage: Any incident resulting from violation of an organization’s acceptable usage policies by an authorized user; for example, a user installs file sharing software leading to the loss of sensitive data; or a user performs illegal activities on a system.
- Web: An attack executed from a website or web-based application—for example, a cross-site scripting attack used to steal credentials or redirect to a site that exploits a browser vulnerability and installs malware.
Impersonation: An attack involving replacement of something benign with something malicious— for example, spoofing, man in the middle attacks, rogue wireless access points, and SQL injection attacks all involve impersonation. - Loss or Theft of Equipment: The loss or theft of a computing device or media used by the organization, such as a laptop, smartphone or authentication token.
- External/Removable Media: An attack executed from removable media or a peripheral device—for example, malicious code spreading onto a system from an infected USB flash drive.
- Attrition: An attack that employs brute force methods to compromise, degrade, or destroy systems, networks, or services (e.g., a DDoS intended to impair or deny access to a service or application; a brute force attack against an authentication mechanism, such as passwords, CAPTCHAS or digital signatures).
- Other: Any attack that does not fit into any of the other categories.
Depending on the data involved, one or more regulatory entities and/or affected individuals will require prompt notification. Detailed procedures for incident handling will be documented in “Playbooks”. An incident form should always be completed to track and manage all incidents.
Playbooks are the detailed procedures maintained within the appropriate organizations that manage incidents such as HIPAA entities or the OIT Security Team.
This incident response plan will be tested a minimum of once per year.
Authority
The University Emergency Management Team (see below), the Vice Provost and Chief Information Officer (CIO), Deputy Chief Information Officer (Deputy CIO) along with the Chief Information Security Officer (CISO) are responsible for the oversight and management of all information security incidents. This includes unauthorized exposure of any and all sensitive and/or regulated information within any University Department or College. This authority is granted by the Provost and the Vice President of Finance and Operations.
The CIO is responsible for the appointment of the CISO and the designation of the University HIPAA Security Officer. A single individual may have both roles.
Most investigations, large or small, require access to sensitive or restricted information. For that reason, OIT Security will request approval from appropriate authoritative groups for permission to perform investigative functions. Appropriate authoritative groups include Human Resources, Legal Counsel, University of Alabama Police Department, a Dean or Vice President.
Incident Management
The University of Alabama Incident Response Team will utilize concepts from the NIST SP 800-61 Computer Security Incident Handling Guide to work through incidents. The basic process utilizes the following high-level steps.
Preparation
The UA incident response methodologies emphasizes preparation—not only establishing an incident response capability so that the University is ready to respond to incidents, but also preventing incidents by ensuring that systems, networks, and applications are sufficiently secure.
Detection & Analysis
The most challenging part of the incident response process is accurately detecting and assessing possible incidents—determining whether an incident has occurred and, if so, the type, extent, and magnitude of the problem.
Containment, Eradication and Recovery
Containment is important before an incident overwhelms resources or increases damage. Most incidents require containment, so that is an important consideration early in the course of handling each incident. Containment provides time for developing a tailored remediation strategy. An essential part of containment is decision-making (e.g., shut down a system, disconnect it from a network, disable certain functions).
After an incident has been contained, eradication may be necessary to eliminate components of the incident, such as deleting malware and disabling breached user accounts, as well as identifying and mitigating all vulnerabilities that were exploited. During eradication, it is important to identify all affected hosts within the University so that they can be remediated. For some incidents, eradication is either not necessary or is performed during recovery.
In recovery, administrators restore systems to normal operation, confirm that the systems are functioning normally, and (if applicable) remediate vulnerabilities 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). Higher levels of system logging or network monitoring are often part of the recovery process. Once a resource is successfully attacked, it is often attacked again, or other vulnerable resources within the organization are attacked in a similar manner.
Eradication and recovery should be done in a phased approach so that remediation steps are prioritized. For large-scale incidents, recovery may take months; the intent of the early phases should be to increase the overall security with relatively quick (days to weeks) high value changes to prevent future incidents. The later phases should focus on longer-term changes (e.g., infrastructure changes) and ongoing work to keep the enterprise as secure as possible.
Post-Incident Activity
One of the most important parts of incident response is learning and improving. A “lessons learned” meeting will be held with all involved parties after a major incident, and optionally periodically after lesser incidents as resources permit, for the purpose of improving security measures and the incident handling process itself. This meeting provides a chance to achieve closure with respect to an incident by reviewing what occurred, what was done to intervene, and how well intervention worked. The meeting should be held within several days of the end of the incident. Questions to be answered in the meeting include:
- Exactly what happened, and at what times?
- How well did staff and management perform in dealing with the incident? Were the
documented procedures followed? Were they adequate? - What information was needed sooner?
- Were any steps or actions taken that might have inhibited the recovery?
- What would the staff and management do differently the next time a similar incident
occurs? - How could information sharing with other organizations have been improved?
- What corrective actions can prevent similar incidents in the future?
- What precursors or indicators should be watched for in the future to detect similar
incidents? - What additional tools or resources are needed to detect, analyze, and mitigate future
incidents?
Categories
Incidents will generally fall into three categories – Low, Medium and High. Each incident should have a designated Incident Commander with overall responsibility for oversight and management of the incident from initial notification through remediation and post incident analysis.
Level | Description | Incident Commander |
---|---|---|
Low | Any information security incident that generally does not involve exposure of any sensitive or restricted information. | A member of the OIT Security Team |
Medium | Any information security incident that involves unauthorized access to regulated or sensitive data such as protected health information, payment card data and/or personally identifiable information. An event where the initial analysis will likely lead to the notification of a significant number of individuals. Any event within a CUI environment that requires notification to DoD within 72 hours. Any event involving Florida Department of Law Enforcement CJI data that requires notification to the FDLE Information Security Officer. Any event involving Alabama Law Enforcement Agency CJI requires immediate notification to ALEA Network Control Center. | Chief Information Security Officer (CISO) or their designee |
High | Any information security incident that affects the primary mission of the University, including significant disruption of the ability to provide basic education and academic services on campus. Any event that requires immediate notification and engagement of our cyber insurance provider. | University of Alabama Emergency Management Team Incident Commander, Vice Provost and Chief Information Officer (CIO) |
Incident Categories with Level, Description, and Incident Commander
Low
The majority of the incidents are considered low, and the Incident Commander will be a member of the Office of Information Technology (OIT) security team. Examples of low-level incidents are events that do not involve unauthorized access or exposure to sensitive or confidential information. Examples include:
- Virus and Malware Removal
- Basic Phishing Attacks
- External Abuse Notifications
- External Data Discovery
- Unrestricted data disclosure
- Scam Activity
- Leaked Credentials
Medium
Medium-level incidents may involve the exposure of sensitive or confidential data that will require thorough investigation leading to possible notification of the individuals discovered. Medium incidents include those that occur within CUI (Controlled Unclassified Information) environments.
Medium incidents will have participation from the following organizations:
- Strategic Communications
- Legal Counsel
- OIT Security
- UA Department(s) and/or College(s) involved
- Risk Management
- DoD DC3 (Department of Defense Defense Cyber Crime Center via DIBNet, for CUI
incidents) - FDLE (Florida Department of Law Enforcement, for FDLE CJI incidents)
- ALEA (Alabama Law Enforcement Agency, for ALEA CJI incidents)
- ALEA Network Control Center – 1-800-392-8025
- Computer Incident Response Form – Attachment B in ACJIC Security Policy, V2.1, Page 18-19
High
High Level Incidents will be coordinated by the University Emergency Management Team, and they will designate the Incident Commander. High-level incidents are those incidents that affect University operations, and/or require immediate notification of the cyber insurance provider. To initiate the Emergency Management process, the CIO or designee will call UAPD at 205-348-5454 and tell them we have a high-level information security incident that requires activation of the EOC. An OIT representative, typically the Executive Director of IT Operations, will become a member of the University’s emergency response team.
Each incident will vary in nature based on the circumstances and the information involved. Therefore, each incident will require participation from other organizations. Some possible additional participants include, but are not limited to:
- Human Resources
- Registrar
- Research
- External Security Investigators
- Law Enforcement (internal and/or external)
- Data Steward(s)
- Application Owner
- System Administrator
- HIPAA Entity Security Officer
- HIPAA Entity Privacy Officer
- University HIPAA Privacy Officer
OIT Vendor Contact Information
Breach notification and credit monitoring: IDX (Identity Experts)
ian.kelly@idx.us – request SOW w/ approx. number of impacted users, whether they need breach communication services and/or call center services and length of credit monitoring required.
Forensic Consulting: Crowdstrike
For Incident Response or Forensic Investigation Services, OIT Security will call the 24/7 Incident Response Hotline number below. A live agent will collect information and connect the caller to a responder.
Americas: +1 (408) 663-5300
Alternatively, email may be used: services@crowdstrike.com*
- If you believe the email infrastructure may be compromised, send this email from a 3rd party email address (e.g., Gmail).
Responsible Parties
Credit Card/Debit Card Data (Payment Card Industry Data Security Standards: PCI DSS) – Primary individuals responsible: Executive Director of Student Accounts and the CISO. This should not include internal University credit card data such as P–Card.
Protected Health Information (Health Insurance Portability and Accountability Act: HIPAA) – Primary individuals responsible: University HIPAA Security Officer (CISO) and the University HIPAA Privacy Officer. The HIPAA entity or Business Associate Privacy and Security Officers will also play a significant role.
Personally Identifiable Information (PII as defined by the Alabama Data Breach Notification Act) – Defines the detailed procedures associated with the investigation and notification of a breach related to the unauthorized access and/or exposure of PII. Primary individuals responsible: CISO, Associate/Assistant Vice President of Human Resources, and the Associate/Assistant Vice President of Finance and Operations.
Financial Aid Records (Gramm–Leach–Bliley Act) – Primary individuals responsible: Executive Director of Financial Aid and/or the Executive Director of Student Services, and the CISO.
Education Records (Family Educational Rights and Privacy Act: FERPA) – Primary individuals responsible: Registrar and the CISO.
Research Data (Research data that requires notice to the data/grant owner/provider) – Primary individuals responsible: Office of Institutional Research and the CISO.
Viruses, Malware, Intrusions, Ransomware, and Compromised Systems (That do not involve the unauthorized access or exposure of any data mentioned above) – Primary individuals responsible: CISO.
Communication and Notification of Events – Primary individuals responsible: OIT communications representative and Strategic Communications representative.
DoD CUI Records (Controlled Unclassified Information: DFARS) – Primary individuals responsible: OIT (CISO) and ORED representative.
FDLE CJI Records (Criminal Justice Information) – Primary individuals responsible: OIT (CISO), DDRC representative, and FDLE Information Security Officer.
ALEA CJI Records (Criminal Justice Information) – Primary individuals responsible: OIT (CISO), UAPD Chief of Police, and UAPD LASO (Local Agency Security Officer).
Scope
The scope of this Plan includes the management of any incident, as defined above, within any and all University Departments and Colleges.
All University Departments and Colleges may also play a role as defined in this incident response plan. This role is either through the information ownership/stewardship or the University organizational responsibilities (e.g. Law Enforcement, Legal Counsel, Strategic Communications, etc.).
This IT Standard should be observed by:
- Students
- Faculty
- Staff
- Contractors/Suppliers
- Anyone accessing University systems of data
Definitions
- Abuse notifications: Communications and awareness of an incident, breach or compromise
from either an internal or external source. - Breach, compromised system, cyber breach event, unauthorized intrusion: An incident or
activity that affects the confidentiality, integrity and/or availablility of a computer system or
information on a computer system either intentionally or unintentially by an untrusted source
using manual or automated interactions. - Computer system: A very generic term for any desktop, laptop, server, mobile phone or tablet,
or any basic internet connected device that performs services such as door locks, lights,
cameras, personal internet assistant, internet attached appliance, TV, etc. - External data discovery: Communications and awareness of confidential University
information at an unauthorized location. - FERPA: Family Educational Rights and Privacy Act – Federal regulation that defines controlling
access and release of student information. - HIPAA: Health Insurance Portability and Accountability Act – Federal regulation that defines the
management of protected health information. - Information Security Incident (Incident): Unauthorized activity/access that affects the
confidentiality, integrity and/or availability of a computer system or information on a computer
system through through a breach, compromised system, cyber breach event, unauthorized
intrusion or unauthorized disclosure from a user with authorized access. - Incident Commander: Individual identified at the initiation of an incident to oversee the
activities related to the management and remediation of the incident. - Malicious code, malware, virus: Unauthorized software/scripts that perform
unintended/unwanted activities on a computer system. This unwanted software maybe injected
into the system via download from websites, file attachments or network access to
vulnerabilities. - NIST: The National Institute of Standards and Technology (https://www.nist.gov/)
- PCI DSS: Payment Card Industry Data Security Standards – Industry regulation that defines
management of processing, transmission, and/or storage of card holder data (credit/debit card). - PII: Personally Identifiable Information – as defined by local, state and federal mandates. For PII
associated with and resident of Alabama, refer to the definition provided in the 2018 Alabama
Breach Notification Act. - Phishing: An attempt to steal information from an individual via bogus request or bogus
websites requested in email, phone call or through social media. - Playbook: For this incident response plan, a detail list of procedures and checklists to manage
various incidents. Playbooks will be developed to accommodate the requirements for different
incidents based on regulation or security best practice. - Ransomware: A specific type of malious code or malware that encrypts data on a computer
system and request payment for the encryption key to return the data to it’s previous state. - Regulatory requirements: Mandates normally through law or industry standards that define the
management and control of information. - Scam: An attempt to steal from a target or group of targets that may also involve extortion of
money as well as information. - Vulnerability: A weakness in a computer system that may be exploited to gain unauthorized
access to information, services or controls.
Approved By:
- Taylor B. Anderson, UA Chief Information Security Officer (CISO)
- John McGowan, Vice Provost and Chief Information Officer (CIO)
- Mike Shelton, UA Deputy Chief Information Officer