Information Technology Incident Response Plan
Authority: Information Technology
Date Enacted or Revised: Enacted June 16, 2020; Revised March 11, 2022; July 22, 2024
Purpose
Security incidents must be reported promptly through the proper University and/or University System channels and resolved by designated professionals in a manner that is consistent with University policies, applicable laws, and this plan.
This document establishes the procedures for identifying, reporting, and responding to an information security event. It establishes the basic language to discuss such events, identifies roles and responsibilities involved in responding to and recovering from these events, and provides a process for handing these events from the time an event is detected to the final debriefing and closeout.
Users of McNeese information technology resources should be familiar with the sections of this plan related to identifying and reporting information security incidents.
The objectives of the Incident Response Plan are to:
- Enable the University to respond to an information security incident without delay and in a controlled manner;
- Enable assessment of mitigation measures that can be taken to protect information, assets, and privacy and limit or prevent damage during an active incident;
- Provide a framework that supports the protection and preservation of evidence in the event of illegal or criminal activity;
- Ensure provision of timely notification of those who need to know, including but not limited to University management, federal and/or state agencies, and business partners;
- Ensure that communications with the public/media are handled appropriately by designated University personnel;
- Support completion of all required investigation, documentation, appropriate notifications, and remediation in a timely and organized manner; and
- Continuously improve the way the University handles information security events.
Definition and Scope
Information security incidents are events that have the potential to compromise the confidentiality, integrity, or availability of University information and/or information technology resources.
The Incident Response Plan should be followed when the following types of events occur:
- Any unauthorized access to University-owned and/or controlled information and/or technology resources, including any potential data breach;
- Any such incident involving a member of the University community, including but not limited to students, faculty, staff, guests, volunteers, partners, and visitors; and/or
- Any such incident involving services provided by third parties to the University, such as contracted vendors, partner institutions, etc.
Examples of Information Security Incidents
- Computer account(s) accessed by an unauthorized person
- Compromise of credentials resulting from malware infection, phishing attack, or improper disclosure of password(s) to an unauthorized person
- Device(s) infected with ransomware
- Unintentional or intentional disclosure of protected University data to an unauthorized person or people
- Evidence that someone tampered with a computer account (e.g., account sending spam)
- Unauthorized access to, alteration of, or activity within a University information system (e.g., unexplained or unauthorized code changes, compromised/defaced website, etc.)
- Physical theft/breach (e.g., broken doors to IT facilities, stolen computers, etc.)
- Stolen or lost laptop, tablet computer, or smartphone
- Denial of Service attack
- Notification of publicly posted University credentials
- Red flags (as required by FTC Red Flags rule) or identity theft
- Risks or circumstances that are likely to result in any of the above
- Notification from a cloud-computing vendor of a breach involving McNeese data
If it is not clear whether a specific situation constitutes an information security incident, report it and the Office of Information Technology will make the determination. If it is not clear whether this plan applies to a particular situation, the McNeese chief information officer (CIO) and/or McNeese State University legal counsel can provide guidance on applicability.
Roles and Responsibilities
- All Personnel: All McNeese State University personnel are required to comply with established McNeese State University cybersecurity policies and procedures.
- General Users: All general and privileged users will receive initial and annual refresher training concerning the identifying and reporting of incidents or suspicious events in relation to information systems. Each user has a duty to identify and report suspicious events or confirmed incidents to the local engineer or a member of the Incident Response Team (IRT). Each user has a duty to cooperate in any and all investigations and to aid when their expertise is warranted and directed.
- Privileged Users: Those roles include but are not limited to: IT network administrator, IT client support specialist, director of IT administrative computing, and CIO. For the purposes of this plan, they are collectively referred to as engineers. Engineers are considered subject matter experts (SMEs) on IT operations related to the systems under their jurisdiction and scope of work. In response to an event, they provide close and direct investigation and mitigation support.
- Engineers: A privileged user with the ability to build, maintain, backup, and sanitize vital system components (logical and physical). Their role concerning business continuity will be the primary custodian of the system who should be adept at maintaining the system under their care and to conduct necessary backups of the systems hardware, software, firmware, and data in the event of an occurrence.
- Information System Owner: The information system owner (ISO) is ultimately responsible for the request and budget of resources for the department. In the event of an incident, management will monitor and report on the amount of resources being utilized to respond to an incident and provide a cost variance analysis concerning the effort. In addition, the University ISO will provide feedback and solutions to eliminate or mitigate systemic incidents.
- Information Technology Incident Response Team: The Information Technology Incident Response Team (IT IRT) is the response team designed to assist in handling security incidents. Frequently referred to as the Computer Incident Response Team (CIRT) or Computer Emergency Response Team (CERT), the IRT responsibilities include discovery of, and response to, activities which might otherwise interrupt the day-to-day operations of the computer infrastructure.
The IT IRT is established to address incident response activities and formalize reporting of incidents, as well as disseminating incident information to need-to-know stakeholders. The team consists of University engineers, the director IT administrative computing, and the CIO. Regardless of who discovers and initially reports the incident, all team members must be alerted to the incident and efficiently respond to the incident.
Incident Response Role | Personnel |
---|---|
Incident Response Officer: Individual responsible for initial response and coordinating response actions with the Incident Response Team (IRT). | Chad Duhon, IT Network Administrator John Smith, IT Network Administrator Robert Burgett, IT Client Support Specialist Curtis Rogers, IT Client Support Specialist Jessica Hill, IT Client Support Specialist |
Incident Response Team Lead: Individual responsible for providing assistance to IT support, which could include support personnel, outside contractors, or individual users. | Fred Fruge, Director of IT Administrative Computing |
Incident Response Management Team Lead: Management representative responsible for interfacing with other managers/executives in areas such as legal, human resources, or other specialties, as required. | Chad Thibodeaux, CIO |
Procedures
It is the responsibility of all McNeese users to report any event that might compromise information security to their direct manager and/or the Office of Information Technology. Events, incidents, and potential breaches reported to McNeese personnel by vendors must also be reported using this process.
How to Report an Incident
Note: McNeese employees in non-management positions should attempt to report the incident to their manager or supervisor before reporting to any other entity. If the manager or supervisor is unavailable, report the incident as per the instructions below.
- Call the McNeese Help Desk.
- The McNeese Help Desk phone number is (337) 475-5995.
- The McNeese Help Desk email address is helpdesk@mcneese.edu.
- Inform the Help Desk that you are reporting an information security incident.
- The only information that should be provided is your name, contact information, and incident details.
- The Help Desk will contact the Office of Information Technology and alert them of the incident report.
- A member of the Office of Information Technology will contact you to confirm receipt of the incident report and to request any additional details about the incident.
If you need to report an incident outside the Help Desk business hours, call University Police at (337) 475-5711 and inform the dispatcher that you need to report an information security incident and are requesting that they alert the Office of Information Technology.
If you become aware that the incident is more serious or broader than what you originally reported, submit another notification to the person or department that confirmed receipt of your incident report.
Incident Response
Once an incident has been reported to the Office of Information Technology (OIT), OIT serves as the primary point of contact and coordination for the duration of the incident except in situations where OIT determines the specifics of the incident warrant law enforcement involvement. Once a determination has been made that an incident has occurred, investigation of the incident and/or forensic analysis related to the incident must be initiated by and coordinated through OIT. Additional investigation, evidence collection, forensic analyses, and/or incident remediation by individuals outside of OIT is prohibited, unless directed by the OIT Incident Coordinator.
Note: This does not preclude system, application, and database administrators from taking investigatory actions to determine if an anomalous event is actually an incident. However, if these actions indicate that an incident has occurred, regardless of perceived severity, it must be reported to OIT, and all investigatory activity must stop until officially requested by the Incident Coordinator.
Note: In events, incidents, and potential/confirmed breaches involving McNeese data stored, accessed, managed, or otherwise used by a vendor application, OIT may opt to immediately involve procurement services and legal counsel to provide guidance and to determine if there is also a breach of contract that needs to be pursued. Additionally, in incidents involving vendors, McNeese may have limited ability to initiate, monitor, guide, or otherwise influence or control the investigation, mitigation, remediation, and any notification resulting from the incident.
Step 1: Assign Incident Coordinator
The CIO assigns an Incident Coordinator who will be the primary point of contact for the duration of the response and recovery effort. The Incident Coordinator’s name and contact information will be provided to all relevant parties.
Step 2: Assess Incident Risk and Assign Classification
The Incident Coordinator, in conjunction with the OIT and any other appropriate personnel, reviews the known details of the incident and determines the incident’s initial risk classification according to the Information Security Incident Risk Classification Matrix.
Critical | Major | Minor |
---|---|---|
Wide-scale malware infection or tangible threat of infection | Isolated malware infection or tangible threat of infection involving more than 10 user devices | Malware infection of less than 10 devices (as part of a single event) |
Multiple devices infected with ransomware with potential for wide-spread infection via network access | Multiple devices infected with ransomware | Single device infected with ransomware |
Compromise of:
|
Compromise of:
|
|
Compromise, breach, or potential exposure of Restricted data | Compromise, breach, or potential exposure of Sensitive data | |
Intrusion detection system flags an unauthorized user penetration or access | Intrusion detection system flags potential unauthorized user penetration or access | |
Confirmed compromise of high-risk user credentials | Confirmed compromise of VIP or Elevated Concern user credentials | Confirmed compromise user credentials |
Large-scale unauthorized exposure of user credentials | Exposure of user credentials (more than 1 but does not rise to the level of large-scale) Potential (but not confirmed) large-scale exposure of user credentials |
Exposure of a single user’s credentials Notification of user credentials posted publicly |
Unauthorized physical access to the data center | Unauthorized physical access to an IT-managed area where physical controls are in place |
Most minor incidents can be managed and remediated per standard processes. Incidents classified as Critical or Major, continue to Step 3.
Step 3: Assemble the Incident Response Team
Under the guidance of the CIO, the Incident Coordinator will assemble an Incident Response Team (IRT) who will be responsible for mitigation, investigation, and remediation of the incident. The make-up of this team will vary depending on the classification of the incident, the type of incident, and the information systems and data impacted by the incident.
When appropriate, the Incident Coordinator will consult with the CIO, legal counsel, University Police, leadership/administration, individual college administrators, the Office of Marketing and Communications, and other departments or groups to establish an IRT appropriate to respond to the specific incident.
Step 4: Mitigate the Potential for Additional Loss/Damage
The IRT determines if the incident is an active incident with ongoing impact. If the determination is made that the incident is ongoing, strategies to mitigate additional loss, damage, or exposure are identified, discussed, agreed, and implemented. The classification and specific details of the incident will determine the measures appropriate for mitigation, which may include:
- Firewall ports may need to be blocked until the source of an attack is known;
- Systems may need to be shut down or taken off-line until they can be protected without disrupting services;
- Protocols may need to be disabled temporarily;
- Access to all users, storage, applications, subnets, etc. may need to be disabled until the extent of any compromise is understood;
- 24/7 guard may need to be provided for physical access control; and/or
- Network access may need to be blocked or restricted to prevent additional intrusion or the spread of malware.
With sign-off by the CIO, the IRT is empowered to take whatever action is deemed necessary, including the use of extraordinary measures, to mitigate the impact of or prevent further damage from an active information security incident.
In lieu of CIO approval, the IRT has authority to block access to the applications or systems under their purview or to take these applications or systems offline.
Note: Restoration of service/access and remediation activities cannot commence without the explicit approval of the Incident Coordinator on behalf of the IRT or at the direction of the CIO.
Step 5: Investigate the Incident
If the IRT determines the incident is not an active incident, or, once steps have been taken to prevent further loss/damage and/or to mitigate the impact of the incident, the IRT investigates the incident.
During the investigation, the IRT will determine the following, wherever possible:
- How the incident occurred;
- Whether or not the incident resulted in the exposure or potential exposure of restricted data;
- If there are other systems, data, or services that might have been impacted or that may be at risk because of the incident;
- If the incident involved criminal activity; and
- What steps need to be taken to recover from the incident.
At any point in the investigation, the IRT may determine, based on the type and classification of the incident and the specific details of the loss or damage, that it is necessary to involve other departments to participate or assist in the investigation and subsequent remediation of the incident. These additional resources may or may not become part of the overall IRT and fall into two categories:
- Incident Handlers:
- IT resources: to assist in investigation activities related to specific systems, databases, devices, and/or networks.
- Non-IT resources: to assist in investigation activities related to systems, infrastructure, and devices managed and administered outside of IT.
- Subject Matter Experts:
- Office of Marketing and Communications: to provide guidance on and assistance with notifications to the community and other entities, and to handle any contact with the press.
- General Counsel: to provide legal guidance and support.
- HIPAA Compliance Officer: to advise on any incident involving Protected Health Information.
- Procurement: to advise on and assist with incidents involving contracted vendors.
- Data stewards: to advise on and assist with incidents involving restricted or sensitive data loss/exposure.
In the event that the IRT’s investigation uncovers criminal activity, the Incident Coordinator or the CIO will notify University Police or other law enforcement agencies who may take over investigation of the incident. Processes and procedures related to information security incidents that have criminal components will be dictated by the relevant law enforcement agency investigating the incident.
Step 6: Define and Implement Remediation Plan
As the IRT investigates the incident, necessary remediation/mitigation activities will also be identified and must be documented, agreed, and organized into a Remediation Plan. These activities will vary depending on the type and scale of the incident and may include:
- Patching vulnerabilities in the impacted infrastructure components and identifying similar infrastructure components that might share that vulnerability to apply preventive patches;
- Securing the accounts of compromised users;
- Rolling back application code to pre-compromise backups;
- Implementing additional security controls on impacted devices, systems, or networks;
- Improving business processes to reduce the risk of recurrence;
- Revising policies and procedures to reduce the risk of recurrence or the impact from similar future incidents; and/or
- Documenting the acceptance of risk in situations where the vulnerability or circumstance that enabled the incident to occur cannot be mitigated or remediated.
In most cases, the activities outlined in the remediation plan will require assistance from incident handlers who are not part of the core IRT. When participation of these resources is required for remediation, the Incident Coordinator will monitor and coordinate these resources and the activities they need to perform.
Incident Documentation
The type of documentation required depends on the classification of the Incident.
- Incidents classified as Critical require a completed Incident Report, a Remediation Plan (which may or may not be documented separately from the Incident Report), an Incident Debrief write-up, and a tracking ticket in the Office of Information Technology ticketing system (Jira).
- Incidents classified as Major require an Incident Report and a tracking ticket in the Office of Information Technology ticketing system (Jira).
- Incidents classified as Minor are only documented in a tracking ticket the Office of Information Technology ticketing system (Jira).
- Additional documentation may be produced as needed, regardless of classification.
Incident Reports
Each incident with a classification of Major or Critical must be documented in an Incident Report. The Incident Coordinator is accountable for incident report completion but may not be the one completing the report. In some circumstances, there may be a need for multiple incident handlers to create individual Incident Reports. In these circumstances, the Incident Coordinator is responsible for collecting the various Incident Reports, ensuring they are completed correctly, and creating an overall Incident Report to which the individual incident handler reports are attached.
The CIO is responsible for ensuring that incidents are appropriately documented, communicated, and archived.
Wherever possible, incident details should be captured and documented in the report as they occur to ensure the highest degree of accuracy. The following standards should be followed when completing an Incident Report:
- Document the date and time of activities as they happen.
- Each Incident Report must minimally contain:
- A description of the incident;
- Information about the results of the investigation (attacker, cause, etc.);
- Impact on service, financial damage, violation of privacy, etc.;
- Actions taken;
- Notification decisions and completed notifications;
- Remediation plan information (unless the Remediation Plan will be documented separately); and
- The Jira ticket number.
Incident Summary
In addition to the Incident Report, an Incident Summary will be produced for each Major or Critical incident. This summary is intended to provide a high-level overview of the incident, investigation, mitigation, and remediation. The Incident Summary is a public document that can be shared without restriction.
When warranted, an Incident Summary may also be created for Minor incidents.
Incident Remediation Plans
There is no formal standard for documenting the remediation plan for an incident. IRTs should document the remediation plan in a way that facilitates communication and tracking. Remediation plans are required for all Critical incidents but can be included in the overall Incident Report.
Incident Debriefing
For all Critical Incidents, an after-action debriefing involving the IRT, incident handlers, subject matter experts, and other relevant stakeholders will be conducted by the Office of Information Technology. The objective of this debrief is discuss and agree to lessons learned while responding to and remediating the incident and to identify opportunities for improving the overall Incident Response and Recovery process. This may include:
- Identification of process improvement opportunities within the Incident Response and Recovery processes;
- Identification of process improvement opportunities to other business processes to prevent future incidents;
- Identification of the need for policy, standard, or procedure revisions (not limited to policies, standards, and procedures related to Incident Response and Recovery); and/or
- Identification of information security training opportunities (specific to incident response or as a preventative measure).
Incident debriefs should occur as quickly as possible after the incident response and recovery has been completed, especially for critical incidents.
Results of Incident debriefs will be used by the Office of Information Technology to prioritize improvements across the University as a whole.
Incident Communication and Notification Processes
The Incident Coordinator is responsible for communicating information about the Incident to appropriate personnel and for maintaining contact with key stakeholders, for the purpose of update and coordination, for the duration of the Incident.
Incidents classified as critical and major are communicated to the CIO immediately upon IRT confirmation of the Incident’s classification. The CIO will determine if communication/notification to McNeese Executive Leadership is appropriate.
When required, the Office of Marketing and Communications will be engaged to manage any communications/contact with the public, media, external agencies, etc. The Office of Marketing and Communications will also be consulted in the event there is the need for a University-wide communication.
Mandatory notifications of regulated data (FERPA, HIPAA, CJIS, etc.) will be coordinated through the appropriate subject matter expert (HIPAA Compliance Officer, Legal Counsel, etc.).
Incident Response Plan Management
Incident Response Plan Testing
OIT shall conduct an annual table-top test of the Information Security Incident Response Plan and is responsible for addressing any deficiencies in processes and procedures identified because of this testing. Testing scenarios should mimic tangible threat/attack vectors.
The annual test process will involve all participants necessary to respond to and recover from the specific scenario being tested. All required documentation will be produced during the test and a debriefing will be held once the exercise is complete.
The goal of the annual test is two-fold. First, to ensure the processes and procedures are adequate to guide a quick, thorough response to a real incident. Second, to provide training for incident coordinators, incident handlers, subject matter experts, and OIT management on the Incident Response and Recovery processes.
With the written approval of the CIO, this annual test requirement can be waived if warranted based on Incident Response activity during the previous year.
Incident Response Plan Review
As part of the annual Incident Response Plan test process, OIT will conduct a review of the Information Security Incident Response Plan and all related documentation to ensure the plan is up to date. Revisions will also be made between formal reviews when necessary changes are identified because of incident debrief sessions.
OIT is responsible for addressing any deficiencies in the plan and its related processes and procedures identified because of this testing and review process.
Incident Response Plan Approval
Annually, as part of the Incident Response Plan test and review process, the CIO will review and approve any revisions made to the Incident Response Plan. Additionally, if major modifications are made to this plan outside the annual testing and review process (ex. as the result of an incident debrief finding) the revised plan will be submitted to the Executive Leadership Team for review and approval prior to publication.
Communication
This policy is distributed via the University Policies webpage.