Maintaining the confidentiality, integrity, and availability of systems and data is a risk management issue for all organizations, including the University of Connecticut. Furthermore, as more personally identifiable information is collected and systems and processes become increasingly more complex, regulations continue to place requirements for the protection of that information on the University.
The University has had security incidents in the past and should expect that they will occur in the future as additional technologies with differing demands are brought into the environment to service the information technology needs of the University. The Information Technology Security Office has created this Incident Response Plan to assist in incident identification, response, and notification.
The University Incident Response Plan addresses events affecting any University information technology resource which may negatively impact the confidentiality, integrity, and/or availability of the resource.
Because of the variety of potential incidents, any attempt to take into consideration the technical procedures required to remediate each incident would be incomplete. For that reason, this document does not attempt to outline the technical procedures associated with incident handling. The Incident Handling Plan provides a methodology or framework within which University of Connecticut incident handlers can work to ensure a complete and consistent approach to incident response.
The University Incident Response Plan is designed to assist in handling security events and is not intended to address scenarios for which standard processes are in place.
This document is primarily for University departmental information security contacts and systems administrators with direct involvement in the identification and resolution of security incidents on the systems, data, and applications which they manage.
University management may also be interested in the document in order to plan for and understand the methods and processes used to remediate security incidents within their scope of responsibility.
The following terms are used throughout the Incident Response Plan:
Departments and Contacts Definitions
|Administrator||A University service provider charged with managing information technology resources.|
|User||An individual who uses an information technology resource or service.|
|ISO||Information Security Office: The central University Information Security Office.|
|CISO||Chief Information Security Officer for the University: The director of the Information Security Office.|
|UCIRT||UConn Computer Incident Response Team: A team of subject matter experts assembled to respond to an incident and implement the Incident Response Plan.|
|ISC||Information Security Contact: An individual responsible for the support and/or maintenance of an information technology resource.|
|Compromised Computer||Any computing source whose confidentiality, integrity or availability has been adversely impacted, either intentionally or unintentionally, by an untrusted source. A compromise can occur either through manual interaction by the untrusted source or through automation.|
|Event||Any observable occurrence within an information technology resource.|
|Incident||Any event, successful or unsuccessful, that has the potential to negatively impact the confidentiality, availability, or integrity of any UConn IT resource.|
|Incident Response||An action plan for handling the misuse of Information Technology Resources.|
Incident Response Plan
The University’s Incident Response Plan is documented to provide a well-defined, consistent, and organized approach for handling security incidents, as well as taking appropriate action when an incident at an external organization is traced back to and reported to the University. The plan identifies and describes the roles and responsibilities of the UConn Computer Incident Response Team (UCIRT), which is responsible for activating the Incident Response Plan.
The UConn Computer Incident Response Team (UCIRT), is led by the Information Security Officer (CISO) or a designee named by the CISO. The mission of UCIRT is to provide an immediate, effective, and skillful response to any unexpected incident with information security implications (i.e., negatively impacting the confidentiality, integrity, or availability of University systems or data). The UCIRT is expected to follow the Incident Response Plan and is authorized to take appropriate steps to contain and remediate an incident.
UCIRT members will be convened as necessary based on the incident scope and severity.
UCIRT Roles and Responsibilities
UCIRT – Executive Representation
- Provides preparedness resources for UCIRT to respond to security incidents.
- Coordinates UCIRT assignment and response to High-Risk incidents.
- Determines if production services should be taken offline until incident resolution.
- Enacts University Security Breach Protocol when appropriate.
- Manages the incident Lessons Learned process.
UCIRT – CISO
- Responds and directly handles High-Risk incidents.
- Classifies High-Risk incidents according to the Incident Severity Classification Guidelines.
- Provides proper training to UCIRT on incident handling.
- Manages necessary communication between the UCIRT, law enforcement, and the Connecticut Education Network (CEN).
- Ensures appropriate evidence gathering, chain of custody, and preservation of information/evidence by UCIRT.
- Prepares a written summary of the incident, including corrective actions taken.
UCIRT – Information Security Contacts (ISC)
- Performs initial incident classification as High-Risk or Low-Risk.
- Escalates all High-Risk incidents to the CISO.
- Collects/preserves pertinent information regarding the incident.
- Works to contain, remediate, resolve, and document security incidents.
- Determines if localized production services should be taken offline until incident resolution.
UCIRT – Functional Representation
- Manages necessary communication between the University, public, and media.
- Provides specific expertise to:
- Assist with proper evidence handling.
- Ensure compliance with state and federal laws.
- Ensure compliance with University policy.
- Manage disciplinary actions for incidents involving University staff or students.
- Implement controls specified by Data Owners and monitors systems for signs of attack or unauthorized/inappropriate access.
- Provide physical and procedural safeguards for information resources.
- Performs regular system maintenance and monitoring.
- Reports unexpected events to ISC, which may lead to incident handling.
- Collects pertinent information regarding the incident at the request of the ISC.
- Provides background information on events which may help UCIRT and CISO understand the cause of an incident.
Reporting and Notification
The CISO is the central point of contact for reporting incidents. There are several methods available for reporting incidents, listed in Appendix C. The CISO will be notified of all High-Risk incidents. If the CISO is not available, the CIO or another delegate will be notified.
An analysis of the incident will take place by the CISO to determine whether UCIRT activation is necessary and determine the appropriate personnel involvement. The CISO will also prioritize incident response in the event multiple incidents require handling.
Communication security incidents must be treated on a ‘need to know’ basis. Individuals who are not directly involved in the handling of the incident must not be given information about the existence of the incident or the methods used to contain or remediate the incident.
Low-Risk incidents should be recorded, either initially or upon resolution, in the ServiceIT system.
High-Risk incidents must be recorded initially and updated throughout the incident response process.
Documentation of actions performed is expected throughout the incident handling process and is expected for all incidents. Incident handlers must record all steps performed and all changes made to production systems and observations.
All documentation should be sequential and time/date-stamped, and should include exact commands entered into systems, results of commands, actions taken (e.g., logging on, disabling accounts, applying router filters, etc.) as well as observations about the system and/or incident.
Documentation should occur as the incident is being handled, not after. All documentation should be provided to the CISO upon incident resolution. A sample Incident Handler Log Template is provided in Appendix D. A list of questions that should be considered for an incident report is provided in Appendix F.
Incident Handling Details
Although technical procedures vary depending on the categorization and type of incident, each incident must include the following six (6) phases:
- Preparation: Ready the UCIRT to handle incidents.
- Detection: Gather and analyze events; determine the existence of a threat and the impact to confidentiality, availability, or integrity of a UConn IT resource.
- Containment: Stop the damage from attackers and preserve evidence.
- Remediation: Remove artifacts left from attacker.
- Resolution: Return systems to production and monitor.
- Closure and lessons learned: Document findings and implement lessons learned to improve operations and/or incident handling.
Based on the investigation, it may be necessary to repeat some of the phases; however, once an incident is detected the process should be followed to completion.
Phase 1: Preparation
The Preparation phase involves readying the UCIRT to handle incidents. Some required elements for incident handling are indicated below:
Preparation should be done at regular intervals prior an actual incident occurring.
Phase 2: Detection
Incident detection occurs internally in all areas and at all levels of the University, as well as externally, through reports from non-University incident handlers. All High-Risk incidents should immediately be reported to CISO once detected.
Administrators and users must be familiar with their systems to determine if an event constitutes an incident. Effective incident detection occurs when:
- The administrator or user is familiar with normal operations.
- Systems are equipped with effective auditing and logging tools.
- Administrators review systems and logs to identify deviations from normal operations.
Security contacts must analyze all available information in order to understand the scope of an incident and effectively contain and remediate the incident. The incident must be fully diagnosed prior to beginning subsequent phases of the Incident Response Plan.
Phase 3: Containment
The first priority of UCIRT, in every incident, is to contain the incident as quickly as possible. An incident is considered contained when no additional harm can be caused and the incident handler is able to focus on remediation. Containment consists of three stages:
- Short-term containment: stopping the progress of the incident or attacker.
- Information gathering.
- Long-term containment: making changes to the production system.
Phase 4: Remediation
The goal of the Remediation phase is to clean up a system and remove any artifacts (e.g., rootkits) left from the attacker. During the Remediation phase, the UCIRT team must also determine and document the cause and symptoms of the incident: isolating the attack based on information gathered during the detection phase, and determining how the attack was executed.
Phase 5: Resolution
During the Resolution phase, the UCIRT restores normal business operations. It is critical to carefully handle incident Resolution and verify system performance and security before being brought back online. Tests must be completed and baseline system activity (gathered in the Preparation phase) must be compared to ensure the system is verified before operations are restored.
Phase 6: Closure and Lessons Learned
In the Closure and Lessons Learned phase, the CISO documents findings from the incident and the handling of the incident is reviewed by the UCIRT. The expected outcome of this phase is improved operations and improved incident response procedures.
Step-By-Step Incident Handling Procedures
The following is the process to follow once an incident is suspected.
- Administrators or Users notify their Information Security Contact (ISC) upon discovery of potential incident.
- ISC confirms the incident.
- ISC classifies the incident based on criteria in Appendix B.
- ISC escalates any High-Risk incidents to be handled by the Information Security Office.
- ISC continues through the Incident Response Document to assist in handling any Low-Risk incidents.
- Begin the documentation process.
- Communicate incident to department management as appropriate.
- Take necessary steps to prevent incident from spreading.
- Document containment steps.
- Determine incident cause based on information gathered during the detection phase.
- Determine how attack was executed.
- Remove threat.
- Perform a vulnerability assessment and remediate vulnerabilities.
- Return systems to trusted state.
- Compare system against original baseline gathered during preparation phase.
- Business units test the service/system to verify functionality.
- Restore system to production environment.
- Perform ongoing system monitoring to ensure system integrity and detect incident recurrence.
- Finalize incident handling documentation.
- Email documentation and incident description to university incident handling system.
Appendix A: Incident Handling Contacts
|Name||Department||Phone#||Cell Phone#||Email Address|
|Jason Pufahl (CISO)||ITS Information Securityfirstname.lastname@example.org|
|Mike Lang||ITS Information Securityemail@example.com|
|Paul Desmarais||ITS Information Securityfirstname.lastname@example.org|
|Ian Rogers||ITS Information Security||860-486-7184||Ian.email@example.com|
|Name||Title||Phone#||Cell Phone#||Email Address|
|Jason Pufahl||Chief Information Security Officer||860-486-3743||860-420-9897||Jason.firstname.lastname@example.org|
Appendix B: Incident Severity Classification Guidelines
Upon detection incidents will be classified as one of two classes by members of UCIRT:
- Low-Risk Incident
- High-Risk Incident
Incidents which meet any of the following criteria will be considered High-Risk Incidents:
- There is a reasonable expectation that Protected or Confidential Data was accessible to unauthorized individuals as a result of the incident (during the initial classification phase it is not necessary to determine whether or not confidential data was actually accessed).
- There is a reasonable expectation that the incident has or may result in financial theft or loss of intellectual property.
- There is a possibility that the incident has or could result in compromise of additional University systems or data.
- There is a possibility that physical harm could result to any person or to University property as a result of the incident.
- There is a possibility that the incident could affect the availability of University or department mission-critical infrastructure, systems, applications, or data.
- The data or systems involved in the incident are impacted by state or federal regulation, grants, or University policy.
Incidents which do not meet any of the High-Risk Incident criteria should be considered Low-Risk Incidents and handled using the Step-By-Step Incident Handling Procedures.
Appendix C: Incident Reporting Methods
Any of the following resources may be used to report an incident for investigation and remediation by the UCIRT.
- (860)486-4357 (HELP), option #3: The ITS Help Center
- (860)486-8255: Security Incident Report Line
- (888)685-2637: Office of Audit, Compliance and Ethics Anonymous Reportline
- (860)486-4526: Office of Audit, Compliance and Ethics
- (860)486-4800: UConn Police Department
- A phone call to any member of the CISO
Appendix D: Incident Handler Log Template
Appendix E: Incident Response Quick Reference Guide
Appendix F: Incident Report Content
- Executive Summary
- Include overview of the incident.
- Include Risk Level (High, Low).
- Determine if compromise has been contained.
- Initial Analysis.
- Investigative Procedures.
- Individual(s) performing investigation.
- Include forensic tools used during investigation.
- Identify ALL systems analyzed.
- Domain Name System (DNS) names.
- Internet Protocol (IP) addresses.
- Operating System (OS) version.
- Established how and source of compromise.
- Function of system(s)
- Function of system(s).
- Timeframe of compromise.
- Any data exported by intruder.
- Remediation steps taken.
Last Revision Date: 09/03/15
Document Release History
|02/15/10||Jason Pufahl/Mick DiGrazia||Initial Document|
|06/2/14||Jason Pufahl||Review and Minor Revisions|
|09/03/15||Jason Pufahl||Review and Minor Revisions|
Document Ownership and Approvals
The University IT Security Office has responsibility for the Incident Response Plan and is thereby responsible for its maintenance and future revisions.
All revisions to this document require the explicit approval of the CISO of the University of Connecticut.
This document will be reviewed annually to ensure its applicability to the current University environment and to address the changing technologies, organization, and needs of the University.
Furthermore, upon resolution of High-Risk security incidents, the Incident Response Plan should be reviewed to determine if the plan can be revised to help provide improved incident response in the future.