University Incident Response
Policy and Procedures
Index: SOP-1001
DRAFT
William L. Custer
Information Security Policy Manager
Revision E: 1/18/2005
106752710
3/7/2016 10:49:10 PM
Page 1 of 10
“… documented incident response procedures are among the most critical elements of an
effective security program.” Ed Skoudis
106752710
3/7/2016 10:49:10 PM
Page 2 of 10
Abstract
Policy Statement
Critical incidents will occur that require full participation of IT technical personnel as well as divisional leadership
to properly manage the outcome. To accomplish this IT Services will establish a critical incident response
procedures that will ensure appropriate leadership and technical resources are involved to (i) assess of the
seriousness of an incident, (ii) assess the extent of damage, (iii) identify the vulnerability created and (iv) estimate
what additional resources are required to mitigate the incident. It will also ensure that proper follow-up reporting
occurs and that procedures are adjusted so that responses to future incidents are improved.
Summary of Responsibilities
CIO
 Communicate status of critical incidents to the PEC
 Forward briefings to University Communications
IT Services Management
 Distribute Critical Incident Response Policy
Incident Response Working Group (IRWG)
 Assist in development and promotion of policy and procedures
 Select and train incident response team members and coordinators
 Develop a representative inventory of critical incidents
 Declare a critical incident and form a CIRT
Critical Incident Coordinator (CIC)
 Declare a critical incident if it is on the inventory and form a CIRT from a pool of trained members
 Communicate to IT Services Leadership that an incident has been declared and a CIRT formed
Critical Incident Response Team (CIRT)
 Follow the leadership of the CIC
 Develop a plan and
Supporting Groups
 Provide technical and other assistance to CIRT as requested

106752710
3/7/2016 10:49:10 PM
Page 3 of 10
Table of Contents
Section
Page #
1. Introduction ...............................................................................................................................................................5
2. Statement of management commitment.....................................................................................................................5
3. Purpose and objectives of this policy ........................................................................................................................5
4. Scope of this policy ...................................................................................................................................................5
A. This policy applies to University Information Technology Services and all system and services for which it is
responsible. ...............................................................................................................................................................5
B. Nothing in this Incident Response Policy and Procedures document should be taken to be in conflict with the
following higher level policies: ................................................................................................................................5
C. These policies and procedures specifically exclude the following: .....................................................................6
5. Definition of critical incidents and their consequences within the context of the University ....................................6
6. Definition of Appropriate Response to Critical Incidents .........................................................................................6
7. Organizational structure and delineation of roles, responsibilities and levels of authority. .......................................7
A. Incident Response Working Group ......................................................................................................................7
B. Critical Incident Response Team (CIRT) .............................................................................................................7
C. Critical Incident Coordinator (CIC) .....................................................................................................................7
8. Types of Incidents .....................................................................................................................................................7
9. Prioritization or severity rating of incidents ..............................................................................................................7
10. Performance measures ............................................................................................................................................7
11. Reporting and contact forms ...................................................................................................................................8
I. Appendices ................................................................................................................................................................9
II. Glossary ....................................................................................................................................................................9
III. Diagrams................................................................................................................................................................ 10
IV. Bibliography .......................................................................................................................................................... 10
V. Index ....................................................................................................................................................................... 10
106752710
3/7/2016 10:49:10 PM
Page 4 of 10
1. Introduction
A rapid response to incidents that threaten the confidentiality, integrity, and availability of university information
assets, information systems, and the networks that deliver the information, is required to protect those assets.
Without a rapid response, those assets could be compromised and the University could be in violation of Federal,
State, and Local statutes, in violation of its own stated policies, and in violation of trust endowed by its constituents.
Rapid incident response that is consistently applied requires planning to identify clear location of responsibility,
decision points, clear action items and communication channels.
The following advantages will result from a well-conceived plan of response to incidents of this nature (from
Vangelos in Krause and Tipton 2003 Chapter xx):
 Following a predefined plan of action during the confusion of an incident can minimize damage
 Policy decisions made in advance rather than in the heat of the moment will be superior
 Details likely to be overlooked can be documented in the plan
 Non-technical business areas who must also prepare for an incident can give advanced input to the plan
 A plan can communicate the potential consequences of an incident to senior management and garner support
Perhaps the most significant advantage of having an incident response plan is to integrate its policies and procedures
tightly into the overall information security plan, into higher level policy, and related to risk assessment. To quickly
respond to unexpected technical events or incidents, the University’s IT Services department of necessity switches
from a supporting role to a diagnostic and response role based on the Policies and Procedures in this document.
2. Statement of management commitment
The Strategic Plan for Information Technology Services identified improvement of Information Security as a
strategic goal. Management of Information Systems and Services has identified improvement of Incident Response
as a strategic task for attention.
3. Purpose and objectives of this policy
The purpose of these policies and procedures is to provide the basis of appropriate response to incidents that threaten
the confidentiality, integrity, and availability of university information assets, information systems, and the networks
that deliver the information. These policies and procedures underlie the establishment and ongoing deployment of
trained critical incident response teams, formed with the purpose of managing the afore mentioned incidents at the
University. This effort is being taken to improve the response time to incidents, to provide consistent response, and
improve incident reporting.
4. Scope of this policy
A. This policy applies to University Information Technology Services and all system and services for which it is
responsible.
B. Nothing in this Incident Response Policy and Procedures document should be taken to be in conflict with the
following higher level policies:




University Computing Security Policy
Responsible Use Policy
GLB Information Security Plan
Memoranda from the University Counsel
106752710
3/7/2016 10:49:10 PM
Page 5 of 10
C. These policies and procedures specifically exclude the following:




Non-electronic information including paper mail.
Copier and fax.
Physical security.
Contingency planning, business continuity and disaster recovery. Disaster’s are governed by a different set of
policies and declared by a different governing body than Critical Incidents. An event may initially be declared
a ‘Critical Incident’ and subsequently declared to be a ‘Disaster’ by the appropriate body. In this case, a critical
incident response team would be subsumed into the Disaster Recovery process.
5. Definition of critical incidents and their consequences within the context of the University
An incident is any adverse event that threatens the confidentiality, integrity, or availability of university information
assets, information systems, and the networks that deliver the information. Any violation of computer security
policies, acceptable use policies, or standard computer security practices is an incident.
Adverse events may include, denial-of-service attacks, loss of accountability, or damage to any part of the system.
Examples include the insertion of malicious code (e.g. viruses, Trojan horses, or backdoors), unauthorized scans or
probes, successful and unsuccessful intrusions, and insider attacks. See Vangelos.
Incidents as defined above vary in their impact on the University and in the degree of threat they pose; consequently
not all incidents require the same response. Incidents with high impact and high threat involve high risk and great
vulnerability to the University; such high risk incidents are called ‘critical incidents’ and require that a Critical
Incident Response Team (CIRT) be assembled to apply appropriate response. Non-critical incidents are incidents
with either low or acceptable risk. (See chart in Appendix on threat, impact, risk and vulnerability). CIRT and
appropriate response are defined further below.
Non-critical incidents also have appropriate response; however procedures for non-critical incidents are not outlined
in this policy.
An incident is declared to be critical and a CIRT assembled in one of the following ways:
 A member of the Incident Response Steering Team declares it to be critical.
 Critical Incident Coordinator declares it to be critical.
 An appropriate University official declares to be critical.
 NOC staff declares it to be critical because the incident is on a list of critical incidents approved by the Incident
Response Steering Team. See Appendix for this list (to be developed).
6. Definition of Appropriate Response to Critical Incidents
The following items define appropriate response of a CIRT to a critical incident.














Determine if an incident has occurred and the extent of the incident
Select which CIRT members should respond
Assume control of the incident and involve appropriate personnel, as conditions require
Report to management for the decision on how to proceed
Begin interviews
Contain the incident before it spreads
Collect s much accurate and timely information as possible
Preserve evidence
Protect the rights of clients, employees, and others, as established by law, regulations, and policies
Establish controls for the proper collection and handling of evidence
Initiate a chain of custody of evidence
Minimize business interruptions within the organization
Document all actions and results
Creates a communication plan and data sheets for use by IT Services Senior Management
106752710
3/7/2016 10:49:10 PM
Page 6 of 10
 Restore the system
 Conduct a post-incident critique
 Revise response as require
Primarily from Alan Sterneckert, “Incident Response Management”.
7. Organizational structure and delineation of roles, responsibilities and levels of authority.
A. Incident Response Working Group
The Incident Response Working group is the Incident Response Team’s steering committee. They are charged with
establishing the basic policies and procedures which will be employed by the Incident Response Team and may be
called upon to oversee team activities. This group selects the pool of Critical Incident Coordinators and Critical
Incident Response Team members.
B. Critical Incident Response Team (CIRT)
The Critical Incident Response Team (CIRT) is a group of individuals who have been trained in Incident
management, each having distinct response roles. The CIRT works under the direction of the Critical Incident
Coordinator.
C. Critical Incident Coordinator (CIC)
The Critical Incident Coordinator is an individual who is selected to oversee and direct the Critical Incident
Response Team actions as well as to act as the single point of contact for the given incident. The Critical Incident
Coordinator will typically also be responsible for ensuring that specific information is communicated to
management in a timely fashion
8. Types of Incidents
Each incident presents a different problem with regard to identification and response determination. Here is a
sampling of incident types.







Unauthorized entry / Breach
Denial of Service
Malicious code or virus
Inappropriate use
Networking system failures (widespread)
Application or Database failures (widespread)
Multiple types
9. Prioritization or severity rating of incidents
In addition to identifying the type of incident that is underway, it is also important to understand the potential
severity of the incident as well.



Severity 1 – Critical systems
Severity 2 – User system
Severity 3 – Background system, non-critical
10. Performance measures


Response times for Severity 1 incidents
Response times for Severity 2 incidents
106752710
3/7/2016 10:49:10 PM
Page 7 of 10

Response times for Severity 3 incidents
11. Reporting and contact forms
A. Types of reports




Incident declaration
Incident status update
Incident closure and end of recovery
Incident Review
B. Incident Declaration
 Is prepared by a Critical Incident Coordinator
 Specifies the criteria by which the incident was declared critical
 Is communicated to the IT Services senior management as well as to the Incident Response Working Group
C. Incident Status Update Report
D. Incident Closure and End of Recovery Report
E. Incident Review Report
Preparation
• Were controls applicable to the specific incident working properly?
• What conditions allowed the incident to occur?
• Could more education of users or administrators have prevented the incident?
• Were all of the people necessary to respond to the incident familiar with the incident response plan?
• Were any actions that required management approval clear to participants throughout the incident?
Detection
• How soon after the incident started did the organization detect it?
• Could different or better logging have enabled the organization to detect the incident sooner?
• Does the organization even know exactly when the incident started?
• How smooth was the process of invoking the incident response plan?
• Were appropriate individuals outside of the incident response team notified?
• How well did the organization follow the plan?
• Were the appropriate people available when the response team was called?
• Should there have been communication to inside and outside parties at this time; and if so, was it done?
• Did all communication flow from the appropriate source?
Containment
• How well was the incident contained?
• Did the available staff have sufficient skills to do an effective job of containment?
• If there were decisions on whether to disrupt service to internal or external customers, were they made by
the appropriate people?
• Are there changes that could be made to the environment that would have made containment easier or
faster?
• Did technical staff document all of their activities?
Eradication and Recovery
• Was the recovery complete — was any data permanently lost?
• If the recovery involved multiple servers, users, networks, etc., how were decisions made on the relative
priorities, and did the decision process follow the incident response plan?
• Were the technical processes used during these phases smooth?
• Was staff available with the necessary background and skills?
106752710
3/7/2016 10:49:10 PM
Page 8 of 10
I. Appendices
Appendix A – Approved list of critical incidents
II. Glossary
The following terms are defined:
Confidentiality. “Confidentiality provides the ability to ensure that the necessary level of secrecy is enforced at each
junction of data processing and prevention of unauthorized disclosure. This level of confidentiality should prevail
while data resides on systems and devices within the network, as it is transmitted, and once it reaches its
destination.” Harris 2003, p. 55
Integrity. “Integrity is upheld when the assurance of accuracy and reliability of information and systems is
provided, and unauthorized modification of data is prevented.” Harris 2003, p. 55.
Availability. “Systems and networks should provide adequate capacity in order to perform in a predictable manner
with an acceptable level of performance.” Harris 2003, p. 54.
Vulnerability. Vulnerability is a software, hardware, or procedural weakness that may provide an attacker the open
door he is looking for to enter a computer or network and have unauthorized access to resources within the
environment. Vulnerability characterizes the absence or weakness of a safeguard that could be exploited.
Threat. A threat is any potential danger to information systems. The threat is that someone or something will
identify a specific vulnerability and use it against the organization or individual.
Risk. A risk is the likelihood of a threat agent taking advantage of vulnerability. A risk is the possibility and
probability that a threat agent will exploit vulnerability.
Exposure. An exposure is an instance of being exposed to losses from a threat agent. Vulnerability can cause an
organization to be exposed to possible damages.
Countermeasure. A countermeasure, or safeguard, mitigates a potential risk. A countermeasure is a software
configuration, hardware, or procedure that eliminates vulnerability or reduces the risk of a threat agent from being
able to exploit a vulnerability.
106752710
3/7/2016 10:49:10 PM
Page 9 of 10
III. Diagrams
IV. Bibliography
Hare, Chris. “CIRT: Responding to Attack”. In Information Security Management Handbook, edited by Harold F.
Tipton and Micki Krause. Auerbach, 2003
Harris, Shon. All In One CISSP Certification. Second Edition. McGraw-Hill, 2003.
Shaurette, Ken M. “The Building Blocks of Information Security”. In Information Security Management
Handbook, edited by Harold F. Tipton and Micki Krause. 4 th ed, Vol II. Auerbach, 2001.
Skoudis, Ed. “Hacker Tools and Techniques”. In Information Security Management Handbook, edited by Harold F.
Tipton and Micki Krause. 4th ed, Vol II. Auerbach, 2001.
Sterneckert, Alan B. “Incident Response Management”. In Information Security Management Handbook, edited by
Harold F. Tipton and Micki Krause. Auerbach, 2003
Vangelos, Michael. “Managing the Response to a Computer Security Incident”. In Information Security
Management Handbook, edited by Harold F. Tipton and Micki Krause. Auerbach, 2003.
V. Index
106752710
3/7/2016 10:49:10 PM
Page 10 of 10