Date enacted or revised:
Enacted June 16, 2020
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
- Continuously improve the way the University handles information security events
2. 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
- 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 (ex. account sending spam)
- Unauthorized access to, alteration of, or activity within a University information system (Unexplained or unauthorized code changes, compromised/defaced website, etc.)
- Physical theft/breach (ex. 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 CITO and/or McNeese State University Legal Counsel can provide guidance on applicability.
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 email@example.com
- 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 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.
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 in actuality 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 CITO 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.
|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, 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 CITO, 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 CITO, Legal Counsel, the Police Department, leadership/administration, individual college administrators, Public Relations, and other departments or groups in order 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
- 24x7 guard may need to be provided for physical access control
- Network access may need to be blocked or restricted to prevent additional intrusion or the spread of malware
With sign-off by the CITO, 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 CITO 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 CITO.
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
- 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:
- Public Relations – to provide guidance on and assistance with notifications to the community and other entities, 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 CITO will notify the Police Department 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 in order 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
- Documenting the acceptance of risk in situations where the vulnerability or circumstance that enabled the incident to occur cannot be mitigated or remediated
4. 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.
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 CITO 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).
- The Jira ticket number
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. IRT’s 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.
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)
- 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 CITO immediately upon IRT confirmation of the Incident’s classification. The CITO will determine if communication/notification to McNeese Executive Leadership is appropriate.
When required, Public Relations will be engaged to manage any communications/contact with the public, media, external agencies, etc. Public Relations 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.)
5. 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 as a result 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 CITO, 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 as a result of incident debrief sessions.
OIT is responsible for addressing any deficiencies in the plan and its related processes and procedures identified as a result of this testing and review process.
Incident Response Plan Approval
Annually, as part of the Incident Response Plan test and review process, the CITO 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 President’s Executive Staff for review and approval prior to publication.
This policy is communicated through the University Policy Page and Senior Staff.