Incident Response Plan

INTRODUCTION  

Purpose 

The Southwestern Oklahoma State University (SWOSU) Incident Response (IR) was developed to provide direction and focus to the handling of an information security incident that would adversely affect SWOSU’s information infrastructure and resources. The IR applies to any person or entity charged by the university Incident Response Manager in response to any information security related incidents that have occurred, including but not limited to events that affect the organization’s information resources. 

The focus of this document is to allow the quick and appropriate response to any information security incident experienced by SWOSU. The document herein applies to all locations owned and/or leased by SWOSU. 

Due to the sensitive nature of the information contained herein, this document should only be distributed to authorized personnel. This includes but is not limited to designated members of the incident management teams, or those who play a direct role in the incident response or recovery process. 

Unless instructed otherwise, each designated person should maintain two copies of this plan that will be stored as follow: 

• One copy at the recipient’s office 

• One copy at the recipient’s home 

Additional copies of this plan may be requested by contacting the SWOSU IT Helpdesk either at 580-774-7070 or helpdesk@swosu.edu. 

SWOSU affirms the importance of people, processes, and technology to the university. It is the responsibility of every SWOSU employee to safeguard and keep university assets confidential and safe as appropriate. 

Scope 

The IR includes initial actions and procedures to aid in the response to an event or action that could have a negative impact affecting critical business activities and functions. The IR covers facilities that are owned and/or leased by SWOSU. The IR is designed to help minimize operational and financial impacts associated with a disaster or incident. 

SWOSU’s IR was created to provide an initial response to any unplanned security event.  An unplanned security event means an event resulting in unauthorized access to, or disruption or misuse of, an information system, information stored on such information system, or customer information held in physical form. This document defines the requirements, strategies, and actions needed to respond to such an event. 

The policies and procedures defined herein apply to all equipment and facilities owned and/or leased by SWOSU. These policies and procedures extend to all persons or devices who access or are granted access to the systems and services owned or leased by SWOSU. 

The document herein only covers events and incidents related to the information infrastructure of SWOSU. Should damage occur due to natural disasters, fire, or flood, please consult the SWOSU (SWOSU) Disaster Recovery (DR) Plan. 

Exclusions 

The IR specifically excludes the following from its scope: 

• Facilities that are not leased or owned by SWOSU. 

Maintenance 

The Qualified Individual (QI) assigned by SWOSU will be responsible for overseeing the maintenance and revision of the Incident Response (IR) plan. The IR will be reviewed no less than once a year. 

DEFINITIONS 

Event 

An “event” is any observable occurrence in a system, network, environment, process, workflow, or personnel. Events may or may not be negative in nature. 

Adverse Event 

An “adverse event” is an event with negative consequences. This plan only applies to adverse events that are computer security related, not those caused by natural disasters, power failures, etc. 

Incident 

An incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices that jeopardizes the confidentiality, integrity, or availability of information resources or operations. A security incident may have one or more of the following characteristics: 

1. Violation of an explicit or implied university security policy 

2. Attempts to gain unauthorized access to a university information resource 

3. Denial of service to a university information resource 

4. Unauthorized use of a university information resource 

5. Unauthorized modification of university information 

6. Loss or accidental disclosure of university confidential or protected information 

CONTACT INFORMATION 

First Name	Last Name	Title	Contact Type	Contact Information
Cindi	Albrightson	Title IX & Compliance Coordinator	Work	580-774-3165
			Mobile	580-302-3418
			Email	cindi.albrightson@swosu.edu
			Alt. Email
Kendra	Brown	Director Campus Police	Work	580-774-3785
			Mobile	803-470-1220
			Email	kendra.brown@swosu.edu
			Alt. Email
Lori	Boyd	Vice President	Work	580-774-3731
		for Administration & Finance	Mobile	405-820-4969
			Email	Lori.boyd@swosu.edu
			Alt. Email
Jonathan	Clemmons	Assistant. Vice President	Work	580-774-3063
		for Public Relations	Mobile	504-444-8827
			Email	jonathan.clemmons@swosu.edu
			Alt. Email
Adam	Johnson	Vice President Student Services	Work	580-774-3177
			Mobile	405-496-9068
			Email	adam.johnson@swosu.edu
			Alt. Email
Patsy	Parker	Provost Academic Affairs	Work	580-774-3264
			Mobile	405-620-7641
			Email	patsy.parker@swosu.edu
			Alt. Email
Chad	Kinder	Assistant Vice President	Work	580-774-3291
		for Strategic Partnerships	Mobile	580-819-3693
			Email	chad.kinder@swosu.edu
			Alt. Email
Garrett	King	Executive Director of	Work	580-774-3706
		Institutional Advancement	Mobile	405-929-0281
			Email	garrett.king@swosu.edu
			Alt. Email
Diana	Lovell	President	Work	580-774-7193
			Mobile	713-553-4234
			Email	diana.lovell@swosu.edu
			Alt. Email
Jesse	Kwak	Webmaster	Work	580-774-3179
			Mobile	678-633-9133
			Email	Jesse.kawk@swosu.edu
			Alt. Email
Dayna	Hardaway	Assistant Vice President	Work	580-774-3248
		for Human Resources	Mobile	940-642-9848
			Email	dayna.hardaway@swosu.edu
			Alt. Email
Dian	Ray	Director Information	Work	580-774-3271
		Technology Services	Mobile	918-851-8100
			Email	dian.ray@swosu.edu
			Alt. Email
Willis	Jones	Director Physical Plant	Work	580-774-3101
			Mobile	580-774-0210
			Email	Willis.jones@swosu.edu
			Alt. Email
Tim	Wills	Incident Response Manager	Work	580-774-3745
		IT Operations Administrator	Mobile	580-819-0008
			Email	Timothy.wills@swosu.edu
			Alt. Email

 

Roles and Responsibilities 

Cyber Security Incident Handling Team (IHT) 

• Consists of legal experts, risk managers, and other department managers that may be consulted or notified during incident response 

• Advise on incident response activities relevant to their area of expertise 

• Maintains a general understanding of the plan and policies of the organization 

• Ensure incident response activities are in accordance with legal, contractual, and regulatory requirements 

• Participate in tests of the IR and procedures 

Responsible for internal and external communications pertaining to cyber security incidents. 

Table 1: SWOSU IHT Team Members 

No.	IHT Member	Role
	RUSO Legal Counsel	Legal Counsel
	CSIRT Team – (see page 5 & 6)	IT Member
	Lori Boyd	Executive Council Committee
	Boone Clemmons	Executive Council Committee
	Garrett King	Executive Council Committee

Director of Information Technology Services 

• Seek approval from the Executive Council Committee (ECC) for the administration of the Incident Response. 

• Coordinate response activities with auxiliary departments and external resources as needed to minimize damage to information resources. 

• Provide updates on response activities to the Incident Handling Team (IHT) and other stakeholders during an incident. 

• Ensure Service Level Agreements (SLA) with service providers clearly define expectations of the organization and the service provider in relation to Incident Response. 

• Ensure policies related to incident management accurately represent the goals of the organization. 

• Review the IR to ensure that it meets policy objectives and accurately reflects the goals of the organization. Seek Plan approval from IHT. 

• Periodically evaluate the effectiveness of the Incident Response and Cyber Security Incident Response Team (CSIRT). 

• Ensure CSIRT managers are given the necessary authority to seize assets and stop services quickly to contain a moderate or critical-severity incident. 

• Approve the closing of moderate or critical-severity incidents. 

• Ensure cyber insurance is maintained as necessary, and appropriate stakeholders are informed. 

• Ensure lessons learned are applied/weighed based on risk for Severity 1 incidents. 

Cyber Security Incident Response Team (CSIRT) 

The CSIRT is comprised of IT management and experienced personnel. The role of the CSIRT is to promptly handle an incident so that containment, investigation, and recovery can occur quickly. Where third-party services are leveraged, ensure they are engaged as necessary. 

Roles within the CSIRT include: 

Incident Response Manager 

The Incident Response Manager oversees and prioritizes actions during the detection, analysis, and containment of an incident. They are also responsible for conveying the special requirements of high severity incidents to the rest of the organization as well as communicating potential impact to the Director of Information Technology Services. Additionally, they are responsible for understanding the SLAs in place with third parties, and the role third parties may play in specific response scenarios. 

Further responsibilities: 

• Act as a liaison for all communications to and from the Director of Information Technology Services 

• Assemble a Cyber Security Incident Response Team (CSIRT) 

• Ensure personnel tasked with incident response responsibilities are trained and knowledgeable on how to respond to incidents 

• Update plan and procedures as needed based on results from testing, incident response lessons learned, industry developments, and best practices 

• Review the plan and procedures annually 

• Monitor business applications and services for signs of attack 

• Collect pertinent information regarding incidents at the request of the Incident Response Manager 

• Consult with qualified information security staff for advice when needed 

• Ensure evidence gathering, chain of custody, and preservation is appropriate 

• Participate in tests of the IR and procedures 

• Be knowledgeable of service level agreements with service providers in relation to incident response 

Qualified Individual (QI) 

The Qualified Individual will oversee, implement, and enforce the university’s information security program. This includes the IR. 

Recorder 

The Incident Response Manager may assign a team member to begin formal documentation of any incident. 

Table 2: SWOSU CSIRT Team Members 

CSIRT Member	Role
Tim Wills	Incident Response Manager; Recorder
Jonathan Kimmitt/Alias Cybersecurity	Qualified Individual; SWOSU virtual CISO
Dian Ray	IT Director
Justin Tate	Assistant IT Director
Alex Kluckner	Network Administrator

INCIDENT RESPONSE FRAMEWORK 

SWOSU recognizes that, despite reasonable and competent efforts to protect information resources, a breach or other loss of information is possible. The organization must make reasonable efforts and act competently to respond to a potential incident in a way that reduces the loss of information and potential harm to customers, partners, and the organization itself. 

Developing a well-defined incident response framework is critical to an effective IR. SWOSU’s incident response framework is comprised of six phases that ensure a consistent and systematic approach. 

Figure 1: Incident Response Framework Diagram 

 

Phase I – Preparation Details 

The preparation phase is easily the most important and often overlooked phase in the incident response framework. Without proper preparation incident response activities may be disorganized, expensive, and could cause irreparable harm to Southwestern Oklahoma State University. During this phase it is important to establish a Cyber Security Incident Response Team (CSIRT), define appropriate lines of communication, articulate services necessary to support response activities, and procure the necessary tools. 

Tasks included in the Preparation Phase include but are not limited to the following: 

• Establish an IHT and CSIRT. 

• Ensure appropriate parties are aware of incident reporting process. (See Reporting Incidents) 

• Document and share cyber insurance details with appropriate parties. (See Appendix IX) 

• Validate Logging, Alerting, and Monitoring policy compliance. 

• Ensure CSIRT receives appropriate training based on skill gap analysis, career development efforts, and skill retention needs. 

• Ensure CSIRT has access to the tools and equipment needed based on estimated ROI and the organization’s risk appetite. 

• Define and document standard operating procedures and workflows for both IHT and CSIRT. 

• Improve documentation, checklists, references, etc. 

• Maintain and validate Network Diagrams and Asset Inventories. 

• Review Penetration Test reports and validate remediations to findings. 

• Review Vulnerability Management reports and validate remediation efforts. 

• Establish disposable and disabled Administrative credentials to be enabled and used for investigations. 

Finally, it should be noted that Phase I is a continuous, or at least, cyclical as incidents are brought to conclusion. 

Reporting Incidents 

Effective ways for both internal and outside parties to report incidents are equally critical as sometimes users of SWOSU’s systems and information may be the first to observe a problem. Review the different types of incidents addressed in Phase II under Incident Categorization and list or establish reporting methods for a variety of incident types. 

Incident Reporting Guide
Incident Type	Reporting Method	Available To	Anonymous	Response Time
Website defacement, data modification, or exposure	Website support contact	Customers	Yes	1 business day
Many	IT Help Desk	Employees	No	Immediately during office hours. Otherwise, within 1 hour of opening.
Physical access	Director of ITS	Employees	No	Immediate
Many	Director of ITS	Employees	No	Immediate

 

Phase II - Identification and Assessment Identification 

Identifying an event and conducting an assessment should be performed to confirm the existence of an incident. The assessment should include determining the scope, impact, and extent of the damage caused by the incident. In the event of possible legal action, digital evidence will be preserved, and forensic analysis may be conducted consistent with legislative and legal requirements. 

When an employee of SWOSU or external party notices a suspicious anomaly in data, a system, the network, or a system alert generates an event; Security Operation, Help Desk, or CSIRT must perform an initial investigation and verification of the event. 

Events Versus Incidents 

As defined above, Events are observed changes in normal behavior of the system, environment, process, workflow, or personnel. Incidents are events that indicate a possible compromise of security or non-compliance with SWOSU’s policy that negatively impact (or may negatively impact) the organization. 

To facilitate the task of identification of an incident, the following is a list of typical symptoms of security incidents, which may include any or all the following: 

1. Email or phone notification from an intrusion detection tool 

2. Suspicious entries in system or network accounting, or logs 

3. Discrepancies between logs 

4. Repetitive unsuccessful logon attempts within a short time interval 

5. Unexplained new user accounts 

6. Unexplained new files or unfamiliar file names 

7. Unexplained modification to file lengths and/or dates, especially in system files 

8. Unexplained attempts to write to system files or changes in system files 

9. Unexplained modification or deletion of data 

10. Denial/disruption of service or inability of one or more users to login to an account 

11. System crasher 

12. Poor system performance of dedicated servers 

13. Operation of a program or sniffer device used to capture network traffic 

14. Unusual time of usage (e.g. users’ login during unusual times) 

15. Unusual system activity such as resource consumption. (High CPU usage) 

16. The last logon (or usage) for a user account does not correspond to the actual last time a user used the account. 

17. Unusual usage patterns (e.g. a user account associated with a user in Finance is being used to login to an HR database) 

18. Unauthorized changes to user permission or access 

Although there is no single symptom to conclusively prove that a security incident has taken place, observing one or more of these symptoms should prompt an observer to investigate more closely. Do not spend too much time with the initial identification of an incident as this will be further qualified in the containment phase. 

NOTE: Compromised systems should be disconnected from the network rather than powered off. Powering off a compromised system could lead to loss of data, information, or evidence required for a forensic investigation later. ONLY power off the system if it cannot be disconnected from the wired and wireless networks completely. 

Assessment 

Once a potential incident has been identified, part or all of the CSIRT will be activated by the Incident Response Manager to investigate the situation. The assessment will determine the category, scope, and potential impact of the incident. The CSIRT should work quickly to analyze and validate each incident, following the process outlined below, and documenting each step taken. 

The 2 Minute Incident Assessment, found in Appendix II, should be leveraged to rapidly determine if further investigation is necessary. Further, it can be modified and used to report the incident to appropriate leadership as required. 

The Incident Response Manager will assign a team member to be “Recorder” to begin formal documentation of the incident. 

Phase III – Containment and Intelligence 

The objective of the containment phase of the incident response is to regain control of the situation and limit the extent of the damage. Steps must be taken to ensure that the scope of the incident does not spread to include other systems and information resources. To achieve this objective, SWOSU has defined a few containment strategies relevant to a variety of incident types. Root cause analysis is required prior to moving beyond the Containment & Intelligence phase and may require expertise from outside parties. Reference to the procedures related to one or more of the Containment Strategies are listed below. 

Containment Strategies 

Use the list of strategies below to choose the procedure(s) most appropriate to the situation. When procedures for each of these strategies match the current situation, refer to the Common Containment Steps listed below. 

• Stolen credentials – disable account credentials, reset all active connections, review user activity, reverse changes, increase alerting, harden from future attacks 

• Ransomware – isolate the impacted system, validate the ransomware claim, contact insurance carrier, identify whether additional systems have been impacted and isolate as needed 

• If DOS/DDOS – control WAN/ISP 

• Virus outbreak – contain LAN/System 

• Data loss – review user activity, implement data breach response procedures 

• Website defacement – repair site, harden from future attacks 

• Compromised API – review changes made, repair API, harden from future attacks 

Common Containment Steps 

Containment requires critical decision making related to the nature of the incident. The Incident Response Manager, in coordination with other members of SWOSU administration, should review all the containment steps listed below to formulate a strategy to contain and limit damages resulting from the incident. 

Attempts to contain the threat must consider efforts to minimize the impact of business operations. Third party resources or interested parties may need to be notified. Where law enforcement may become involved, efforts must be made to preserve the integrity of relevant forensic or log data and maintain a clear chain of custody. Where evidence cannot be properly maintained due to containment efforts, the introduced discrepancy must be documented. 

When evaluating containment steps, consider the following: 

• Enable disposable Administrator accounts for use during the investigation and reset associated passwords if believed to have been at risk or compromised while being used. (See Phase I – Preparation Details) 

• Will the ability to provide critical services be impacted? How? For how long? 

• When should the company cyber insurance provider be notified? (See Appendix IX – Cyber Insurance & Third-Party Service Agreements) 

• Is a legal investigation or other action likely to be required? Does evidence of the event need to be preserved? (See Preserve Evidence) 

• How likely is the containment step to succeed? What is the result, full containment or partial? 

• What resources are required to support the containment activity? 

• What is the potential damage to equipment and other resources? 

• What is the expected duration of the solution? (temporary, short-term, long-term, or permanent) 

• Should Incident Response team members act discreetly to attempt to hide their activities from the attacker? 

• Will third party assistance be required? What is the expected response time? 

• Do interested parties (students, faculty, staff) need to be notified? If so, when? (see Appendix IV) 

• Does the impact on SWOSU’s equipment, network, or facilities necessitate the activation of the Disaster Recovery Plan? 

• Does the data impacted include protected data such as cardholder data? If yes, refer to the Notification Requirements. 

Engage Resources 

The CSIRT should select the option based on the severity of the incident, the damage incurred by SWOSU, and legal considerations. 

	In-House Investigation	Law Enforcement	Private Forensic Specialist
Time Response	Quick response	Varies by area and agency	Quick response
Competency	Skills vary	Depends on local law enforcement	Highly skilled, often with law enforcement background
Preservation of Evidence	Does not ensure evidence integrity	Preserve evidence integrity and present evidence in court	Preserve evidence integrity and present evidence in court
Reputation Impact	Minimal effect	Potential loss of reputation if certain incidents reach public	Potential loss of reputation if certain incidents reach public

Preserve Evidence 

NOTE: If there is strong reason to believe that a criminal or civil proceeding is likely, SWOSU will maintain a chain of custody logs for any evidence that has been taken into custody, or custody is transferred for the purpose of investigation. For incidents involving card holder data, Visa has defined specific requirements to be followed to preserve evidence and facilitate the investigation. Refer to Notification Requirements for more information. 

Consult legal counsel regarding applicable laws and regulations related to the collection and preservation of evidence. Create a detailed log for all evidence collected, including: 

• Identification information (e.g. serial number, model, hostname, MAC address, IP address, or another identifier) 

• Name and contact information for all individuals who have handled the evidence during the investigation 

• Date and time of each transfer or handling of the evidence 

• List of all locations where the evidence was stored 

• Deviation from standard operating procedures and associated justifications 

Follow guidance from NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response, when preserving evidence. 

Reduce Impact 

Depending on the type of incident, the team must act quickly to reduce the impact on affected systems and/or reduce the reach of the attacker. Actions may include, but are not limited to the following: 

• Stop the attacker using access controls (disabling accounts, resetting active connections, changing passwords, implementing router ACLs, or firewall rules, etc.) 

• Isolate compromised systems from the network 

• Avoid changing volatile state data or system state data early on 

• Identify critical external systems that must remain operational (e.g., email, client application, DNS) and deny all other activity 

• Maintain a low profile, if possible, to avoid alerting an attacker that you are aware of their presence or giving them an opportunity to learn the CSIRT’s tactics, techniques, or procedures 

• To the extent possible, consider preservation of system state for further investigation or use as evidence 

Collect Data and Increase Activity Logging 

Increase monitoring packet capture on affected systems while the CSIRT investigates the scope and impact of the incident. Continue increased logging and monitoring as you move onto the Eradication and Recovery phases. 

• Enable full packet capture 

• Collect and review system, network, and other relevant logs 

• Create a memory image of impacted systems 

• Take a forensic image of affected systems 

• Monitor possible attacker communication channels 

Conduct Research 

Performing an internet search, consulting third party resources, and/or consulting an IT insurance carrier using the apparent symptoms and other information related to the incident you are experiencing may lead to more information on the attack. For example, if your insurance carrier has received multiple reports of similar incidents, or if mailing list message contains the same IP or text of the message you received. 

Notify Interested Parties 

Once an incident has been identified, determine if there are others who need to be notified, both internal (e.g., human resources, legal, finance, communications, business owners, etc.) and external (e.g., service providers, government, public affairs, media relations, customers, public, etc.). Always follow the “need to know” principle in all communications. Most importantly, remain factual and avoid speculation. See Notify Interested Parties for more detail. 

Depending on the degree of sensitivity of the incident, it may be necessary for Legal/Management to require employees to sign NDAs or issue gag orders to employees who need to be involved. 

Key Decisions for Exiting Containment Phase 

• The attacker’s ability to affect the network has been effectively mitigated/stopped 

• The affected system(s) are identified 

• Compromised systems volatile data collected, memory image collected, and disks are imaged for analysis 

Investigation 

As the CSIRT works to contain, eradicate, and recover from the incident, the investigation will be ongoing. As the investigation proceeds, you may find the incident is not fully contained, eradicated, or recovered. If that is the situation, it may be necessary to revisit earlier phases (see Figure 1: Incident Response Framework Diagram). The Containment, Eradication, and Recovery phases are frequently cyclical. 

The investigation attempts to fully identify all systems, services, and data impacted by the incident, including root cause analysis, which helps to determine the entry point of an attacker or weakness in the system that allowed the event to escalate into an incident. 

A third party may need to be contracted if investigation is beyond the skills of the CSIRT; impacted systems are owned by a Cloud Service Provider, or forensic analysis is required. 

Initial Cause (“Root Cause”) Investigation 

Investigation should be conducted with consideration given to the ongoing impact of critical business operations. Ideally, the Initial Cause Investigation should be concluded before leaving the Eradication Phase. At times, however, it may be necessary or appropriate to continue investigation during or after eradication and recovery. Delaying the investigation should only be considered when the CSIRT is confident that the incident has been fully contained, and full scope of the impact is known. Delays or modifications to the scope of investigation activities must be approved. 

The investigation techniques utilized will vary by the type of incident. The investigation may rely on some (or all) of the following: 

• Interviews with witnesses and/or affected persons 

• Capturing images, snapshots, or memory dumps of affected systems 

• Obtaining relevant documents 

• Conducting observations 

• Taking photographs of physical locations 

• Reviewing security camera footage 

• Analyzing the logs of the various devices, technologies and hosts involved (e.g. firewall, router, anti-virus, intrusion detection, host) 

• Reviewing email rules (compromised email account) 

• Compare the compromised system to a known good copy 

• Anomaly detection/behavior monitoring (compare to preestablished baseline) 

Phase IV – Eradication Details 

The Eradication consists of full elimination of all components of the incident. Eradication requires removal or addressing all components and symptoms of the incident. Further, validation must be performed to ensure the incident does not reoccur. 

Eradication 

NOTE: The specific administrative tools on a compromised host could be altered versions of the originals. Use a separate set of administrative tools (e.g. boot disk) than those on a compromised host for investigation whenever possible. 

Steps to eradicate components of the incident may include: 

• Disable breached user accounts 

• Reset any active sessions for breached accounts 

• Identify and mitigate vulnerabilities leveraged by the attacker 

• Close unnecessary open ports 

• Increase authentication security measures (implement MFA, and geolocation restrictions) 

• Increase security logging, alerting, and monitoring 

• Clean installation of affected operating systems and application 

All re-installed operating systems and applications must be installed according to SWOSU’s system build standards, including but not limited to: 

• Applying all the latest security patches 

• Disabling all unnecessary services 

• Installing anti-virus software 

• Applying SWOSU’s hardened system configuration baselines 

• Changing all account passwords (including domain, user and service accounts) 

NOTE: It may be possible to restore the system without the need to perform a full clean installation. IT personnel, in the direction of CSIRT, will make this decision. 

Key Decisions for Exiting Eradication Phase 

• Has the root cause been identified and identified vulnerabilities been remediated? 

• Have all impacted accounts, including CSIRT burner credentials been reset? 

• CSIRT is confident that the network and systems are configured to eliminate repeat occurrences. 

• There is no evidence of repeat events or incidents. 

• Sign-off from Incident Response Manger for limited-severity incidents or Director of Information Technology Services for moderate and critical-severity incidents. 

Phase V – Recovery Details 

Recovery involves the steps required to restore data and systems to a healthy working state allowing business operations to be returned. 

Prior to restoring systems to normal operation, it is critical that the CSIRT validate the system(s) to determine that eradication was successful, and the network is secure. Once the organization has been attacked successfully, the same attackers will often attack again using the same tools and techniques leveraged in the initial attack. Having gained access to the compromised system(s) or network once, the attacker has more information at their disposal to leverage in future attacks. 

If feasible, the system should be installed in a test environment to determine functionality prior to re-introduction into a production environment. 

Furthermore, network monitoring should be implemented for as long as necessary to detect any unauthorized access attempts. 

Recovery steps may include: 

• Restoring systems from a clean backup 

• Replacing corrupted data from a clean backup 

• Restoring network connections and access rules 

• Communicating with interested parties about changes related to increased security 

• Increasing network and system monitoring activities (short or long-term) 

• Increasing internal communication/reporting related to monitoring 

• Engaging a third party for support in detecting or preventing future attacks 

Key Decisions for Exiting Recovery Phase 

• Have business operations been restored? 

Phase VI- Lessons Learned 

The Lessons Learned phase includes post-incident analysis on the system(s) that were impacted by the incident and other potentially vulnerable systems. Lessons Learned from the incident are communicated to executive management and action plans developed to improve future incident management practices and reduce risk exposure. 

The follow-up phase includes reporting and post-incident analysis on the system(s) that were the target of the incident and other potentially vulnerable systems. The objective of this phase is to continue improvement to applicable security operations, response capabilities, and procedures. 

Documentation 

All details related to the incident response process must be formally documented and filed for easy reference. The following items must be maintained, whenever possible: 

• All system events (audit records, logs) 

• Actions taken (including the date and time that an action is preformed) 

• External conversations 

• Investigator notes compiled 

• Any deviations from SOP and justifications 

An incident report, documenting the following will be written by the CSIRT at the end of the response exercise: 

• A description of the exact sequence of events 

• The method of discovery 

• Preventative measures put in place 

• Assessment to determine whether recovery was sufficient and what other recommendations should be considered 

The objective of the report is to identify potential areas of improvement in the incident handling and reporting procedures. Hence, the review of the report by management should be documented, together with the lessons learned, to improve the identified areas and used as a reference for future incidents. 

Lessons Learned and Remediation 

The CSIRT will meet with relevant parties (technical staff, management, vendors, security team, etc.) to discuss and incorporate lessons learned from the incident to mitigate the risk of future incidents. Based on understanding the root cause, steps will be taken to strengthen and improve SWOSU’s information systems, policies, procedures, safeguards, and/or training as necessary. Where mitigations or proposed changes are rejected, a Risk Acceptance Process must be followed. Incidents should be analyzed to look for trends, and corrective action should be considered where appropriate. 

Lessons Learned discussion should cover: 

• Review of discovery and handling of incident(s) 

• How well staff and management performed and whether documented procedures were followed 

• Review of actions that slowed or hindered recovery efforts 

• Proposed improvements to future response and communication efforts 

• Recommendations to increase the speed of future detection and response efforts 

• Recommendations for long and short-term remediation efforts 

At the end of Lessons Learned meetings, some sort of remediation needs to occur, either resolving the issues, installing compensating controls, or at minimum, formally assessing and accepting the risk. Recommendations for long and short-term remediation efforts must be added into the overall treatment plan. 

Updates to the incident response procedures should also be considered and incorporated where areas of improvement are found. 

Voluntary information sharing should occur whenever possible with external stakeholders to achieve broader cybersecurity situational awareness (InfraGard, ISAC, etc.). Legal and management must be consulted before doing so if a formal Information Sharing policy and process do not exist. 

Forensic Analysis & Data Retention 

In the event of possible legal action, forensic analysis will ensure in such a manner as to preserve digital evidence consistent with legislative and legal requirements. Outside legal counsel and forensic experts may be required. 

Consider the following when deciding whether and for how long to retain evidence related to the incident: 

• Prosecution – Is it likely that the attacker will be prosecuted? If so, evidence may need to be retained for multiple years. 

• Recurrence – Consider whether the evidence collected may be useful in case the attacker or a similar attack should occur in the future. 

• Data Retention Policies – Consider the contents of evidence held (such as a system image capture) and retain policies related to the data (e.g. email retention policy). 

• General Records Schedule (GRS) 24 specifies that incident handling records should be kept for three years. 

• Cost – Depending on the type and amount of data or equipment preserved as evidence, cost may be a limited factor. 

Key Decisions for Exiting Lessons Learned Phase 

• Leadership is satisfied that the incident is closed. 

• Incident Response Manager makes the decision for limited-severity incidents. Director of Information Technology Services makes the decision for moderate and critical-severity incidents. 

• There is an action plan to respond to operational issues which arose from the incident. At this point, it is time to return to the Preparation Phase (See Figure 1: Incident Response Framework Diagram). 

NOTIFICATION & COMMUNICATION 

Required notification and communication both internally and with third parties (customers, vendors, law enforcement, etc.) based on legal, regulatory, and contractual requirements must take place in a timely manner. 

• The Incident Response Manager must report the incident to senior leadership 

• The senior leadership must report any potential breaches and/or incidents involving customer data to the Incident IHT promptly 

• The IHT is responsible for appropriate notification to: 

• Personnel 

• Affected customers and/or partners (within 48 hours, based on SLA, based on legal or regulatory compliance, whichever is shorter) 

• Local, state, or federal law officials as required by applicable statutes and/or regulations 

Depending on the type and scope of breach, consider using the Security Incident Response Form to inform impacted business entities. 

Interaction with Law Enforcement 

Interaction between law enforcement and emergency services personnel should be coordinated by the Incident Response Manager. Ongoing communication with authorities will be managed by the Incident Response Manager. It must be noted that Law Enforcement’s priorities are eventual prosecution of offenders and not necessarily the returning of the University to a functional state. Ensure legal is consulted and provides direction before and while communicating with law enforcement. 

Regulatory Authorities 

• SWOSU is subject to various regulatory oversight, depending on the data impacted. If there is a potential that regulated data were breached, it may be necessary to notify the Secretary of the U.S. Department of Health & Human Services or Payment Card Industry Security Standards Council (PCI SSC). (See Appendix IV) Depending upon the nature of the breach, it may be required to contact other governmental regulators. 

• Only the IHT and cabinet members are permitted to discuss the nature and/or details of an incident with any regulatory agencies. 

• IHT should contact regulators as soon as practical. (See Appendix IV) 

Customers 

• All customers who are affected by the incident must be notified according to applicable contact language, service level agreements (SLAs), applicable statutes, and/or regulations. 

• Communications with customers must be consistent with the same or similar message delivered to all. The message sent to customers will be created by members of the Public Relations and Marketing team. 

• Customer service and/or customer account managers will communicate with customers according to the message developed by the Public Relations and Marketing team. 

Public Media Handling 

Information concerning an incident is to be considered confidential, and at no time should any information be discussed with anyone outside of SWOSU without approval of the ECC and/or legal counsel. 

Public or media statements must be carefully managed to ensure that any investigation/legal proceedings are not jeopardized, and reputational damage is minimized. Decisions concerning the disclosure and method of disclosure of any information concerning an incident at SWOSU will only be made by a designated spokesperson assigned by the IHT.  The spokesperson will be from the Public Relations and Marketing team or a representative prepared and briefed by the Public Relations and Marketing team. 

Inquiries from media agencies must be directed to the designated IHT representative. Employees found to be discussing incidents without approval from executive management/legal counsel will be subject to disciplinary action, up to and including termination. 

Refer to Appendix V for guidance in communicating with the Media. 

PLAN TESTING & REVIEW 

The SWOSU IR and procedures must be tested at least annually. The Incident Response Manager will conduct training using a scheduled simulated incident to guide the test procedures. (Refer to NIST SP 800-61r2, Appendix A—Incident Handling Scenarios for test scenarios) The plan and procedures will be updated to reflect lessons learned and to incorporate any new industry developments. 

IHT members must participate in test exercises at least annually. 

The IR and procedures are reviewed annually, and updates are tracked in the revision history. 

Plan Review should include: 

• Review supporting documents and forms listed in Supporting Document List (Appendix X) to ensure they are accurate and effective 

• Review Appendices to ensure they are accurate and effective 

• Review completed Incident Reporting Forms and corrective action plans for recommended plan and procedure updates 

• Compare recent changes to the organization’s infrastructure and management structure to documented plan and procedures 

REVISION HISTORY 

Date of Change	Version	Responsible	Summary of Change	Date Approved	Approved By
October 27, 2022	1	ITS	Created as Policy	October 27, 2022	ECC

 

APPENDICES 

Index of Appendices 

1. Logging, Alerting, and Monitoring Activities List 

2. Two Minute Incident Assessment Reference 

3. Incident Response Checklist 

4. Notification Requirements 

5. Media Statements 

6. Customer Letter Template 

7. Incident Response Organizations 

8. Containment Strategies 

9. Cyber Insurance and Third-Party Service Agreements 

10. Supporting Document List 

APPENDIX I – LOGGING, ALERTING, & MONITORING ACTIVITIES LIST 

Logging, alerting, and monitoring activities may target individual systems or a range of activities across multiple systems and applications. Keep a list of logging, alerting, and monitoring activities and review the list regularly to ensure that technicians can respond to abnormal events quickly. If you have a managed asset inventory, those activities may be added to the existing list. 

Prepared by:	Date Updated:
System/Application Name	Monitoring frequency	Alerting
O365	When alerted
ERP	When alerted
Quicklaunch	When alerted
Databank (Webserver)	When alerted

APPENDIX II – TWO MINUTE INCIDENT ASSESSMENT REFERENCE 

Step 1: Understand Impact/Potential Impact (and Likelihood if not an Active Incident) 

• What is the value of the asset? If not significant, why react? 

• Roughly quantify the potential worst-case impact. 

• Include a rough estimate of the likelihood of experiencing this impact. 

Step 2: Identify Suspected/Potential Cause(s) of the Issue 

• All possible scenarios should be considered. 

• Quickly eliminate those that can be proven incorrect. 

• Share most likely scenarios when communicating. 

Step 3: Describe Recommended Remediation Activities 

• How do you close the hole/stop the bleeding? 

• Include any steps that could reduce the impact. 

• Don’t forget about reputation damage and legal expectations. 

Step 4: Communicate to Management 

• Describe the issue at a high level. (what and how it happened) 

• Explain what it means to the business. (financial, reputation, etc.) 

• Share short-term actions needed to move the risk from critical/high to something more acceptable. 

 

Value of the Asset  (H/M/L)	Example of high might be access to the full client database vs. low might be a proprietary internal process document with limited IP.
Potential Impact	What would the loss or felt impact be if the incident were real and fully realized? Try to quantify into both $ and impact like reputation or legal liability.
Likelihood of Impact	Immediate risk (internet accessible cataloged trivial vulnerability to exploit) or not likely known complex (requires sophisticated expertise and specific circumstances to exploit)
Suspected causes (list all potential causes that should be investigated)	Configuration error, remote vulnerability exploited, lost device, targeted denial of service by political or financially motivated party (DDoS to cover up a fraud), etc.
Most likely cause(s)	The sources should be quickly pursued to prove correct or incorrect.
Recommended Remediation Short-term	Turn off the internet, remove server from external access, implement a patch or configuration change, communicate issues to employees or students, etc.
Long-term Actions	Change in process or architecture, acquisition of tools, or systems to reduce the risk to an acceptable level over the long-term.
Communication	Statements need to be communicated calmly, honestly, succinctly, and factually.
Describe Issue in Simple Terms	Describe the problem within a business context if possible. Examples are useful to illustrate the issue in operational terms.
Explain the “So What” factor	Why is this important to our business? What could it cost us if we fail to act?
Suggested Immediate Actions	Propose specific responses and why we should take them.  What will taking that action provide the business with regards to reduced impact or liability?  There may be more than one potential path.  If there are viable options, they should be presented for decisioning.
Other Proposed Remediation	Are there follow-on risks that require additional action?  Examples are communication strategy, user awareness activities, process changes, systems/tools enhancements or implementations (long-term actions)

APPENDIX III – INCIDENT RESPONSE CHECKLIST 

Refer to the Security Incident Response Form 

No.	Description	Remarks
	Preparation Phase (Incident Response Commander)
1	Prepare contact list and disseminate to relevant parties
	Identification (IT Support)
2	Complete sections 1 and 2 of the Incident Response Form
	Assessment (CSIRT)
3	Complete sections 3-5 of the Incident Response Form
4	Notify relevant parties
	Containment (CSIRT/Support)
5	Preform system backup to maintain current state of the system
6	Change local passwords for the affected system(s)
	Eradication (CSIRT/Support)
7	Do not use the system's administrative tools. Use separate administrative tool sets for investigation.
8	Re-install a clean operating system
9	Harden the operating system (e.g. apply patches, disable unnecessary services, install anti-virus software, etc.)
	Recovery (CSIRT/Support)
10	Validate that the system has been hardened
11	Restore system data with clean backup
12	Put the affected system(s) under network surveillance for future unauthorized attempts
	Follow-up (Incident Response Manager)
13	Perform analysis on affected system(s) to identify (potential) vulnerable areas
14	Submit an Incident Response Report for management review
15	File all documentation on the incident response process for future reference

APPENDIX IV – NOTIFICATION REQUIREMENTS 

List all requirements that apply to the organization 

Requirement	Clients Impacted	Notification Timing	Notes
U.S. Department of Education – Federal Student Aid (FSA)		Immediately, no later than 24 hours after discovery
PCI DDS (Payment Card Industry Data Security Standard)		Immediately, no later than 24 hours after discovery
OMES (Oklahoma Office of Management & Enterprise Services)		Immediately, but may be delayed at law enforcement advisement
GDPR (General Data Protection Regulation)		72 hours after becoming aware of breach
HIPAA (Health Insurance Portability & Accountability Act)		No later than 60 days following a breach
FDC/OCC (Financial Development Company/Office Comptroller Currency)		No later than 7 days after the date on which there is a reasonable basis to conclude that a major incident has occurred
All others as applicable

 

PCI DSS 

Any security incident involving a breach or cardholder data must adhere to all notification and response requirements of the Payment Card Industry (PCI) Security Standards Council. 

Visa 

Taking immediate action 

SWOSU upon the suspected or confirmed security breach must take immediate action to help prevent any additional damage and adhere to Visa CISP requirements. 

Alert necessary parties immediately: 

• Your internal incident response team and information security group 

• Your merchant bank(s) 

• If you do not know the name and/or contact information for your merchant bank, notify Visa Incident Response Manager immediately at U.S. – (650) 432-2978 or usfraudcontrol@visa.com 

Loss or theft of account information 

Members, service providers, or merchants must immediately report the suspected or confirmed loss or theft of any material or records that contain Visa cardholder data. 

Forensic Investigation Guidelines 

A Visa client/member or compromised entity must engage a Payment Card Industry Forensic Investigator (PFI) to perform a forensic investigation. Visa will NOT accept forensic reports from non-approved forensic companies. It is Visa client or member’s responsibility to ensure their merchant or agent engages with a PFI to perform a PFI forensic investigation. Visa has the right to engage a PFI to perform a further forensic investigation as it deems appropriate and will assess all investigative costs to the appropriate Visa client, in addition to any assessment that may be applicable. PFIs are required to release forensic reports and findings to Visa. All PFIs must utilize Payment Card Industry reporting templates. 

Note: For a list of PFIs, please go to: https://listings.pcisecuritystandards.org/assessors_and_solutions/pci_forensic_investigators 

Note: Visa has the right to reject the report if it does not meet the PFI requirements. PFIs are required to address Visa, the acquirer, and the compromised entity, and discrepancies before finalizing the report. 

To preserve evidence and facilitate the investigation: 

• Do not access or alter compromised system(s) (e.g., don’t log on at all to the compromised system(s) and change passwords; do not log in as ROOT). Visa highly recommends that the compromised system not be used to avoid losing critical volatile data. 

• Do not turn the compromised system(s) off. Instead, isolate compromised system(s) from the network (e.g., unplug network cable, shut down switchport, etc.). 

• Preserve all evidence and logs (e.g., original evidence, security events, web, database, and firewall logs, etc.) 

• Document actions taken, including dates and individuals involved. 

• If using a wireless network, change the Service Set Identifier (SSID) on the wireless access point (WAP) and other systems that may be using the connection (with the exception of any systems believed to be compromised). 

• Block suspicious IP addresses from inbound and outbound traffic. 

• Be on high alert and monitor traffic on all systems with cardholder data. 

For more information on the forensic investigation guideline, please refer to the document labeled PCI Forensic Investigator (PFI) Program Guide. 

MasterCard 

The MasterCard Account Data Compromise User Guide sets forth instructions for MasterCard members, merchants, and agents, including but not limited to member service providers and data storage entities regarding processes and procedures relating to the administration of the MasterCard Account Data Compromise (ADC) program. 

Discover 

To Contact Discover regarding Data Security or PCI Compliance: 

Data Security:  1-800-347-3083 Call Mon–Fri 8:30am to 12:30pm and 1:30pm to 4:00pm Eastern Time, excluding holidays 

Questions on Security or PCI Compliance:  AskDataSecurity@discover.com 

Report data compromise or cardholder data breach:  1-800-347-3083 Call Mon–Fri 8:30am to 4:00pm Eastern Time, excluding holidays 

American Express 

Data Incident Management Obligations: Merchants must notify American Express immediately and in no case later than twenty-four (24) hours after discovery of a data incident. 

To notify American Express, please contact the American Express Enterprise Incident Response Program (EIRP) toll free at (888) 732-3750 (US only), or at 1-(602) 537-3021 (International), or email at EIRP@aexp.com. Merchants must designate an individual as their contact regarding such Data Incident.  

Please see the American Express Data Security Operating Policy for all details pertaining to Data Incident Management Obligations. 

HIPAA (Health Insurance Portability and Accountability Act) 

Reference: http://www.hhs.gov/hipaa/for-professionals/breach-notification/ 

The HIPAA Breach Notification Rule, 45 CFR §§ 164.400-414, requires HIPAA covered entities and their business associates to provide notification following a breach of unsecured protected health information. 

HIPAA Breach Definition 

A breach is, generally, an impermissible use or disclosure under the Privacy Rule that compromises the security or privacy of protected health information. An impermissible use or disclosure of protected health information is presumed to be a breach unless the covered entity or business associate, as applicable, demonstrates that there is a low probability that the protected health information has been compromised based on a risk assessment of at least the following factors: 

• The nature and extent of the protected health information involved, including the types of identifiers and the likelihood and re-identification 

• The unauthorized person who used the protected health information or to whom the disclosure was made 

• Whether the protected health information was acquired or viewed 

• The extent to which the risk to the protected health information has been mitigated 

There are three exceptions to the definition of “breach.” 

• The first exception applies to the unintentional acquisition, access, or use of protected health information by a workforce member or person acting under the authority of the covered entity or business associate, if such acquisition, access, or use was made in good faith and within the scope of authority. 

• The second exception applies to the inadvertent disclosure of protected health information by a person authorized to access protected health information at a covered entity or business associate to another person authorized to access protected health information at the covered entity or business associate, or organized health care arrangement in which the covered entity participates. In both cases, the information cannot be further used or disclosed in a manner not permitted by the Privacy Rule. 

• The final exception applies if the covered entity or business associate has a good faith belief that the unauthorized person to whom the impermissible disclosure was made, would not have been able to retain the information. 

If a covered entity determines that a breach has occurred, the following breach notification obligations apply: 

1. Notice to Individuals: Affected individuals must be notified without unreasonable delay, but in no case later than 60 calendar days after discovery. 

1. If the covered entity has insufficient or out-of-date contact information for 10 or more individuals, the covered entity must provide substitute individual notice by either posting the notice on the home page of its web site for at least 9 days or by providing the notice in major print or broadcast media where the affected individuals likely reside. 

2. Notice to Media: If a breach affects more than 500 residents of a state or smaller jurisdiction, the covered entity must also notify a prominent media outlet that is appropriate for the size of the location with affected individuals. 

3. Notice to HHS (US Department of Health & Human Services): Information regarding breaches involving 500 or more individuals (regardless of location) must be submitted to HHS without reasonable delay and no later than 60 days following a breach. 

1. If a particular breach involves 500 or fewer individuals, the covered entity is required to report the breach to HHS within 60 days after the end of the calendar year in which the breach occurred via the HHS web portal. 

4. Notice by Business Associates to Covered Entities: All business associates of a covered entity must notify the covered entity if the business associate discovers a branch of unsecured PHI. Notice must be provided without unreasonable delay and in the case later than 60 days after discovery of the breach. See the Security Incident Response Form. 

5. Administrative Requirements and Burden of Proof: Covered entities and business associates, as applicable, have the burden of demonstrating that all required notifications have been provided or that a use or disclosure of unsecured protected health information did not constitute a breach. Thus, with respect to an impermissible use disclosure, a covered entity (or business associate) should maintain documentation that all required notifications were made, or alternatively, documentation to demonstrate the notification was not required: (1) its risk assessment demonstrating a low probability that the protected health information has been compromised by the impermissible use or disclosure; or (2) the application of any other exceptions to the definition of “breach.” 

U.S. Department of Education – Federal Student Aid (FSA) 

Once a cyber incident has been confirmed, institutions of higher education are required to notify the Office of Federal Student Aid (FSA) of data breaches via email pursuant to the GLBA Act, and Title IV participation and SAIG agreements. Additional proactive tools for institutions of higher education are available at Cybersecurity page on ifap.ed.gov. 

U.S. Department of Education Contact Information: 

Phone:  1-800-USA-LEARN (1-800-872-5327) 
Email:  cpssaig@ed.gov (email) 
Cybersecurity page:  https://fsapartners.ed.gov/knowledge-center/topics/fsa-cybersecurity-compliance 

Federal Student Aid Contact Information: 

Email:  FSASchoolCyberSafety@ed.gov 
Report a Breach:  Cybersecurity Intake Form 
Website:  https://fsapartners.ed.gov/home/ 

More information about FSA Cybersecurity can be found at: https://fsapartners.ed.gov/title-iv-program-eligibility/cybersecurity 

State of Oklahoma 

Once a cyber incident has been confirmed, SWOSU is required to report the incident. An incident must be reported in a timely manner to the Oklahoma CyberCommand. 

Notification Process: 

• Initial notification of a cyber incident should be made to the Lead Technology Position (Director of Information Technology Services) of the affected state agency or office. The affected state agency or office will make the appropriate cyber incident notification to the Oklahoma CyberCommand and law enforcement. 

• Notification of this cyber incident should be made through the Oklahoma Office of Management & Enterprise Services (OMES) IS Service Desk at the contact information provided below. The Oklahoma CyberCommand will provide all necessary notification and coordination to the Supervisory Special Agent of the Computer Intrusion Squad at the Federal Bureau of Investigation (FBI) and the Electronic Crimes Special Agent at the United States Secret Service. 

RESPONSE ACTIONS 

• Once an incident has been reported, specifics such as time, date, location, affected systems, and the nature and consequence of the incident will be obtained. 

• An initial response team and the affected agency will respond to the incident. 

• The focus will be on identifying the origins of the incident and apprehending those responsible. If the initial response team suspects the incident to be a cyber terrorism incident, the FBI Joint Terrorism Task Force (JTTF), and Oklahoma Office of Homeland Security will be notified. Based on continuing analysis and assessments, the initial response team will focus on remediation of mission critical information and telecommunications systems, as well as those systems whose loss would constitute an immediate threat to public health or safety. 

• The Oklahoma CyberCommand shall apprise the State Chief Information Officer, and the person(s) responsible for Information Technology at the agency, affected by the computer incident of the progress of the investigation to the extent possible. 

Oklahoma CyberCommand Contact Information: 

Email: cybercommand@omes.ok.gov 
Phone: 405-521-2444 (toll free: 1-866-521-2444) 

More information about the Oklahoma Information Security Policy can be found at: https://oklahoma.gov/content/dam/ok/en/omes/documents/InfoSecPPG.pdf 

GDPR 

The General Data Protection Regulation (GDPR) is the toughest privacy and security legislation in the world. It was passed by the European Union (EU) on May 25th, 2018, but imposes obligations on organizations everywhere, if they collect data on people in the EU. Violation of GDPR can result in harsh fines for those who violate its privacy or security standards. Maximum violations can be either €20 Million or 4% of a company’s global revenue, whichever is higher. Further, it allows individuals whose data has been mishandled to seek compensation for damages. 

Per GDPR, any data breach involving the personal data of EU residents must be reported to the EU Data Protection Authority (DPA) within 72 hours, although there are provisions that allow the company to report reasons for delay. Due to the severe penalties involved for reaching security requirements imposed on organizations, if the Company has business in the EU or with EU residents, they are advised to seek professional legal advice regarding their obligations. 

APPENDIX V – MEDIA STATEMENTS 

Below are sample statements to use if members of the media call before a press release is issued. All communications with the media should be directed to the Assistant Vice President of PR & Marketing, the Incident Response Manager, or other representative designated by executive management. Getting the facts correct is a priority. Do not give information to the media before confirming facts with internal personnel and management. Changing information after it is released can lead to media confusion and loss of focus on key messages. 

Pre-Scripted Holding Statements for Media Inquiries 

Use this template if the media is “at your door” and you need time to assemble the facts for the initial statement. 

Getting the facts is a priority. It is important that SWOSU not give in to pressure to confirm or release information before having confirmation. 

The following response gives the necessary time to collect the facts. 

For Individuals Who Are Not Authorized to Speak to the Media 

If the media contacts an individual who is not authorized to speak to the media:  

• “I am not a quotable source, please contact the Assistant Vice President of PR & Marketing for information on this matter.” 

For the Authorized University Spokesperson 

If on the phone the media: 

Before making any statement or giving any information over the phone, refer to the press’s inquiry log and get the journalist’s email. Providing statements via email allows us to verify facts, discuss information, and provide appropriate context for the journalist. Additionally, emailing information provides a written record that can be referred to if information is omitted from the statement when published.  

Initial Holding Statements for Media Phone Inquiries:  

• The safety and well-being of our students, faculty, staff, and neighbors are our first priorities. [Expression of compassion/concern if appropriate]. As more information is available, we will be providing updates through [web site address] and regular media briefings. 

• “We’ve just learned about the [situation, incident, event] and are trying to get more complete information now. How can I reach you when I have more information?” 

• “All our efforts are directed at [bringing the situation under control]. I’m not going to speculate about the situation. What is your email, and I will reach out to you when I have more information?” 

• “We’re preparing a statement now. Can I email you in about [number of minutes or hours]?” What is your email? 

If in person at the incident site or in front of a press meeting: 

• This [issue] took place [date and time] and affected [this group of individuals]. We apologize that we cannot provide [service] at this moment. Our technicians are working diligently to get our operations to full functionality as soon as possible. 

• We will continue to update you on our progress in resolving this matter at [website] and on Twitter at [handle]. We have created a dedicated customer service line to address any inquiries related to this issue. We ask that you please be patient with our customer support team as they work to help address your concerns/needs. The support team can be reached at 1-800-123-4567. 

• This is an evolving [situation, incident, event], and I know you want as much information as possible right now. While we work to get your questions answered, I want to tell you what we can confirm right now: at approximately [time], a [brief description of what happened]. 

• We have a [system, plan, procedure, operation] in place. We are being assisted by [local officials, experts, and our legal team] as part of that plan. 

• The situation is [under, not yet under] control. We are working with [local, state, federal] authorities to [correct this situation, determine how this happened]. 

• We ask for your patience as we respond to the [situation, incident, event]. 

Statements Should Avoid 

• Confrontation - the objective of media statements in a crisis is to diffuse the situation – not make it worse. Avoid blaming/buck-passing because it will simply result in a media-based argument between opposing parties – remember journalists love confrontational stories. e.g., ‘They were wrong’, ‘it is not our fault’. 

• Ambiguity - weak, ambiguous statements have no place in handling negative media situations and can leave room for the journalist to re-interpret your response. Always be robust and clear. Use strong positive words, e.g., ‘we are committed to X and will not tolerate Y’. Make sure your statement is completely unambiguous.  

• Personal pronouns - try to avoid referring to your organization by name in your media statement as doing this could reinforce the link between your organization and the negative issue concerned. You may simply use the first-person plural (‘we’/’us’). This also has the advantage of adding a slightly personal and less bureaucratic feel to the statement.  

Crisis Analysis Worksheet 

Before issuing any statement, the crisis response team should answer the following questions. These answers provide the crisis communication team with key details that will be needed as statements are drafted and provided to the media. 

1. How did we learn about the crisis? 

2. Briefly describe the crisis: 

3. In addition to members of the Crisis Management Team, are there other personnel who can provide vital information when preparing a response?  Provide their names and contact information: 

4. Does the crisis involve a specific campus, college, department, office, or program? 

5. Are there specific stakeholders who can provide secondary messaging in this crisis?  Who will contact them? 

6. Are there particularly sensitive elements of this crisis that need to be considered in our messaging? Are there any public officials involved in this crisis?  

Press Inquiry Log 

If you are authorized to speak with the media, please ask the following questions on the initial call and be sure to let them know you will follow up with them via email.  

1. What is your name? 

2. What media outlet do you represent? 

3. What is your email and phone number? 

4. What story are you working on? 

5. Are there any specific questions you have? 

6. What is your deadline? 

End the call by letting them know a representative will follow up through email. 

APPENDIX VI – CUSTOMER LETTER TEMPLATE 

Formal Email and/or Letter Template 

Dear [Vendor, Staff, Faculty, Student, etc.], 

Southwestern Oklahoma State University (SWOSU) recently announced that it experienced a criminal intrusion into a portion of its information system. This criminal intrusion may have resulted in the theft of [add brief description of event]. The university has not determined that any such data was in fact stolen by the intruder, and it has no evidence of any misuse of such data. 

SWOSU is providing this notice out of an abundance of caution to all its customers who have provided their contact information to the university, including you. YOUR INFORMATION IS NOT NECESSARILY AFFECTED. 

SWOSU believes that the potentially impacted systems were breached during the period of <insert date> through <insert date>. 

Upon recognition of the intrusion, SWOSU took immediate steps to secure the affected part of the network. An investigation supported by third-party forensics experts is going on to understand the nature and scope of the incident. SWOSU believes the intrusion has been contained. However, given the continuing nature of the investigation, it is possible that time frames, location, and/or at-risk data in addition to those described above will be identified in the future. 

SWOSU has notified federal law enforcement authorities and is cooperating in their efforts to investigate this intrusion and identify those responsible for the intrusion. The press release and this letter have not been delayed as a result of this law enforcement investigation. SWOSU has also notified the appropriate governing bodies and is cooperating in their investigation into the intrusion. 

SWOSU has established a hotline to answer questions about the intrusion and the identity protection services being offered. The hotline will be staffed [dates and times]. 

We value our students, faculty, and staff, and we regret any inconvenience that this may cause you. 

Sincerely, 

<insert name and title> 

Possible other considerations to include depending on the nature of the incident 

• Provide free credit reports (http://www.annualcreditreport.com/ or 1-877-322-8228) 

• Fraud Alerts – Equifax (https://www.equifax.com or 1-877-478-7625), Experian (https://www.experien.com or 1-888-397-3742), TransUnion Fraud Victim Assistance Division (www.transunion.com or 1-800-680-7289) 

APPENDIX VII – INCIDENT RESPONSE ORGANIZATIONS 

Below is a list of incident response organizations that may be useful in planning for or responding to an incident: 

Organization	URL
Anti-Phishing Working Group (APWG)	https://www.antiphishing.org/
Computer Crime and Intellectual Property Section (CCIPS), US Department of Justice	https://www.justice.gov/criminal-ccips
CERT Coordination Center	https://www.sei.cmu.edu/about/divisions/cert/index.cfm
European Network and Information Security Agency (ENISA)	https://www.enisa.europa.eu/
Government Forum of Incident Response and Security Teams (GFIRST)	https://www.us-cert.gov/government-users/collaboration/gfirst
High Technology Crime Investigation Association (HTCIA)	https://htcia.org/
InfraGard	https://www.infragard.org/
Internet Store Center (ISC)	https://isc.sans.edu/
National Council of ISACs	https://www.nationalisacs.org/
United States Computer Emergency Response Team (US-CERT)	https://www.us-cert.gov/
FRSecure	https://frsecure.com/

 

APPENDIX VIII – CONTAINMENT STRATEGIES 

The following containment strategies have been defined to assist in incident response. If none of the containment strategies outlined below fit the current situation, refer to Phase III – Containment: Common Containment Steps on page 9 of this plan. 

Stolen Credentials 

Containment 

Reduce Impact: 

• Change the password or disable affected accounts. 

• If the compromised account had administrator access, review activity logs for additional accounts that may have been created. Disable any accounts created by the attacker. 

Notify Interested Parties: 

• Notify the users responsible for the impacted accounts. 

Investigation 

• Attempt to determine the date and time that the account was compromised 

• Review all activities completed by the compromised account during the period of compromise. If logs do not exist, check all configurations the account had access to modify. (e.g. for a compromised email account, check for added or changed forwarding rules) 

Eradication and Recovery 

• Reverse changes made by the compromised account during the time of compromise 

RANSOMWARE 

Containment 

• Block access to command and control (C2) servers 

• Set file shares into read-only mode 

• Check ownership of encrypted files to determine infected user or users 

• Recall known phishing emails from user mailboxes 

• Take infected systems offline 

Eradication & Recovery 

• Patch third-party applications as soon as possible 

• Test and validate back-up processes 

• Deploy GPO to block executables and disable macros 

• Block email attachments based on file signature and/or extension 

• Remove local administrative rights 

Virus Outbreak 

1. Update antivirus software 

1. Obtain detection signature and technical description for virus from AV vendor 

2. Test detection signature update provided in test environment 

3. Distribute fix to environment 

2. Submit sample file to AV vendor if latest virus signature does not detect the infection 

Eradication & Recovery 

3. Eradicate the virus, if necessary 

1. Contain virus/attack (depending on virus this could include partitioning the network, disabling SMTP email, changing content filtering to block attachments or specific strings of text, removing workstations from the network, etc.) 

2. Identify infected systems 

4. Environment cleanup: 

1. Obtain the detection signature and any required fix tools for the virus from your antivirus vendor. 

2. Test the fix provided by your vendor for the virus in your virus signatures staging lab. This may include separate repair tools that you need to run before using the updated virus signatures. 

3. Develop a deployment methodology to fix the process. 

4. Create a cleanup plan and validate with all affected teams and your antivirus vendor. 

5. Clean all infected perimeter and email servers and update the virus signatures of the antivirus software providing protection of these avenues of infection. 

6. Distribute the fix to all the workstations and servers in your environment using whatever method you have in place for rapid deployment. 

7. Isolate systems that are infected and require repair. 

8. Run all required fix tools on all infected systems to remove the virus from memory or disable it. 

9. Scan all systems with the updated virus signatures to remove all infected files. 

10. Eliminate all temporary and suspicious files, including Gidden directories and files. 

11. Remove or alter configuration information used for the functionality of the virus, or that might allow the virus to reappear. 

12. Remove configuration information that may cause system failures. 

13. Search for newly mounted partitions created by the virus and eliminate them. 

14. Search for missing log partitions and restore. 

15. Search for added or altered user accounts and remove or restore. 

16. Restore changed or deleted files. 

17. Distribute patch updates to all systems and update patch levels. 

APPENDIX IX – CYBER INSURANCE & THIRD-PARTY SERVICE AGREEMENTS 

Where cyber insurance or third-party services are involved, having a clear understanding of the incident response and detection services is essential. For example, many cyber insurance carriers require the organizations they cover to follow a pre-defined process. Examples of third-party service provider (ISP), cloud service provider (CSP), software vendors, or a multiservice provider (MSP). 

The Director of Information Technology Services is responsible for reviewing all SLAs with service providers to ensure that responsibilities and expectations are defined in relation to incident response. 

The Incident Response Manager is responsible for understanding SLAs with service providers and knowing when the team should engage with the service provider. 

Third Party Support and Response
Service Provider	Applications/Services	When to Contact
Ferrilli	O365/General Support	Immediate
OneNet	ERP/Backup	Immediate
Alias Cybersecurity	Incident Response Services	Immediate