UNIVERSITY OF WISCONSIN River Falls

Information Security

Incident Response Plan (UWSA 1033)

Revision Date: April 9th, 2019

Table of Contents

Note: Items called out in bold italics are verbatium replications from the official UW-System Administration policy documents.

1. Purpose


The Information Security Incident Response procedure provides specific details of how information security events are handled within the University of Wisconsin-River Falls. This procedure has been developed to comply with University of Wisconsin System Administration Policy 1033, Information Security Incident Response, last revised July 31, 2017, which requires every UW System institution to have this written procedure.

2. Responsible


Each Chancellor or designee shall annually review and approve their institution’s information incident response procedure. The UW System President or designee shall annually review and approve UW System Administration’s information security incident response procedure.

At UW-River Falls, the Chief Information Security Officer reports to the UW-River Falls Chief Information Officer who reports to the Provost who is a member of the cabinet led by Chancellor.

The Division of Technology Services is composed of four major distinct units of Infrastructure & Security Technologies, Enterprise Application Services, Enterprise Systems and Services, and the Teaching & Learning Technologies departments. Each of those department managers report to the Chief Information Officer. Each staff member in Technology Services reports to one of these managers.

Incident investigations are specialized forensics processes and the affected department is responsible for the initial investigation costs. All costs associated with the initial forensics of an incident will be charged to the department(s) involved with an incident investigation. These costs begin at about $4,000 for a basic triage investigation and may range upward to $10,000 depending on the nature. Investigations are conducted by the Division of Technology Services and direct invoicing against a purchase order opened on behalf of the department will be made using the department's provided funding string. After the initial investigation costs are past and more is known, the secondary investigation and then re-mediation may range in the additional thousands of dollars and even in the millions.

3. Scope


This procedure applies to all University of Wisconsin-River Falls faculty, staff and associated individuals. 

4. Background


This procedure is internal to the University of Wisconsin-River Falls and is intended to be in alignment with applicable UW System and Board of Regents policy. UW-River Falls is committed to a secure information technology environment in support of its mission. The Division of Technology Services is entrusted by the administration to ensure this procedure is designed to generate a swift and deliberate response to any security event that may occur.

5. Definitions

 

Term Definition of Term

CIO

Chief Information Officer (aka Executive Director of the Division of Technology Services) - Responsible for all matters related to information technology for the university. 

CISO

Chief Information Security Officer - The person designated by the CIO as responsible for information security related matters for the university.

Cloud Services

Solutions that are contracted as infrastructure or software as a service - not internally hosted applications.

COOP

Continuity Of Operations Plan - The institutions plan for reacting to a crisis and "keeping the lights on" at the institution. The Emergency Management Team is responsible for ensuring COOP is activated and progressing.

Customers

Individuals or departments at the university that are in partnership with the Division of Technology Services for information technology services. May include students, faculty, staff, contractors, guests, parents of students or any others with a business with the university.

DoTS

Division of Technology Services - The information technology department within UW-River Falls. 

Environment

An application, service, network, domain, database, file structure, physical location or other information technology related component.

IRT

Incident Response Team - The group of individuals that are reacting in a cohesive way to the report of a potential incident.

PS

Professional Services - A department within the Division of Technology Services responsible for Information Technology Service Management and Project Management methodologies, including oversight of the tier 1 helpdesk unit.

Stakeholders

Individuals that have some interest in a particular incident - its response or the outcomes associated with it.

 

6. Procedures


This policy requires that any individual who suspects that an information security incident has likely occurred shall report it using the appropriate institutional procedures. Personnel involved in information security incidents shall cooperate with investigation teams and provide access to UW System assets. Where personally owned information technology assets are involved, cooperation and access is necessary to ensure no institutionally owned data is compromised.
This policy requires the creation of an information security incident response procedure at each UW System institution. These information security incident response procedures shall contain the following:

From https://www.wisconsin.edu/uw-policies/uw-system-administrative-policies/information-security-incident-response/

6.A Procedures - Preparation


i. Procedures detailing the implementation of tools, process and staff to monitor assets for indicators of compromise and signatures for misconfigured or vulnerable systems
ii. Procedures for submitting information of a potential incident to appropriate incident response personnel
iii. Identification of specific position(s) and/or team(s), and their roles and responsibilities for those involved in incident response. This may include management, departmental representatives, information technology response staff, institutional risk management, university communications, and legal advice
iv. Identification of documentation to be collected during the response to the incident
v. Integration with other institutional business continuity and disaster recovery programs
vi. A requirement for annual testing of the incident response procedure

From https://www.wisconsin.edu/uw-policies/uw-system-administrative-policies/information-security-incident-response/

6.A.i Procedures - Preparation - Monitoring Assets


i. Procedures detailing the implementation of tools, process and staff to monitor assets for indicators of compromise and signatures for misconfigured or vulnerable systems

UW-River Falls will meet this policy objective in the following ways:

  • The Chief Information Security Officer monitors various sources (i.e. XOPS, FBI InfraGuard, SANS Internet Storm Center, etc.) for notification of known or suspected compromise. The CISO will pass on to team leads any information that seems pertinent to the environment.
  • All team leads and/or service owners will monitor industry notifications for each application or service under team's control or for which they are liaisons with the customer base. They will provide notification to their peers, to their manager and to the CISO when a vulnerability has been identified as pertaining to the environment.  
  • All customers of cloud services or applications that are hosted by DoTS will forward security notifications received from their vendors to the appropriate DoTS service liaison.
  • All team leads and/or service owners will monitor logs produced by the environment for indications of misconfiguration or compromise. These logs will be configured in a manner that only a small number of exceptions are being reported to reduce ambient noise level making it more likely that humans will review the information daily.
  • Through various monitoring programs, system administrators set metrics for normal utilization of services.  The server, storage and network teams also monitor at an infrastructure level for unexplained anomalies in metrics monitored. Alerts to Spark, SMS, email or other appropriate communication channels should be configured when an alarming threshold is met.
  • Server operating systems are updated automatically and those servers that are not are documented in the update tool to why they are manually patched. Weekly patching reports are sent to the team leads and each team lead should ensure their environment is being addressed.
  • On a monthly basis, the storage and server team lead will bring the anomalies report (not patched in the last 90 days) to the weekly Professional Service meeting for discussion. The group of team leads and management should create an action plan and document expected resolutions for each anomaly.
  • The server and storage team will monitor Active Directory usage for active successful login attempts, invalid login attempts, locked accounts and password changes for anomalies in the average pattern.
  • Entirely hosted cloud services should be adequately monitored, vendor notifications subscribed to, status pages checked and a contractual obligation for the vendor to notify the institution for all security related events established.
  • Any activity that should be done on a periodic, but yet infrequent, basis should be set up in the ticketing system as a scheduled ticket to ensure those activities are completed. A scheduled meeting of a team would also be appropriate as long as there is always a future meeting on the calendar. Individual accountability for task completion needs to be logged in the ticketing system for transparency.
  • All service reviews that are conducted by the Division of Technology Services Enterprise Application Services team will gather 24x7x365 contacts for departmental personnel to be used in the event of a service related emergency. This information is stored in a OneNote here: Services.

6.A.ii Procedures - Preparation - Reporting Incidents


ii. Procedures for submitting information of a potential incident to appropriate incident response personnel

DoTS Staff University Constituents outside of DoTS

By any two-way communications channel available report to:

  1. Chief Information Security Officer (CISO)
  2. If unavailable: Chief Information Officer (CIO)
  3. If unavailable: Refer to DoTS COOP (Continuity Of Operations Plan) - 2.05 Orders of Succession
  • Call 715.425.3687 and declare a general emergency to be escalated to a DoTS manager.
  • The DoTS manager that takes this call should report the incident as noted above internally to DoTS.

 

How do you determine if an incident should be reported?

  • If you are asking this question of yourself, report it immediately!
  • The CISO should discuss with you the potential incident details and together you will make a determination to the first course of action taken.
  • The CISO is responsible for understanding the entire environment at a high level. There may be other factors already at play you are not aware of or you may be the first to contribute to a host of future indicators.

What is a "potential incident" to report?

"See something, say something"

  • If you feel that there is a potential for a breach in data security, a system may be compromised with an unknown component, or data is being accessed by unauthorized entities, then immediately report it as prescribed above.

How much research should I do before reporting it?

DoTS engineers should conduct enough research to understand what they are seeing so they can have a conversation with the CISO about the situation. However, do not do so much research that you are delaying involving the CISO and the management team. Do not stop or alter the services that may compromise evidence. Do not do too much time in forensics as that will potentially be done in conjunction with a response team. The initial conversation with the CISO will be to determine your first and subsequent courses of action.
 
When is malware and virus infections routine or not routine?

The answer is dependent on the results that are found in the initial scan. Most tools provide links to a library of knowledge related to the findings of the scan. Review the findings and if you are seeing key phrases like data exfiltration, remote command and control, password collection or XYZ data is at risk then the incident should be reported as prescribed above. If the malware is more ad-ware in nature and is just a PUP (potentially unwanted program) without more scary traits, then only an incident ticket documenting the results is needed.

6.A.iii Procedures - Preparation - Incident Response Team


iii. Identification of specific position(s) and/or team(s) and their roles and responsibilities for those involved in incident response. This may include management, departmental representatives, information technology response staff, institutional risk management, university communications, and legal advice

Incident Response Team (IRT)

  • The Chief Information Security Officer will serve as incident command and in their absence the Chief Information Officer may designate or be the incident command.
  • The following staff and areas will be included as needed and as the situation evolves. Initial investigations will be done on a "need to know" basis only to prevent speculations from becoming rumors. There is also a potential of an "inside job" and those details need to be carefully ruled out first. No individual should communicate outside the team without it being approved by the CISO and/or CIO.

Management

  • The CIO will provide updates to their supervisor, the Provost, and as requested directly to the Chancellor's cabinet on an agreed upon frequency.
  • The time frame for the first notification will be dependent upon the incident scope.

Departmental Representatives

  • If the potential incident involves a departmental representative, they will be brought into the investigation at the appropriate time.
  • Their cooperation is likely critical to understand what may have occurred or what the impact of that incident has on the safety and reputation of those involved.

Information Technology Response Staff

  • The five managers of the Division of Technology Services report to the Chief Information Officer and will be responsible for the coordination of the incident response team activity in conjunction with the Chief Information Security Officer.
  • Any environment related to information technology would fall under one of these managers and if there is a conflict with the CISO serving as a departmental manager, as the CISO, the CIO may appoint one of the other managers to the response.
  • Depending on the sensitivity of the incident, each of the managers will bring in only those that are needed for the response which may include their team leads and/or specific engineers.

Institutional Risk Management

  • The university's Emergency Management Team may be stood up in response to a large scale incident at the discretion of the Chief Information Officer.
  • This response would serve as an "operation" under the Operations Section Chief and staffing would be determined.
  • The IRT (Incident Response Team) would serve as the field operations unit and the EOC Leader would lead the EOC response.

University Communications

  • In the event that is necessary for the institution to "report" or to "communicate" in regards this event, the Chief Information Officer should ask the Risk Manager to activate the Emergency Operations Center (EOC) in support the incident.
  • The EOC will follow standard institutional protocols to address issues related to communications through Human Resources and through the media involving the Public Information Officer.

Legal Advice

  • Legal advice should be sought by the CIO from UW-System General Counsel.  
  • UWRF Police Department may be sought, in a consultative manner, to assist in classifying the incident as criminal or non-criminal natures.  

6.A.iv Procedures - Preparation - Documentation


iv. Identification of documentation to be collected during the response to the incident

Documentation to be collected will be dependent on the nature of the incident.

Initial documentation to be collected will be used to classify the incident and whether further response is necessary. Documentation should be held in a secure manner and should be collected in a way as to not alter or destroy existing conditions of the system. As the response unfolds more obtrusive collection of data may occur, such as powering down systems to collect physical drives.

Examples of the initial documentation to be gathered:

  • Local system log files
  • Local application log files
  • Remote syslogs
  • Virtual hard drive snapshots already stored
  • Virtual hard drive snapshots created of running systems
  • Memory dumps
  • Screenshots of configurations
  • Screenshots or screen recordings of anomalies being demonstrated
  • Similar artifacts collected from other systems connecting to the suspected system
  • Network, operating system and application firewall logs
  • Load balancer logs
  • Antivirus and/or antimalware investigation reports
  • Subpoenas, warrants and other legal instruments scanned
  • Journal entries made by investigating staff including actions taken, observations made

All collected artifacts should be consolidated and a record of their source location and date, time and collector referenced in the meta data.

See 6.D Review for records retention.

6.A.v Procedures - Preparation - COOP


v. Integration with other institutional business continuity and disaster recovery programs

COOP - Continuity Of Operations Plans

UW-River Falls does not have a COOP team outside of the departmental plans. Each department does have a COOP team and an approved plan on file with the Risk manager. The Emergency Management Team at UW-River Falls would be utilized to assist in any large scale incident that requires additional resources and/or a need to communicate to the public.

The DoTS Continuity of Operations Plan (COOP) should be activated.

Management of System Downtime and Impact on Institutional Operations

In the event that a system is considered irreparable and/or will be offline for a period of time, the institution's Risk Manager should be brought in by the CIO to assist the department in activating their COOP program. The Division of Technology Services will assist the Risk Manager in those efforts as able. Those plans should already detail scenarios where they are without IT resources and how the department (or the institution as a whole) would try to recover.

The university's Emergency Management Team may be stood up in response to a large scale incident at the discretion of the Chief Information Officer. This response would serve as an "operation" under the Operations Section Chief and staffing would be determined. The IRT (6.A.iii Incident Response Team (IRT)) would serve as the field operations unit and the EOC Leader would lead the EOC response. This would be similar to the EOC supporting "fire command" for a building fire, where the IRT is the field team being supported.

Breach Notification

In the event that is necessary for the institution to report or to communicate in regards this event, the Chief Information Officer should ask the Risk Manager to activate the Emergency Operations Center (EOC) in support the incident. The EOC will follow standard institutional protocols to address issues related to communications through Human Resources and through the media involving the Public Information Officer.

See 6.C.iv Notification.

6.A.vi Procedure - Preparation - Testing of Procedure


i. A requirement for annual testing of the incident response procedure

Division of Technology Services

  • On an annual basis, the Division of Technology Services will conduct several activities to exercise the components of this plan from end to end.
  • A review will be conducted, the plan will be updated and the testing cycle will begin to measure for improvement.

Other Campus Areas

  • Each department that manages moderate or high risk data must make themselves familiar with this procedure and the associated policies.
  • Each functional area or departmental/divisional director is responsible for ensuring all staff are trained on their requirements to report.

6.B Procedures - Detection and Analysis


i. Procedures for initial investigation and assignment of severity for a potential incident
ii. Procedures for investigation of a suspected incident

From https://www.wisconsin.edu/uw-policies/uw-system-administrative-policies/information-security-incident-response/

6.B.i Procedures - Detection and Analysis - Initial Procedures


i. Procedures for initial investigation and assignment of severity for a potential incident

The initial procedure should be done at the time of realizing an event may have occurred. In this phase we are "looking but not touching" to try to determine what may be happening. The secondary procedure may take days but should more likely take hours and the 6.B.ii Investigative Procedures will then take days or weeks.

Initial Procedure - Discovery

  1. Report all incidents to the Chief Information Security Officer and/or Chief Information Officer and to your direct reporting manager per the section 6.A.ii Reporting Incidents.
  2. The CISO and/or CIO will evaluate the an initial report to assign a level of severity and to determine whether to activate entire 6.A.iii Incident Response Team (IRT) or a limited set of individuals
  3. Answer question: Is this incident criminal in nature?

At the incident manager's direction, initially the response should be to classify whether the incident is criminal in nature. Examples where there may be a criminal component might include:    

  • Financial fraud
  • Extortion, harassment, cyber-bullying, etc.
  • Child pornography
  • Involvement of at-risk population such as youth
  • Whenever not sure, ask first

The CISO and/or CIO may contact the university Police Chief, or designee, for assistance in determining the classification. It is best to ensure that the police are included to guide, or take over, the investigation.
    
There may be an incident where a criminal act might have occurred but in reality it is unlikely any investigatory or future law enforcement action will be taken due to the nature, lack of information or the size of the incident.  In these cases, a notification to police is still prudent but their involvement in the incident response is not expected:

  • DDOS (Distributed Denial of Service) attacks originating from outside the United States
  • Remote unauthorized access to a "small" system received via malware
  • "Run of the mill" social engineering threats

If an incident involving the university is reported from an outside law enforcement related agency, involve university police immediately for guidance on how the institution should respond. Keep in mind this may also be a social engineering threat and should be verified for its credibility.

6.B.ii Procedures - Detection and Analysis - Investigative Procedures


ii. Procedures for investigation of a suspected incident

Secondary Procedure - Investigation

At the direction of the incident manager and/or the 6.A.iii Incident Response Team (IRT)

  1. Begin collection of data using 6.A.iv Documentation
  2. Synthesize the data and understand the situation to prepare for presentation to CISO/CIO
  3. Call a meeting with the CISO and the CIO to review the data and to determine next steps
  4. Begin operating under the 6.B.ii Investigative Procedures

Keep in mind this is the investigation; you need to get to 6.C Containment, Eradication and Recovery in the quickest and most prudent way possible.  

Law Enforcement Related Incidents

Direction of how to proceed should be taken from University Police or other involved agencies.

Other Incidents Types

Direction of how to proceed should be taken from University Police or other involved agencies. Generally the 6.A.iii Incident Response Team (IRT) response steps to be followed include:    

  1. Establishing an incident command structure who will be in charge of the incident and the staffing of the team.
    1. Incident Manager - Oversight of the entire incident response and decision maker
    2. Operations Chief - Responsible for the incident investigation, response and clean up, the operation chief will supervise all of the "operations" under the incident including the investigation by engineering teams through the notification letters being mailed out. The brunt of the activities will happen under the operations section.
    3. Planning Chief - Works to establish a plan for the response and to ensure the plan is being met
    4. Logistics Chief - Responsible for ensuring vendors are procured to do the investigation and work to obtain any other required resources
    5. Finance Chief - Works with the other chiefs will develop a budget, gain approval of the budget from the incident manager and ensure the budget is monitored during the operation
    6. Public Information Officer - If an external voice is needed, the Emergency Management Team should be stood up (see 6.A.v COOP). Otherwise, internal communications will be kept under control.
  2. Establish a point of communication and sharing (i.e. a Microsoft Group for the incident, 6.C.iii Information Management)
  3. Meet to determine what steps will be needed for the investigation, what 6.A.iv Documentation needs to be collected, who are the stakeholders.
  4. When prudent, involve stakeholders and/or those that are involved in the incident
  5. Determine if outside consultants are required. If so, procure resources and schedule a discovery meeting with them to determine what steps are required. See Annex 13: Forensics Services in the DoTS Continuity of Operations Plan notebook for Forensic vendors.
  6. Determine steps, operational period of those steps, will the team meet again, when will stakeholders be updated and consulted?
  7. Will a "breach notification" to the public process need to be invoked?

6.C Procedures - Containment, Eradication and Recovery


i. Procedures to identify actions to be taken in response to an incident, including but not limited to:

  • Isolating compromised systems and coordinating the remediation
  • Blocking of potential hostile network traffic
  • Communicating to members of the institution’s information technology community the indicators of misconfigured or vulnerable assets

ii. Procedures that identify an appropriate escalation path for the incident based on severity.
iii. Procedures for collecting and managing information during the event lifecycle.
iv. Procedures for meeting the requirements for internal notification and legal requirements for external reporting and meeting notification periods.
v. Procedure for notifying the UW System CIO. Notification to the UW System CIO is required within one business day if a confirmed incident involves the reasonable likelihood of a compromise of high or moderate risk data. If the UW System CIO is not available, notification should be made to the UW System Chief Information Security Officer (CISO). If the CISO is not available, notification should be made to the UW System Help Desk.

From https://www.wisconsin.edu/uw-policies/uw-system-administrative-policies/information-security-incident-response/

6.C.i Procedures - Containment, Eradication and Recovery - Actions to Take


i. Procedures to identify actions to be taken in response to an incident, including but not limited to:
    • Isolating compromised systems and coordinating the remediation
    • Blocking of potential hostile network traffic
Communicating to members of the institution’s information technology community the indicators of misconfigured or vulnerable assets

A determination with the team should have been done prior to this to determine the direction in which containment and eradication is commencing. This should be signed off on by both the CISO and CIO.

In 6.B. Detection and Analysis, we were previously "looking and not touching."

Now in this step we are

  • touching and altering the systems
  • stopping the incident from proceeding further
  • trying to recover from the incident.  

This may include a complete restart of the system from fresh or it may be possible to eradicate the system of the situation.

Review NIST 800-184 for suggested processes

Suggested Actions, Situational Dependent

  • Continue to identify information that has been altered or if it is safe
  • Connect with any vendors that need to be involved in the recovery
  • Archive (aka hold, freeze) existing snap shots for long term recovery
  • Copy/clone hard drives using forensics tools
  • Verify network traffic signatures before and after eradication
  • Change all usernames and passwords (both) and redeploy to systems
  • Setup monitoring processes to watch for re-development of the situation
  • Determine restoration method and deploy
    • Restore from snapshots
    • Restore from backups
    • Install new server hardware and/or virtual machines, re-install application

6.C.ii Procedures - Containment, Eradication and Recovery - Escalation


ii. Procedures that identify an appropriate escalation path for the incident based on severity.

UW-River Falls is a small organization with only one team and pathway. All institution departments are responsible for notification through this plan to a single process. See 6.A.ii Reporting Incidents for a pathway to reporting any and all incidents related to information security regardless of their severity.

See 6.C.iv Notification for notification requirements.

6.C.iii Procedures - Containment, Eradication and Recovery - Information Management


iii. Procedures for collecting and managing information during the event lifecycle.

See 6.A.iv Documentation for reference of information to be collecting and maintaining.

  1. In Office 365, create a new Group for the incident.
    1. Add in the CIO and CISO as moderators/owners to the group.
    2. Add in as contributing team members only those others that are needed for the incident.
    3. Create a OneNote Notebook to maintain documentation related to the investigation and incident.
  2. Create Sharepoint file repositories as needed for the data collected.*
  3. Create a Lastpass share folder and add in appropriate team members to share any zip passwords, encryption keys, etc.
  4. Utilize the Microsoft Group for communications and to maintain a record of communications.

* Encrypt using a .zip utility any data that contains restricted information prior to uploading or storing in an electronic location. If physical media is present, discuss the security of that media with the CISO.

See Annex 13: Forensics Services in the DoTS Continuity of Operations Plan notebook for Forensic vendors.

See 6.D. Review for records retention.

6.C.iv Procedures - Containment, Eradication and Recovery - Notification


iv. Procedures for meeting the requirements for internal notification and legal requirements for external reporting and meeting notification periods.

Wisconsin State Law

Refer to 2005 WI Act 138 - statute 134.98 for definition to what requirements of notification are in Wisconsin.

Specifically, you have 45 days for a reasonable time before notification must be completed.

"Subject to sub. (5), an entity shall provide the notice required under sub. (2) within a reasonable time, not to exceed 45 days after the entity learns of the acquisition of personal information. A determination as to reasonableness under this paragraph shall include consideration of the number of notices that an entity must provide and the methods of communication available to the entity. 134.98(3)(a)"

Federal Law

Review Information Compromise and the Risk of Identity Theft: Guidance for Your Business and evaluate what requirements for reporting may exist for the incident. There are requirements for credit cards, social security numbers, financial information, health information, etc.

FTC Health Breach Resources

  • HIPAA Breach Notification Rule: hhs.gov/hipaa/for-professionals/breach-notification
  • HHS HIPAA Breach Notification Form: hhs.gov/hipaa/for-professionals/breach-notification/breach-reporting
  • Complying with the FTC’s Health Breach Notification Rule: ftc.gov/healthbreachnotificationrule
Administrative Requirements

The CIO will provide notifications to the Provost and/or CBO when one or more of the following conditions is met:

  • The procurement of forensic services to accurately determine the confirmation of the incident may be required for high or moderate risk data may being affected.
  • An incident investigation is commencing that may result in a mandatory notification to the public and/or affected individuals due to compromised high or moderate risk data

The CIO shall provide notification, within one business day, to the UWSA CIO/CISO/Helpdesk when the following condition is met:

  • A confirmed incident meets the "mandatory reporting" requirements

If a confirmed incident involves the reasonable likelihood of a compromise of high or moderate risk data, see 6.C.v UWSA Escalation

6.C.v UWSA Escalation


v. Procedure for notifying the UW System CIO. Notification to the UW System CIO is required within one business day if a confirmed incident involves the reasonable likelihood of a compromise of high or moderate risk data. If the UW System CIO is not available, notification should be made to the UW System Chief Information Security Officer (CISO). If the CISO is not available, notification should be made to the UW System Help Desk.

If moderate or high risk data is confirmed compromised, UWRF's CIO or UWRF's CISO shall contact UW-System within one business day to provide notification to them.

See 7 - Annex C: UWSA Contacts

6.D Procedures - Review


i. Procedures to collect and communicate information about an event to improve protection of the institution’s infrastructure
ii. Procedures to mitigate a reoccurrence of the event or incident
iii. Procedures for close-out of incidents
iv. Procedures for the tracking and management of incident related information. Institutions must update the UW System CIO of the resolution of the incident

The CISO should evaluate the tools that were used and archive any existing information into a secure package on media offline in the secure data center storage cabinet. Physical materials such as paper and hard drives containing data should be sealed and secured.

Prior to the incident being considered closed, the CIO should call upon the Professional Services  (PS) Manager to conduct a review of the incident.

The PS manager should evaluate, with the assistance of the CISO,

  • the response for proper ITSM and Project Management methodologies being used to manage the incident response
  • if there are modifications to any existing incident response protocols and procedures required
  • the effectiveness of communication and where improvements could have been made
  • that all mitigation to prevent a reoccurrence have been identified, documented and action is or being taken on them
  • closure of any vendor relationships including destruction of data forms, invoices and purchase orders (See Annex 13: Forensics Services in the DoTS Continuity of Operations Plan notebook for Forensic vendors.)

The PS manager in conjunction with the CISO should produce a shareable report in regards to the incident to the CIO, including a summary of the response and the lessons learned.

The CIO will provide a summary to the UWSA System CIO upon the conclusion of the incident review, as well as to the Chancellor's Cabinet where appropriate.

Records Retention

Notes should be maintained through the entire process on how data is collected and synthesized. The raw data should be protected. Data that is collected can be summarized and once prudent (approved by the incident manager in consultation with law enforcement and/or system legal) destroyed. All summary data and notes should be maintained for a period of no less than seven years and then can be destroyed if there is no pending action on the case.

7.A Related Information


An annex of documents are secured for access by the Division of Technology staff in a related knowledge base article.

  • Annex A: Technologies Employed
  • Annex B: Scheduled Tickets
  • Annex C: UWSA Contacts

Incident Severities

Severity ratings drive the actions of the IRT (incident response team.) Below are the severities ratings we use, some examples of incidents that might fall into that bucket, and some guidelines for about how to treat each class of incident.

Note the severities may (and often will) change during the lifecycle of the incident. That’s normal.

1 - High Severity

High Severity incidents successfully compromise the confidentiality/integrity of Personally Identifiable Information (PII), impact the availability of services for a large number of customers, or have significant financial impact. Examples include:

  • Confirmed breach of moderate or high risk data
  • Successful root-level compromise of production systems
  • Financial malware (ie. CryptoLocker) targeting UWRF faculty and staff
  • Denial of Service attacks resulting in severe outages
  • Unauthorized access or traffic across network

Guidelines for addressing High Severity issues:

  • Work will likely be 24?7 (e.g. work until the issue is contained).
  • Responders are empowered to take any step needed to contain the issue, up to and including complete service degradation.
  • CIO will inform Chancellor's cabinet immediately.
  • CIO will inform UWSA Office of Security immediately.
  • Situation reports should be sent every hour, or more, from the IRT to the CIO and/or CISO.

2 - Medium Severity

Medium Severity incidents represent attempts (possibly un- or not-yet-successful) at breaching high risk data, or those with limited availability/financial impact. Examples include:

  • Suspected PII breach of moderate or high risk data
  • Targeted (but as-of-yet unsuccessful) attempts to compromise production systems
  • Spam/phishing attacks targeting UWRF faculty and staff
  • DoS attacks resulting in limited service degradation

Guidelines for addressing Medium Severity issues:

  • Response should be business-hours.
  • Responders should attempt to consult stakeholders before causing downtime, but may proceed without them if they can’t be contacted in a reasonable time-frame.
  • Situation reports should be approximately twice a day, from the IRT to the CIO and/or CISO.

3 - Low Severity

Low Severity incidents do not affect moderate or high risk data, and have no availability or financial impact. Examples include:

  • Attempted compromise of non-important systems (staging/testing instances without product data, etc.)
  • Incidents involving specific employees
  • DoS attacks with no noticeable customer impact

Guidelines for addressing Low Severity issues:

  • Response should be business-hours.
  • Responders should avoid service degradation unless stakeholders agree.
  • Situation reports should sent approximately daily, from the IRT to the CIO and/or CISO.