http://www.securityfocus.

com/infocus/1467

How to Design a Useful Incident Response Policy
Timothy E. Wright 2001­10­02

How to Design a Useful Incident Response Policy 
by Timothy E. Wright 
last updated September 18, 2001 

Perhaps you're the Information Security Officer for your company. Or, maybe you're a technology auditor. Maybe you're in 
charge of data security for your university's computing department. Regardless of your title and circumstances, you've been 
working on implementing an information security program (you have been working on your program, right?!) Such an 
endeavor has a tremendous scope, requiring great feats of perception and planning. This article aims to help you with an 
important facet of any information security program: the incident response policy. 

Policy: Does Anybody Read This Stuff? 

Policy: lifeblood of bureaucrats! But does anyone actually read policy? In truth, any properly constructed information security 
policy can perform several worthwhile services. First, it acts as an informed guide for your organization's information 
activities: good policy can help an organization manage its security risks better. Next, it brings structure to chaos: sensible 
rules and recommendations, tailored to your organization, can resolve confusion about handling information under different 
circumstances. Finally, it streamlines activities in the face of a security issue. If people know what to do and when to do it, 
they will be able to protect their organization through decisive and correct responses. 

In addition to these pragmatic functions, there is, in fact, another benefit that good information security policy can perform. 
Good policy can demonstrate that an organization has thought through its information security needs, and has properly 
configured itself to meet these needs. In some instances, there may be a legal requirement for this! For example, the Gramm­
Leach­Bliley Act (GLB) states very clearly that "...each financial institution has an affirmative and continuing obligation to 
respect the privacy of its customers and to protect the security and confidentiality of those customers' nonpublic personal 
information." (In fact, GLB requires that financial institutions document and implement a full­blown information security 
program.) In other situations, an organization may have to present a cogent information security program in order to conduct 
business. 

Towards a Useful Policy 

Having established the reasons for devising information security policies, we can now consider the elements of truly useful 
policy. Good information security policy should be succinct, understandable, practicable, cooperative, and dynamic. Let's 
consider each of these in turn. 

Succinct 

By succinct, we mean that the policy should be clear and concise. It should be stated as briefly as possible without omitting 
any vital information. Long winded policies are more difficult to understand, less likely to be read, and harder to implement. 

Understandable 

When we say a good policy is understandable we mean that the policy's text actually makes sense within the context of the 
organization. As the aphorism from the world of business an aphorism states, there are two types of people: those who don't 
manage what they understand, and those who don't understand what they manage. 

In the realm of information security, sense can only be achieved if the person writing the policies has a grasp of information 
security concepts as well as their organization's structure and purpose. 

Practicable 
Regardless of how succinct and understandable a policy might be, if it isn't possible to practice it's worthless. A great example 
of this issue would be the implementation of a policy prohibiting the connection of modems to server machines in an 
organization that has a service contract in place whereby a software vendor must dial into a server to do maintenance. An 
example related to incident response might be a policy stating that members of a response team have to be reachable 24 hours 
a day, even though no reliable means of contact is provided by the company except when the members are at work. Policies 
that aren't practicable are not only, by definition, ineffective, they are also quickly ignored by an organization's employees. 

Cooperative 

A good information security policy is cooperative in that it is crafted and maintained with the input of all relevant departments 
within an organization. In general, information security can only succeed when everyone participates. Where incident response 
is concerned, departments such as Legal, Human Resources, Public Relations, Audit, and Information Technology all have to 
contribute to the creation and review of policy documentation. During an incident response it's very likely that some or all of 
these departments will play a significant role in the management of the situation. If relevant departments haven't given their 
endorsement for a policy, the policy is sure to experience problems during implementation. 

Dynamic 

Finally, any useful information security policy is dynamic in that it is capable of changing and growing with an organization. 
The rate at which technology changes is immense. And while organizations may or may not keep pace with this, they 
inevitably must make changes and minor course corrections as a result of the technologies they deploy. It would be negligent to 
create an information security policy and believe that the needs it serves today will be adequate in the long run. 

Incident Response: Where the Rubber Meets the Road in the Information Security Program 

Much of an organization's information security program is passive. Policies that prescribe how systems are to be used, 
passwords to be managed, and system audit activities to take place are all designed to prevent something bad from happening. 
In contrast, items like disaster recovery and incident response are entirely action oriented. In fact, in many ways, responding to 
an incident is similar to responding to a disaster: money, public relations, and time are all considerations. Of course, for 
incident response, the level of success is inversely proportional to the degree of public relations exposure. 

No organization wants to appear as though they have a weak information security posture. Such an appearance can tarnish the 
corporate image, precipitate law suits, attract unwanted hacker attention, and damage good will. Yet, there is no such thing as 
fool­proof security: sooner or later, all organizations must respond to a security incident. The speed and decisiveness with 
which an organization can mount its response will determine whether or not a serious incident turns into a nightmare. If the 
response is methodical and well orchestrated, invariably the incident will be controllable. 

A poor response capability equals financial and public relations trouble. How is this risk managed? By devising an effective 
incident response policy from the outset. Such a policy's documentation will consist of the following sections: background, 
definitions, incident classification, reporting, business continuity, process flow, and example incidents. 

Background 

All policies need to have a background section in order to explain the motivation and purpose driving the policy. For incident 
response the objective is somewhat obvious: to adequately respond to electronic incidents that take place within an 
organization's purview. This background not only identifies the objectives of the incident response policy, it provides the 
context within which those objectives will be met. 

Definitions 

Here, the policy will need to define exactly what an electronic incident is. Are we talking about computer fraud and computer 
abuse (the difference being that computer fraud is a crime whereas computer abuse is a policy violation)? What about 
incidents that are accidental on the part of the organization or a vendor? Does this type of activity warrant an incident response 
or something more low­key? Unfortunately, this article cannot answer these questions, since the answers will be contingent 
upon your organization's goals and priorities. A good tip, however, would be to carefully read through any regulations (e.g. 
GLB, FERPA, etc.) that apply to you and grasp the totality of what they are requiring. 
Another item that requires definition is that of the Computer Emergency Response Team (CERT). An incident response policy 
won't be practicable unless there is someone who puts that policy into action during an incident. The CERT must be a highly 
skilled and available group. Members should represent expertise within the various information systems belonging to an 
organization, be on call twenty­four hours a day, and be capable of responding within a nominal amount of time. There should 
be backup available for when members are out of town or on vacation. Members of the CERT need to be familiar with the 
fundamentals of gathering and handling computer evidence. 

Incident Classification 

To be effective in managing its incident response process, an organization should create an event classification system. Such a 
system will enable the filtering of background noise from items that are more serious: for example, does an organization really 
need to respond to every port scan. One effective approach is to assign events a degree of urgency and then further assign a 
priority ranking to anything of high urgency. Incidents that fall into the low and medium urgency classes may be logged, with 
medium events being examined later on by a system administrator. High urgency events would be treated immediately. This 
response would require the attention of other relevant departments and groups. 

An escalation list should be used for all incidents. Such a list designates responsibilities for incidents in which the degree of 
urgency increases as the incident progresses. As an event increases in urgency and priority, an appropriate individual further 
up the escalation list is contacted. Ultimately, for incidents of the highest urgency and priority, the CERT is activated. 

As an incident escalates, it is likely that departments other than network administration will need to become involved. 
Executive management will have to be very careful to not hamper the CERT's ability to do its job (e.g. by assigning it 
unreasonable or time consuming chores). The Legal and Public Relations departments may also need to become involved. If 
the situation warrants it, executive management should be prepared to contact law enforcement. 

Note that an organization's information system vendors should be included on the escalation list. In particular, relevant vendors 
should provide a twenty­four hour contact and be given such a contact at the organization. It is also recommended that some 
type of information security service level agreement be included in any contract between an organization and its vendors. 

Reporting 

Before, during, and after an electronic incident, various kinds of data will be gathered. How will these data be processed, and 
to whom will they be presented? Very little beyond intrusion detection system and server audit logs will be available for 
reporting during normal business operations. However, when an incident is being managed there is a great potential for 
additional information. For example evidence that might be collected, additional log data, and documentation of the incident 
can all contribute to the data available. After an incident has passed there will no doubt be new information pertaining to the 
aftermath: what the incident has cost the organization, what resources will be needed to fully recover, etc. It's important for the 
incident response policy to outline when reports are generated, what they will contain, and to whom they will be made 
available. 

Business Continuity 

A crucial element to consider in a useful incident response policy is that of business continuity. In the event that a serious 
incident should take place, a decision to halt certain information systems may need to be made. For example, during a denial of 
service attack it may be better to undergo a self­imposed service outage rather than wait for an overwhelming flood of service 
requests. Who should be responsible for determining when to pull the plug on a service, and under what circumstances is this 
an option? This needs to be set out in the Incident Response Policy. The converse is also of importance: who should be allowed 
to re­enable a service, and under what circumstances? As with other difficult policy questions, answers will vary from 
organization to organization. 

Process Flow 

Now we come to the heart of the incident response policy; it is within the process flow that the steps for response are outlined. 
The flow should start wherever an incident comes into being, and then trace the incident via the classification system up to the 
point where the CERT and other departments are notified. It's a good idea to use both a written description and diagram to 
describe the incident response process. Also, be sure to include a means for dealing with incident response at a vendor's site. 
Here is a very simplistic process flow that follows the classification system discussed above. 
Example Incidents 

The last element to be included in a useful information security policy is a table of example incidents and responses. The 
concept here is to provide sample incidents of varying degrees of nastiness, along with brief response summaries. The effect of 
such a table is two­fold. First, it will help you to think through the application of your response policy in a variety of situations. 
This is a great way to search for inadequacies within a policy's process. Second, a table of examples will anchor an incident 
response policy to the real world. It will allow an organization to better comprehend why the policy is needed. 

Conclusion 

By now, Information Security has become part and parcel of most organizations' business processes. This entails the 
development and deployment of useful policies to control and monitor information systems, and respond to electronic 
incidents. Without an incident response policy an organization will be unable to properly respond to an information security 
event. This can lead to a loss of money, bad public relations, and even additional security risks. The ingredients of a useful 
incident response policy include the following components: background, definitions, incident classification, reporting, 
business continuity, process flow, and example incidents. 
http://www.datasecuritypolicies.com/tag/incident-response-policy

Sample Incident Response Policy
Cynthia Bonnette, the Director of Information Security Risk Assessment for NETBankAudit in Arlington, VA wrote a sample 
incident response policy which appeared in this issue of the AML Compliance Alert here.

Here’s an exerpt:

INCIDENT IDENTIFICATION, CLASSIFICATION AND ESCALATION

Once detected, suspected incidents (e.g., anomalous activity) must be reported. The nature and severity of the incident will 
determine the appropriate response strategy. The Information Security Officer (ISO) or Security Officer classifies the threat 
severity based on the definitions below. The ISO or Security Officer is also responsible for determining when to escalate or 
downgrade the severity level of an incident based on changes in circumstances and the discovery of additional information.

Severity levels are as follows:

High. A high level event is an event that can cause significant damage, corruption, or loss (compromise) of confidential, 
critical and/or strategic bank and customer information. The event can result in potential damage and liability to the bank and 
to its public image and may degrade customer confidence concerning the bank’s products and services (e.g., online banking). 
Examples: computer intrusions, compromise of critical information, widespread virus infection, attacks against the IT 
infrastructure (e.g., domain name servers, firewalls and backup systems) and denial­of­service attacks that disable a critical 
service or impede business performance.

Medium. A medium level event is an event that may cause damage, corruption, or loss of replaceable information without 
compromise or may have a moderate impact on the bank.s operations or reputation. Examples: misuse or abuse of authorized 
access, accidental intrusion, confined virus infection, unusual system performance or behavior, system crashes, installation of 
unauthorized software, unexplained access privilege changes or unusual after­hour activities.

Low. A low level event is an event that causes inconvenience, aggravation, and/or minor costs associated with recovery, 
unintentional actions at the user or administrator level, or unintentional damage or minor loss of recoverable information. The 
event will have little, if any, material impact on the bank.s operations or reputation. Examples: sharing of passwords, policy or 
procedural violations, and scans of bank systems (except online banking or investing systems, which are medium level events).

Worth looking at for a jump start on developing your own incident response policy. Check it out!
http://www.corrections.govt.nz/about-us/fact-sheets/managing-offenders/incident-
response-policy.html

Incident Response Policy

The Department of Corrections, through the Public Prisons Service (PPS), currently manages more than 6,000 offenders daily, 
at 20 locations throughout the country.
The Department contributes to a government key goal of safer communities by protecting the public and reducing re­offending. 
As part of protecting the public we need to provide as safe an environment as possible for our people, offenders and the public.
As part of its efforts towards achieving these goals, PPS has developed a National Incident Response Policy that identifies how 
incidents in prisons will be dealt with to ensure that the response brings the incident to a safe and swift conclusion, minimising 
the risk to life and damage to property.
Incident Response Policy Framework
Serious incidents in prisons are not common, but when they occur they have the potential to result in injuries to both staff and 
inmates, as well as damage to property. To ensure consistency and effectiveness in its response to serious incidents, PPS has 
developed an Incident Response Policy Framework.
This framework provides for:
A structure for incident response, including the level of resource which is applied to different incidents;
Different roles and responsibilities for incident response;
The establishment of an incident response capability, on an “as required” basis, to perform incident response functions; and
Each prison to develop and maintain emergency response plans to assist with the management of incidents and emergencies.
Incident response structure
PPS has adopted the Coordinated Incident Management System (CIMS) for managing incident response.
This international standard provides a framework for handling incident response, and is particularly useful when coordinating 
an incident response with other agencies (e.g. Police, Fire Service, Ambulance Service).
Each of the 20 prisons has developed comprehensive emergency response plans that outline how civil defence emergencies and 
critical incidents will be managed.
The emergency response plans are reviewed at least annually, and are developed based on best practice principles. The 
Department uses the SMEAC (Situation, Mission, Execution, Administration and Logistics, Command and Communication) 
format for the development of emergency plans.
Emergency plans are an important part of the Department’s requirement, under the Civil Defence Emergency Management Act 
2002, to continue essential functions to the optimum extent. PPS has developed a business continuity plan (BCP) for each 
prison to return the prison site to business as usual quickly and minimise risks during an emergency.
Clear roles and responsibilities for managing incidents/incident response
The PPS National Incident Response Policy has clear roles and responsibilities for managing incidents. These guidelines 
identify the different roles, and recognise that responsibilities will vary based on the type and seriousness of an incident.
A clear statement of role and responsibility will allow all staff to understand the authority for calling up, authorising 
deployment and managing the incident when an incident response is required.
Responding to incidents
The implementation of this policy (other than for low level incidents) involves mobilising suitably trained and equipped staff 
on an ‘as needed’ basis to respond to serious incidents. The policy uses rostered custodial staff who have received additional 
training to respond to incidents when and where required. This approach is similar to the New Zealand Police Armed Offenders 
Squads (AOS) where AOS members are part­time, drawn from all branches of the Police, and operate on a call­out basis.
Staff trained in incident response initiatives will be located at most of the 20 prison sites, and can provide support on a regional 
(and where required, national) basis. Specialist training includes negotiation skills, fire fighting and advanced first aid.
Comprehensive debriefs are conducted at the conclusion of an incident response. These debriefs are a good opportunity to 
review how the incident was managed, and utilise lessons learned for future incident responses.
Implementation of the Incident Response Policy has begun and will continue into 2005/06.
http://www.instantsecuritypolicy.com/defs-incident_response_policy.html

Incident Response Policy (aka Incident Response Plan)

The Incident Response Policy specifies exactly how the organization will respond in the event of suspected security incident. 
 This policy defines security incidents, both physical (such as the loss of a laptop) and electronic (a suspected attack or 
malware infection).  This policy includes preparation plans, response activities for different scenarios, and forensics/recovery 
based on your stated goals.  Incident Response Policies are required by a number of regulations and security standards.
An Incident Response Policy is clearly one of a company's most important policies, as it can reduce risk of a security incident 
as well as reduce data loss and speed recovery times in the event an incident were to occur.  Most importantly, an Incident 
Response Policy outlines roles, responsibilities, and actions to take in advance, so that these decisions don't need to be made 
during the stress of responding to a security incident.
An Incident Response Policy developed with the InstantSecurityPolicy.com application will include the following detailed 
sections:
1. Overview
2. Purpose
3. Scope
4. Policy
    4.1. Types of Incidents
        4.1.1. Electronic
        4.1.2. Physical
    4.2. Preparation
    4.3. Confidentiality
    4.4. Electronic Incidents
        4.4.1. Step­by­Step Response
    4.5. Physical Incidents
        4.5.1. Response
            4.5.1.1. If Loss Contained
            4.5.1.2. If Data Loss Suspected
    4.6. Notification
    4.7. Applicability of Other Policies
5. Enforcement
6. Definitions
7. Revision History
Available in the Silver and Gold Packages only, this is a policy that is intended to be used by technical staff and management 
only.
Your custom Incident Response Policy will be delivered immediately upon completion of the wizard via email, as both a PDF 
and an RTF file.   RTF files are editable in all major processing programs, including Microsoft Word.
Our security policies were written based on a cohesive and integrated approach using security best practices stemming from 
the C­I­A triad of confidentiality, integrity, and availability.  This approach aligns with both real­world and industry standard­
based objectives, resulting in an invaluable resource for your security policy management.  A Incident Response Policy 
developed with the InstantSecurityPolicy.com wizard will provide the foundation for a realistic, practical implementation of 
your IT security policy program.
http://www.evergreen.edu/policies/policy/biasincidentresponsepolicy

Bias Incident Response Policy

Category(ies)
Student Affairs

Approval(s)

President and Vice Presidents: October 31, 2005 Signature (pdf)

President and Vice Presidents: November 16, 2005 Signature (pdf)

Introduction
The reality for Evergreen students is that hate crimes and bias incidents can occur in their living communities, in their 
classrooms, at co­curricular activities, and in employment situations and at off campus college related activities. The College 
already has policies, procedures and protocols in place to respond to different kinds of incidents, enabling the college to attend 
to the health and safety of students, manage individual complaints or grievances, and adjudicate possible violations of college 
policies or local, state or federal laws. Examples of such policies, procedures, and protocols' include but are not limited to:
• Living communities — the housing contract, the Student Conduct Code and
the Peer Arbitration Board and the college Non-Discrimination Policy local,
state and federal civil rights laws and regulations

• Classrooms - program covenants, the Faculty Handbook, college Non-

Discrimination Policy, academic administrative policies and deans

• Co-curricular activities — the Student Conduct Code, college Non-

Discrimination Policy and local, state, and federal civil rights laws and
regulations

• Employment settings - student employment agreements, policies and

procedures, college Non-Discrimination Policy, local, state and federal civil
rights laws and regulations

• Case Coordinating Protocol

• Sexual Assault Protocol

Protocol for Bias Incidents

The following protocol is to ensure a timely, efficient, and effective response to campus incidents involving Evergreen students, 
which may be characterized as hate crimes or bias incidents. The protocol should be implemented whenever a hate crime or 
bias incident is believed or perceived to have occurred. This protocol is specific to addressing hate crimes or bias incidents 
directed at Evergreen students. The protocol does not cover faculty and staff. The protocol may apply in incidents off campus. 
This proposed interim protocol is not in lieu of and does not override established college or external processes and services 
available to students. 
Circumstances When the Protocol Is To Be Initiated
The bias incident protocol is initiated in cases of what may be a hate crime, bias incident, or when it is clear that the incident 
would have a serious impact on groups by virtue of their race, color, religion, ethnic/national origin, gender expression, sex, 
age, disability or sexual orientation identities. The purpose of convening the protocol response team is not to respond to more 
private incidents, especially when victims are uncomfortable with a public response, but rather to deal with more visible 
incidents that are likely to significantly affect the community.
A hate crime is an actual criminal offence motivated in whole or in part by the offender's bias towards the victim's status based 
on race, color, religion, ethnic/national origin, gender expression, sex, age, disability or sexual orientation identities.
A bias incident is conduct, speech or expression that is motivated by bias based on perceived race, color, religion, 
ethnic/national origin, gender expression, sex, age, disability or sexual orientation identities but does not rise to the level of a 
crime. To constitute a bias incident, sufficient objective facts must be present to lead a reasonable and prudent person to 
conclude that the actions in question may be motivated by bias toward the status of a targeted individual or a group.
The College has a zero tolerance for hate crimes and bias incidents and will act swiftly and effectively when such are reported. 
The College aspires to create an environment that is inclusive and safe for all students to learn. This protocol is specific to 
addressing hate crimes or bias incidents directed at Evergreen students identified as protected classes under the College's Non­
Discrimination Policy, local, state and federal civil rights laws and regulations. The College realizes the scope of the laws, 
policy and regulation extends to the abovementioned protected classes. Though socio economics status is not covered under 
existing laws and college policies, the College also recognizes, that students from lower socio economic groups may experience 
discrimination or bias.
Reporting of Bias Incidents
Students who experience or witness, and staff or faculty members who become aware of a possible hate crime or bias incident, 
are asked to report the crime or incident immediately to a designated college office or official:
• Vice President for Student Affairs 867-6296

• Police Services 867-6832

• Director of Housing and Food Services 867-6137

• Campus Grievance Officer 867-5113

• Dean of Student and Academic Support Services 867-6034

• Director of First Peoples' Advising Services 867-6467

• Civil Rights Officer 867-5371

• Provost Office 867-6400

• Academic Deans 867-6870

Notification of the report will then be made to the Office of the Vice President for Student Affairs. The Vice President will 
ensure that the complaint is investigated by the appropriate investigative official as well as convene the response team.
This protocol will be used 24 hours a day/7 days a week. During regular business hours, the Vice President for Student Affairs, 
the Dean of Student and Academic Support Services, Police Service, the Director of Housing and Food Services or Academic 
Dean Should be notified immediately of any incidents which have the potential to be characterized as hate crimes or bias 
incidents.
During evening and weekend hours, Police Services or housing staff will notify the Vice President for Student Affairs or the 
vice president's designee. In the case of incidents in the living community, Police Services or housing staff will first notify the 
Director of Housing and Food Service or the director's designee, who will then notify the Vice President for Student Affairs.
Procedural Steps
1. Front-line respondents to the incident should (a) assess and determine the
need for emergency services, which may include emergency medical or
psychological treatment; (b) determine if there continues to be a threat to
parties involved and provide appropriate protection to the targeted individual
or group through Police Services. A list of student affairs practitioners who can
be contacted to assist will be available in the Office of the Vice President for
Student Affairs and in the Police Services office.

2. Once an incident has been reported the Vice President for Student Affairs or
the vice president's designee will initiate the case-coordinating protocol. In
crises and emergencies the Division of Student Affairs activates the case-
coordinating protocol to ensure direct services and support to students in
 crisis. The case coordinator is a student affairs practitioner trained in crisis
management and emergencies. The coordinator assists the student(s) in
accessing campus and local support services and resources and intervenes or
facilitates in matters related to the student's(s') academic and personal well-
being. The case coordinator is assigned to the student(s) until the crisis is
resolved. When requested by the student(s), the case coordinator will
accompany the student(s) to appointments when appropriate, as well as
advise the student(s) regarding college policies. Students residing in the
residence halls are assigned a case coordinator by the Director of Housing
and Food Service, and students living off campus are assigned a case
coordinator by the Dean of Student and Academic Support Services.

3. A student affairs practitioner will be assigned to coordinate services for the

student(s) involved. The assigned coordinator will be responsible for
maintaining contact with the student(s) throughout the process, from the
initial crisis through subsequent periods as needed to address academic and
personal issues which may have developed as a result of the hate crime or
bias incident. If the student(s) shows any signs of being distraught, contact
with the counseling center or crisis center should be made immediately.
Based on interactions with the student(s) it may be determined appropriate to
assign case coordinators who may be from the individual's affinity group if
possible. If this is not possible, every effort should be made for the case
coordinator to identify who within the college community could assist as
additional support to the student(s).

4. Documentation of the incident should begin immediately. Police Services

should be contacted to document possible hate crimes or bias incidents
through such activities as photographing physical injuries, offensive graffiti
and evidence of vandalism. Depending on where the incident occurs (in the
living community, in the classroom, in a co-curricular program, or on the job),
the appropriate documentation procedure should be implemented. Reports
should include important details such as when and where the incident
occurred and who was involved in or witnessed the incident. Any physical
evidence of the incident (messages written on doors, physical objects, etc.)
should be retained and secured for police to investigate and crime scenes
should not be disturbed prior to the arrival of Police Services.

5. Targeted students may feel uncomfortable about cooperating with an

investigation due to fear of retaliation by the perpetrator(s). Impacted
students should be assured by investigating authorities that their safety and
security are important and that every effort will be made to ensure that their
safety is protected and measures, such as relocation and when possible
anonymous reporting, can be utilized to minimize potential threats. Any
retaliatory behavior by the student suspected of the violation or by his or her
supporters may constitute an independent violation of college policy.

6. Students who have been identified as suspects in a bias incident or hate

crime will be assigned a case coordinator to work with regarding the impact of
the incident and the student's rights and responsibilities and the steps for due
process that they will be afforded under the Student Conduct Code.

7. Intake investigation and fact finding of all complaints of hate crimes and bias
incidents will be conducted by the appropriate investigative teams (police
services, campus grievance officer, and civil rights officer). Investigations will
be conducted to determine possible violations of college policies and local,
 state and federal laws and regulations. Students suspected of violations may
be accountable under the criminal justice system, the Student Conduct Code
and Non-Discrimination Policy.

8. Once the most immediate needs have been addressed, the Vice President for
Student Affairs or the vice president's designee will convene the response
team. The response team will be comprised of:

○ Vice President for Student Affairs

○ Dean of Student and Academic Support Services

○ Director, Housing and Food Services and designees

○ Academic Dean (Provost will refer to the appropriate dean)

○ Agenda Committee Member

○ Director of First Peoples' Advising Services

○ Director of Police Services

○ Campus Grievance Officer

○ Civil Rights Officer

○ Executive Associate to the President

○ Associate Vice President for Human Resource Services

○ Director of College Relations

○ Director of Access Services

○ President's Special Assistant for Diversity Affairs

○ Director of Student Activities

○ Students

The Vice President may add to the membership of the team, faculty and staff
who have scholarship/research and expertise who could add to the analysis of
the situation or other faculty and staff in areas based on the circumstances or
location of the incident.
9. The response team will identify the needs of the affected communities as well
as that of the larger Evergreen community. Informing the affected
communities as well as the larger community regarding the incident, as
appropriate, will be a major function of the response team.

10.An email will be sent to the appropriate affected community members

describing the incident and the steps which are being taken, status of the
investigation, and that the response team has been assembled. An update
should follow once the response team has had an opportunity to assess the
situation and determine next steps.

11.The response team may organize and hold open forums within the affected
communities as well as the larger community to provide information regarding
those details of the incident which can be revealed outside of the
 investigation, to gather suggestions, to denounce such incidents, to reaffirm
Evergreen's values and standards around diversity and equal respect and to
educate about hate and bias.

12.The response team will be provided with progress reports of the investigation.
Given that criminal and judicial investigations are confidential, the team will
be kept informed of the investigation's progress to the extent allowable.
Whenever possible, the team will provide assistance to ensure that all aspects
of bias-related activities are examined and that the investigation is handled in
a manner that is efficient, effective and culturally sensitive. The intent is to
send a clear message that the college has zero tolerance for hate crimes and
bias incidents and will act swiftly and effectively when such incidents are
reported.

13.The response team will also determine topic program areas for additional
trainings for students, staff and faculty. All efforts should be made to develop
trainings for the community that will enhance and encourage inter-group
dialogue that focuses on how conversations around issues of racism and
discrimination of all types enable all students to be more socially integrated
into the campus.
Endnotes
Division of Student Affairs Case Coordinating Protocol. In crises and emergencies the Division of Student Affairs activates the 
case­coordinating protocol to ensure direct services and support to students in crisis. The case coordinator is a student affairs 
practitioner trained in crisis management and emergencies. The coordinator assists the student(s) in accessing campus and local 
support services and resources and intervenes or facilitates in matters related to the student's(s') academic and personal well­
being. The case coordinator is assigned to the student(s) until the crisis is resolved. When requested by the student(s), the case 
coordinator will accompany the student(s) to appointments when appropriate, as well as advise the student(s) regarding college 
policies. Students residing in the residence halls are assigned a case coordinator by the Director of Housing and Food Service, 
and students living off campus are assigned a case coordinator by the Dean of Student and Academic Support Services.
The case coordinator also works with students who may not have been directly involved in the crisis, but who have felt the 
impact of the crisis. Another form of support the case coordinator lends is to students who are involved in the college judicial 
system, assisting them in understanding their rights and responsibilities and due process guidelines.
Sexual Assault Protocol
The sexual assault protocol, under the Health and Counseling Center, provides advocacy support to persons who have been 
sexually assaulted. These services are coordinated by a student affairs professional who works closely with Police Services, St. 
Peter's Hospital and Safe Place.
Note: Permission granted by Syracuse University to adopt selected text from Syracuse's Bias Related Incidents Protocol
Reference Sources Reviewed
A Systematic Plan to Fight Hate on Campus, (2004), American Association of Colleges and Universities (AAC&U)
Diversity on Campus: Report from the Field, (2000), National Association of Student Personnel Administrators
Responding to Hate Crimes and Bias Motivated Incidents on College and University Campuses, (2000), Community Relations 
Services, Department of Justice
Violent Victimization of College Students, (2003), Department of Justice
American Civil Liberties Union Briefing Paper Number 16, Hate Speech on Campus
Responding to Hate at School, A Guide for Teachers, Counselors and Administrators, (1999), Southern Poverty Law Center
10 Ways to Fight Hate on Campus, A Response Guide for College Activities, (1999), Southern Poverty Law Center
http://www.zdnetasia.com/techguide/workplace/0,3800010799,39217254,00.htm

Create an incident response policy
By Mike Mullins, Special to ZDNet Asia
Monday, February 21, 2005 05:16 PM

Does your organization have an incident response policy (IRP)? You may not think you need one. You've locked down 
your organization's network, and your disaster recovery plan effectively details how to respond to a security incident­­so 
you feel relatively secure. 

But even the most secure networks need an IRP. Regardless of the severity of the incident, it's essential that your company has 
a policy in place that outlines steps to take during potentially disastrous times. 

Every organization should include an IRP as part of its overall business continuity plan (BCP). Knowing how to minimize 
security vulnerabilities and respond to security incidents in a well­organized and thorough manner should be a critical 
component of any company's BCP. 

A security incident is any adverse event or threat that affects your organization's information systems or network. Incidents can 
include unauthorized access, malicious code (such as viruses), network probes, and denial­of­service attacks. 

An effective IRP should address eight key areas. Let's take a closer look. 

1. Demonstrate management support 
First and foremost, your policy should clearly outline management's support of the policy. A member of senior 
management­­or anyone with the same authority to address the included provisions­­should sign the policy. These 
provisions might include any financial resources, personnel, equipment, and training dedicated to implementing the 
policy as well as internal consequences of violation. 

2. Decide an organizational approach 
There are two common methods of dealing with an incident: Contain, clean, and deny, or monitor and record. The 
method your organization chooses should depend on whether the goal is to seek prosecution and/or compensation or 
to quickly restore services. 

3. Determine outside notification procedures Allowing your network to participate in a distributed attack and 
remaining silent is a legal landmine waiting to explode. In our collaborative world, it's important to determine 
procedures for notifying third parties if you're involved in a distributed event. Decide whom you'll inform as well as 
when and how. 

4. Discuss remote connections 
Your policy must address remote connections. This should encompass all remote employees or contractors, and it 
needs to outline your rights to disconnect and remove access during a security incident. 

5. Define partner agreements 
Describe downstream and upstream agreements with your service providers and customers that define your right to 
monitor and disconnect the network as required. 

6. Develop an incident team 
Identify by position (not name) the members of the team that will enforce the policy, and describe their roles, 
 responsibilities, and functions. The team should encompass a variety of skills and areas of expertise, including 
security, administrators, human resources, and legal. 

7. Design an internal communications plan 
Develop an internal communications plan that identifies who you will notify and how you will contact them. In 
addition, decide on the person who's responsible for initiating this contact. 

8. Demand a follow­up report 
Define a method for reporting and historically archiving the incident. Use that information to tune your operations to 
prevent a similar incident from reoccurring. 

Every network is unique, and the type of business your organization conducts on the Internet will influence the level 
of your response to a security incident. As your network changes, make sure you adjust your IRP accordingly and 
address newly discovered vulnerabilities as they occur. 

Final thoughts 
If your organization has no established, coherent plan of action, it can easily make the wrong decisions both during and after a 
security incident. An IRP policy can't solve your problems, but it can offer a cool­headed method for dealing with a hot issue. 

For more in­depth information on incident response, check out SANS' Information Security Reading Room , which offers a 
wealth of available information that can help you create a comprehensive incident response policy. 
http://technology.iusm.iu.edu/body.cfm?id=99

SUBJECT: Incident Response Policy 
SOURCE: Office of the Dean, IU School of Medicine 
POLICY NO: IUSM SEC­04 
DATE ISSUED: 12 Nov 04 
REVISION: March 31, 2005 
PURPOSE: 
The purpose of this policy is to outline the different responsibilities of the Information Services and Technology Management 
(ISTM) office and the IUSM departments with regards to reacting and responding to various types of network and information 
security incidents that may occur within IUSM. 
SCOPE: 
This policy applies to all employees and faculty of IUSM; as well as vendors, contractors, partners, students, collaborators and 
any others doing business or research with the IUSM will be subject to the provisions of this policy. Any other parties, who 
use, work on, or provide services involving IUSM computers, technology systems, and/or data will also be subject to the 
provisions of this policy. IUSM computing resources have been developed to encourage widespread access and distribution of 
data and information for the purpose of accomplishing the educational, clinical, and research missions of the school. This 
policy will not supercede any Indiana University developed policies but may introduce more stringent requirements than the 
university policy. 
DEFINITIONS: 
Security incidents can generally be defined as "the act of violating an explicit or implied security policy" (Definition taken 
from the Carnegie Mellon Computer Emergency Response Team Coordination Center Incident Reporting System Guidelines.) 
An IUSM security incident is defined as an event that exposes IUSM­held data to unauthorized individuals and impacts or has 
the potential to impact negatively either patient safety or privacy, IUSM employee safety or privacy, or the reputation of IUSM. 
The Core incident response team consists of those members of various IUSM offices, departments, and centers who will assist 
in the conduct of a major incident investigation. The incident response team will be activated at the discretion of the CIO. The 
core IUSM incident response team members will be the Chief Information Officer, the Chief Security Officer, a physician 
advisor, a Legal Office representative, a Media Relations Office representative, and a Compliance Office representative. 
Adjunct incident response team members are those members of various IUSM centers, departments and offices who have 
specific skills needed at times during incident investigations. 
POLICY: 
1. The Chief Information Officer is granted authority through the ISTM Charter, dated 1 Oct 03, to take actions necessary to 
protect IUSM people, resources, data and/or communications in the event of a security incident. 
2. The Chief Security Officer serves as the investigative and operational lead for the conduct of all IUSM security incident 
investigations. The Chief Security Officer will be the primary authority for invoking incident response procedures. 
3. Various IUSM departments and centers will provide core and adjunct members of the incident response team to assist the 
Chief Security Officer during security incident investigations. All incident response team members will be assigned duties 
based on the circumstances of the incident. Specific members and their respective roles are outlined in IUSM incident response 
procedures. 
4. IUSM personnel must immediately report: a. a security incident that involves unauthorized physical access to a building or 
secure location, physical threat, imminent danger, or personal safety issue to the IUPUI Police Department. b. an actual or 
suspected security incident that involves unauthorized access to electronic systems owned or operated by IU and/or IUSM; 
malicious alteration or destruction of data, information, or communications; unauthorized interception or monitoring of 
communications; and any deliberate and unauthorized destruction or damage of IT resources to the Indiana University IT 
Security Office (ITSO) as outlined in IT Policy Office (ITPO) incident reporting procedures. 
5. All communications with the media regarding an incident will be coordinated through the IUSM Public and Media Relations 
office. 
VIOLATION OF POLICY: 
If it is suspected that this policy is not being followed, report the incident to the Center, Departmental IT manager or 
representative and the Chief Security Officer. Any exceptions to this policy must be approved in advance by both the Chief 
Security Officer and the Chief Information Officer. 
ENFORCEMENT: 
Any person found to have violated this policy will be subject to appropriate disciplinary action as defined by the provisions of 
Indiana University Policy IT­02, Policy on Sanctions for Misuse or Abuse of Indiana University Technology Resources. 
REVISION HISTORY: 
1. IUSM SEC­04, 12 Nov 04, original policy 
2. Revision, March 31, 2005: Added "Centers" to the following: Definitions section, Core Incident Response Team and Adjunct 
Incident Response Team definitions. 
http://www.gsu.edu/ist/incident_response.html

Incident Response Policy

Policy
Rationale
Standards & Procedures
Revisions
Approval Dates
(Summary of Changes/Additions/Deletions) 

Policy
Information security incidents occurring on the university network or attached devices will be managed centrally by the 
University Information Security Officer (ISO) and will include other campus resources as determined by the ISO. 

Rationale
Centralized notification and control of security incident investigation is necessary to ensure that immediate attention and 
appropriate resources are utilized to control, eliminate and determine the root cause of events that could potential disrupt the 
operation of the university or the compromise of university data or sensitive information.  

Standards & Procedures
Standards
Computer Security Incident Response Team (CSIRT). The ISO, with the advice and assistance of college and departmental 
IT representatives, will have the capability to establish a CSIRT to respond to security incidents.  
Campus­wide Outage. A campus­wide outage is a fault, event or other unforeseen issue causing failures to all or large 
portions of the campus communication and computing infrastructure, services and devices or key communication and 
computing resources such as a DNS failure or a loss of campus Internet access.  This type of incident would be treated as a 
Critical Incident.
Incident Types.  An incident is defined an as adverse event in an information systems and/or network device or the threat of 
the occurrence of such an event.  Events may be characterized as unauthorized use of another’s user account, unauthorized use 
of system privileges or execution of malicious code.  Events characterized as environmental (such as natural disasters, 
electrical outages, heat damage, etc.) are not within the scope of this policy. The most identifiable types of event are: 
Malicious code attacks—Attacks by programs such as viruses, Trojan Horse programs, worms, and scripts to gain privileges, 
capture passwords, and/or modify audit log to hide unauthorized activity. 
 
Unauthorized access—Includes unauthorized users logging into a legitimate account, unauthorized access to files and 
directories or operation of “sniffer” devices.

Disruption of services—Includes erasing of programs or data, mail spamming, denial of service attacks or altering system 
functionality.

Misuse—Involves the utilization of computer resources for other than official purposes.  

Espionage—Stealing information to subvert the interests of a corporation or government entity.
 
Hoaxes—Generally an e­mail warning of a nonexistent virus.

Incident Severity. Incidents will be classified by the ISO based on the perceived impact on university resources:
Critical—Severe risk to the university network and/or external systems over the Internet.  May be characterized by widespread 
risk of compromise of multiple systems or high risk of compromising sensitive information. Criteria for determining if an 
incident is critical include but are not limited to: health and safety of personnel, legal issues, possible harm to the university’s 
reputation.
Medium—Medium risk to the university network and low risk to external systems over the Internet. May be characterized by 
risk of compromising more than one system, no risk to sensitive data, or isolation to a single system.
Low—Low risk to the university network and no risk to external systems over the Internet. May be characterized by 
compromise of a system that does not host or process critical/sensitive information, does not pose a risk to other systems or 
types of devices.
 
Procedures
Compromised System Procedure (PDF)
Computer Security Incident Response Team Procedure (Word)
 

Revisions
 

Approval Date(s)
Reviewed by IS&T
Reviewed by Information Security Subcommittee
Reviewed by ISAT Senate Committee
Approved by: University Administrative Council
Approved on: 3/8/06
Version number: 1.0.0
Effective Date: 3/8/06
 

Summary of Additions/Deletions/Changes
http://boisestate.edu/oit/iso/incresponsepolicy.shtml

Boise State University Information Technology Incident Response Policy  
DRAFT 09/09/2008

 Purpose 

The purpose of this policy is to define general requirements for responding to an information security incident.  

I.  Policy Statement  

 The IT Incident Response Policy and subordinate procedures define standard methods for identifying, containing, eradicating 
and documenting response to computer­based information security incidents.  Information Security incidents occurring on the 
University network or attached devices will be managed centrally by the University Information Security Officer (ISO) and 
will include other campus resources as determined by the ISO.  Centralized notification and control of security incident 
investigation is necessary to ensure that immediate attention and appropriate resources are used to respond to events that could 
potentially disrupt the operation of the University or compromise University data. 
 

 A.  Definitions

 Incident Types  

An incident is defined an as adverse event in an information systems and/or network device or the threat of the occurrence of 
such an event.  Events may be characterized as unauthorized use of another’s user account, unauthorized use of system 
privileges, or execution of malicious code.  Events characterized as environmental (such as natural disasters, electrical outages, 
heat damage) are not within the scope of this policy. The most identifiable types of event are: 

Malicious code attacks—Attacks by programs such as viruses, Trojan Horse programs, worms, and scripts to gain privileges, 
capture passwords, and/or modify audit log to hide unauthorized activity.

      

Unauthorized access—Includes unauthorized users logging into a legitimate account, unauthorized access to files and 
directories, or operation of “sniffer” devices.

Disruption of services—Includes erasing of programs or data, mail spamming, denial of service attacks, or altering system 
functionality.

 Misuse—Involves the use of computer resources for purposes other than those defined in the Information Technology 
Resource Use policy (BSU 6460­C). 

      
Espionage—Stealing information to subvert the interests of a corporation or government entity.

      

Hoaxes—Generally an email warning of a non­existent virus.

Campus­wide Outage­­A campus­wide outage is a fault, event, or other unforeseen issue causing failures to all or large portions 
of the campus communication and computing infrastructure, services, and devices or key communication and computing 
resources such as a DNS failure or a loss of campus Internet access.  

 
  

B.  Incident Severity

Incidents will be classified by the ISO based on the perceived impact on University resources:

Critical—Severe risk to the University network and/or external systems over the internet.  May be characterized by widespread 
risk of compromise of multiple systems or high risk of compromising sensitive information.  Criteria for determining if an 
incident is critical include but are not limited to: health and safety of personnel, legal issues, possible harm to the University’s 
reputation, a campus­wide outage.

     

 Medium—Medium risk to the University network and low risk to external systems over the internet.  May be characterized by 
risk of compromising more than one system, no risk to sensitive data, or isolation to a single system.

Low—Low risk to the University network and no risk to external systems over the internet. May be characterized by 
compromise of a system that does not host or process critical/sensitive information, does not pose a risk to other systems or 
types of devices.

 
 

C.  Computer Security Incident Response Team (CSIRT)  

The ISO with the advice and assistance of college and departmental IT representatives will have the capability to establish a 
CSIRT to respond to security incidents. 

D.  Incident Reporting

Any individual or organization internal or external to Boise State can notify the ISO of an activity or concern.

 
II. Scope  

This policy applies to all Boise State employees, contractors, vendors and agents.   
 
III. Responsibility

All users of Boise State IT resources are reponsible for compliance with this policy.

IV.  Procedures

A.  Incident Response Procedure:  The ISO maintains internal procedures for Incident logging, tracking, and reporting.  The 
current procdure can be found at http://boisestate.edu/oit/iso/IncidentResponseProcedureBSU.html

B.  Non­Compliance with this Policy:  Any employee found to have violated this policy may be subject to disciplinary action, 
up to and including termination of employment.

Adapted with permission from Georgia State University and Yale University
http://www.certiguide.com/secplus/cg_sp_542IncidentResponsePolicy.htm

 5.4.2     Incident  Response Policy
    
Incident Response Policy will vary with the particular needs of an organization. For example, while it may be
acceptable to disconnect the router that connects to the Internet in one firm, this could lead to serious liability in
another firm, such as an ISP. It is beyond this work to detail all forms of policy regarding Incident Response. The
footnote443 will take you to a page supported by Fred Cohen who has more than a half dozen links to specific
policies from the Naval Research Lab to generic templates to be filled in.

One of the most important things to say about incident response policies is, have one before you need it. Decide
before you’re faced with a computer security incident, how you are going to handle it, who will be involved, what
their duties will be, etc. This enables you not to waste valuable time deciding these things during an actual incident.
https://security.tcu.edu/IncidentResponsePolicy.htm

TCU Technology Resources Incident Response Policy

The purpose of this policy is to define the procedures that are to be followed when an incident is
reported to, or discovered by, Technology Resources. This policy does not apply to major incidents
involving widespread loss of sensitive or confidential personal information. These latter incidents are
dealt with in the TCU Major Computer Incident Response Plan which is under development.

When an incident is reported through any means to any staff in Technology Resources, the matter is
referred to the Associate Provost for Technology Resources or their designee.

A determination is made as to whether the incident primarily involves the authority of other
departments and if so the matter is forwarded by Technology Resources as follows

1. Legal matter - Campus Police

2. Solely a breach of the Computer Resources Policy - Technology Resources

3. Student Code of Conduct or other student issue - Campus Life

4. Faculty/Staff Code of Conduct issue or other faculty/staff issue - Human Resources

If the incident is handed off to another department the Associate Provost for Technology Resources
or their designee will act as the liaison with these other departments.

If the issue is deemed to be an immediate threat to the security or stability of TCU information
resources such as the network or servers, Technology Resources may take immediate action to
isolate the problem in accordance with the Computing Resources Policy. Under these circumstances
Technology Resources staff may disable network or account access for persons or equipment inside
or outside TCU without prior notice. This action will be reported to the Associate Provost for
Technology Resources or the Provost as soon as is possible.

If the incident is investigated initially by Technology Resources and it is discovered that there are
legal issues involved, or possible violations of any policies concerning TCU students, faculty or staff
then the incident will be handed to Campus Police, Campus Life or Human Resources along with any
evidence collected to that point. From that point on Technology Resources will assist the
department now responsible for the investigation.

During an investigation by Human Resources, Campus Police, or Campus Life personal information
including traffic logs, email, files etc. may be requested through the Associate Provost for
Technology Resources by these unit heads or their designee. If information is requested for any
other reasons it will be provided only after the approval of the Provost, or in their absence the
Associate Provost for Technology Resources. In any case personal or private information will be
protected in accordance with the TCU Privacy of Information Policy and the Computing Resource
Policy as well as other applicable policies.
http://infrastructure.fedoraproject.org/csi/security-policy/en-US/html-
single/#IncidentResponse-Standard

2.2. Security Incidents
Security incidents are serious matters. Any detection of a security breach or
malicious behavior should immediately be reported. Users should contact the
security team directly at admin fedoraproject.org. Please do not share any details
related to the incident with anyone other than the initial contact. Maintaining
confidentiality protects you and The Fedora Project from further internal attacks. A
potential attacker that becomes aware of detection may cover tracks or change
behavior suddenly, which makes investigation more difficult. On the other hand, if
the security team is aware of and tracking an attack in progress, the chances of
catching the attacker greatly increases.
2.3. External Sources and References
• Hardening RHEL5
http://people.redhat.com/sgrubb/files/hardening-rhel5.pdf

• CentOS OS_Protection
http://wiki.centos.org/HowTos/OS_Protection
Chapter 3. Incident Response
Mike McGrath
Fedora Infrastructure Lead
Fedora Project
3.1. Introduction

3.1.1. The Rules

3.1.2. Incident Response Team

3.1.3. Management

3.2. Prerequisite Tasks

3.3. Assessment and Communication

3.3.1. Management Chain Notification

3.3.2. Threat Assessment

3.3.3. Entry Investigation

3.3.4. Impact-Assessment

3.3.5. Partner Communication

3.3.6. Public Disclosure

3.4. Actions

3.4.1. Investigation

3.4.2. Data Integrity Plan

3.4.3. Re-secure Environment Plan

3.1. Introduction
This document sets out the procedures that are to be followed in the event of a
security-related incident. Each incident will have an acting incident coordinator at
all times. The incident coordinator is charged with coordinating task responsibilities,
and with finding another coordinator in the event that he or she becomes
unavailable.
3.1.1. The Rules
You have been directed to read this policy because you are either involved in an
incident, or because you have been asked to be part of an investigation related to a
security incident. While performing the tasks below please keep the following in
mind.
Incident Rules

Complet Requireme
Action Comment
e nt
Unless it is part of a task that is assigned to you,
do not make any changes to a host without
Make
Must Not permission from the incident coordinator. This
Changes
includes shutting services down, logging in or
out, and other configuration changes.
Incident team members must not work on tasks
Task that have not explicitly been assigned to them
Must Not
Assignment without discussing it with the incident
coordinator or the task leader. [37]
Discussion of the incident must only happen
between the members of the team chosen by
Information
Must the incident coordinator. Before discussing any
Disclosure
incident with someone, make sure they are on
the list of team members. [38]
Do not make any assumptions about task
Must Assumptions assignments or completion. Discuss any
concerns you have with the incident coordinator.
3.1.2. Incident Response Team
Anyone specifically contacted and assigned responsibility for a task related to this
incident automatically becomes a member of the incident response team. The team
may include non-technical members involved with marketing or legal tasks.
3.1.2.1. Incident Coordinator
The incident coordinator is accountable for all technical issues related to the
incident. If a compromise is involved, the incident coordinator is ultimately charged
with discovering the nature of the incident; assessing the extent of any damage or
risk to services, users, or data; concluding the incident as quickly and efficiently as
possible; and creating and implementing a plan for mitigation and prevention of
future damage or risk. This role is largely technical, but the incident coordinator
must also work with team members to coordinate and delegate tasks. This
coordination includes, but is not limited to, working with hosting providers,
providing or summarzing information for reporting or dissemination, and ensuring
that team members are following the incident respose plan.
The tasks below must be completed in an order determined by the incident
coordinator. Tasks that require or depend on another task are to be explicitly so
defined. As each task is completed it should be marked completed on the task list.
Some tasks require written answers to questions. Coordinate the answers to these
questions for factual correctness among chosen parties via a secure
communications channel.

3.1.2.2. Task Coordinator

Each task is to be assigned to a task coordinator. Each task must be completed and
the results (if any) should be given back to the incident coordinator. Do not work on
tasks that have not been assigned to you. Multiple team members may be working
on one task, though only one of them is to be designated the coordinator of that
task. Many tasks can be accomplished in parallel, but some tasks must be
processed sequentially. Tasks are to be labeled if they must be completed
sequentially. Any assignment with a "sign off" field must be signed off by the task
coordinator to ensure it has been completed and verified.
It is also the responsibility of the task coordinator to ensure that once a task is
done, the task is marked as completed along with the identity of the team member
who completed it. If a team member is unable to complete a task, it is the team
member's responsibility to inform the incident coordinator. The team member
should then attempt to find a replacement from the incident response team, and
must notify the incident coordinator whether a replacement has been found. The
incident coordinator is ultimately responsible for ensuring that all tasks are assigned
properly.

3.1.3. Management
Generally the incident coordinator reports to or works with one or more further
managers. Although managers may not be involved directly in specific tasks, it is
important to keep them informed of the plan for investigation and recovery, and the
overall progress. Managers are responsible for ensuring the technical members of
the incident response team are able to work as unfettered as possible, and that the
appropriate entities outside the team are kept informed properly. For instance, it
should not be the responsibility of the technical team to also manage
communication with end users.
3.2. Prerequisite Tasks
The tasks in this listing must be started prior to any other tasks. Some tasks, like
the time line, will be ongoing.
Prerequisite Tasks

Sign
Task Description
off
If possible, take two LVM snapshots of all volumes on affected
systems. If possible, take a snapshot at the disk level to get an
Snapshot entire disk image, as opposed to logical volume images. If LVM
is not being used, try to dd the block device somewhere piping
through ssh.
Work with the incident coordinator to copy the images from the
"Snapshot" task above to an agreed secure location. Provide a
Snapshot Copy size estimate. Include basic details about the images, including
the architecture and the requirements to restore these images
to a running state.
Sign
Task Description
off
Log Copy Make an off-site copy of any relevant logs.
Create and maintain a list of people who are aware of the
Incident
compromise and its details. Once the list is made, it must not
Response Team
grow without the approval of the incident coordinator unless
List
already specified in this incident response plan.
Create and maintain a time line, sorted by the actual time an
Time line event took place. The timeline should indicate the actual time
of events and not simply the time of discovery.
Aside from the incident response team, disable access to any
Disabling
hosts that are suspected as compromised. In extreme cases
Authentication
this may involve disabling central authentication altogether.

3.3. Assessment and Communication
These tasks are designed around threat assessment and communication.
Communication tasks include apprising appropriate management chains of the
problem and assembling correct information for dissemination to the public.
3.3.1. Management Chain Notification
This section sets out the method by which the management chain is to be informed
that an incident has been discovered, and reports and updates are to be sent as
investigation, mitigation, and repairs are completed.
Management Chain Notification

Sign
Task Description
off
This is the initial contact through which management is notified
that an incident has either occurred or is in progress. Contact is to
be made by phone, and all contact numbers should be used until
Notify either the manager has been reached, or the list of contact
Managemen numbers has been exhausted. A message is to be left at each
t number if no one answers. Phone contact must be followed up by
email, whether or not the manager was reached directly. Ensure
the following people have been contacted:
legal@fedoraproject.org, fpl@fedoraproject.org
Complete the Threat Assessment below, and email it to:
legal@fedoraproject.org, fpl@fedoraproject.org. Inform the
Threat
recipients that until the final assessment has been completed, the
Assessment
information provided should be considered preliminary.
Additionally include a copy of the time line in its current state.
3.3.2. Threat Assessment
The Threat Assessment is to be written for dissemination to management and
communication personnel listed as team members. Provide high level technical
details, and remember the people reading this assessment may not be technical.
Include appropriate explanations for all technical terms used in the assessment.
Threat Assessment Sign off

Sign
Task Description
off
Threat Answer the questions
Assessment below.
For each of the following questions, provide an answer that takes into account each
of the hosts that have been affected and the information on those hosts.
Threat Assessment

Complet Answe
Question
e r
Could this incident impact end users or customers?
Could this incident impact contributors, contractors, co-workers,
or partners?
Could private data have been read or written to by the attacker?
Has private data been read or written to by the attacker?
Provide an estimate of how long the incident has been occurring.
3.3.3. Entry Investigation
In the event that the incident involves a compromise of security such as an
intrusion, it is important to determine the point of entry. Below are questions that
should be answered in the event of such a compromise, prior to any mitigation
efforts such as rebuilding or repairing services.
Entry Investigation Sign off

Sign
Task Description
off
Entry Answer the questions
Investigation below.
Entry Investigation

Complet Answe
Question
e r
How did the attacker gain entry to the services?
What is the likelihood the incident was caused by (1) a malicious
associate, or (2) someone without any prior association with The
Fedora Project?
Did the attacker use a known or unknown vulnerability in software
installed on the system?
Did the attacker use physical access to any of the host(s) covered
by this plan to gain additional access?
Did the attack appear to come from other machines operated by
The Fedora Project?
Did the attack appear to come from machines operated by any of
our hosting providers?
3.3.4. Impact-Assessment
The impact assessment is closely related to the threat assessment but measures in
greater detail what services and servers are are affected by this incident. Include as
much specificity as possible at the time of the assessment. As new facts or details
emerge, updates of the impact assessment are to be emailed to the incident
response team.
Impact Assessment Sign off

Sign
Task Description
off
Impact Answer the questions
Assessment below.
Impact Assessment
Complet Answe
Question
e r
Which hosts are impacted?
Which services are potentially impacted?
Which databases or other data stores require auditing to ensure
their integrity?
3.3.5. Partner Communication
Partners include any hosting providers, contractors, or other professionals that are
impacted by or involved with this incident. Partner involvement may arise from co-
ownership of equipment, provision of services, or shared connections of network
hardware. For example, an incident that involves unauthorized physical access to a
console may involve the hosting provider responsible for the security of that
console.
Any incident that involves a previously undisclosed software vulnerability should
include the upstream software provider as a partner.

Any partner notified as part of this incident response plan is considered part of the
incident response team.

Partner Notification

Sign
Task Description
off
Partner At the discretion of the incident coordinator, contact partner
Notification with details about the incident for further investigation.
3.3.6. Public Disclosure
fpl@fedoraproject.org must sign off on these tasks unless he/she delegates one or
more of them to someone else. These tasks should be completed as soon as is
feasible, and may consist of multiple notifications and updates, or be combined into
one notification if the incident is discovered and fixed quickly. Each of the tasks
listed below must be completed.
Notification Tree

Sign
Task Description
off
Initial
Let everyone know that an incident has happened.
Notification
When a partner has been determined to be affected and
therefore notified (refer to Section 3.3.5, “Partner
Partner
Communication”), outgoing notifications must not jeopardize
Integrity
the integrety of any investigations underway by those
partners.
Once a service repair plan is formulated, notify all affected
Service Repair parties about any service availability changes during rebuild
and repair.
Once the environment is deemed secure, notify all affected
Credentials parties and institute a system-wide password change by all
account holders.
Once the entry point has been located, assessed, and repaired,
and investigations are completed, notify all affected parties of
Entry
the cause of the incident and the specific repairs undertaken
to prevent recurrence.
Time Once the rebuild/repair phase is complete and services are
Sign
Task Description
off
returned to normal, send a summary of the repairs undertaken
line/Postmorte and, if appropriate, the rationale for these actions. This
m communication should include the same time line used by the
incident response team.

3.4. Actions
The following actions must be taken to correct issues related to the incident and
ultimately restore service to nominal levels. Work with the incident coordinator or
task manager to complete the tasks listed below.
3.4.1. Investigation
This section of the incident response plan includes some techniques that should be
used in the event an incident involves an intrusion or other unauthorized access, to
determine the nature of the access and whether it is ongoing.
Investigation

Sign
Task Description
off
Investigatio Once the intrusion entry point discovered, send a summary and
n details to the incident coordinator.
Mitigation Ensure the point of entry is closed or properly secured.
Investigation Tasks

Complet
Task Description
e
Increase logging of any and all services suspected of being
Increase
involved in the attack to a level sufficient to determine that no
Logging
unauthorized access is ongoing.
Compare files to known good copies, as well as backup copies.
File Use best practices such as the rpm ­V command to ensure the
Notification integrity of system contents. If appropriate, examine file
s metadata such as change, modify, and access times to
develop information about the nature of the incident.
3.4.2. Data Integrity Plan
The data integrity plan is designed to identify data that may have been accessed in
an unauthorized fashion, to identify data that may have been changed as a result of
that access, and to ensure that all impacted data is safe for continued use.
Data Integrity Plan

Sign
Task Description
off
Data Ensure the below table has been completed and is
Integrity accurate.
Data Integrity Plan

Complet
Task Description
e
Ensure the configuration management repository is intact
Configuration
and has not been altered as a result of an unauthorized
Management
access. Compare to off-site backups if necessary.
Database Verify hosts containing any databases, and the data that
Data resides therein. The nature of this task depends on the
Complet
Task Description
e
extent of any unauthorized access. The incident response
team must reach an informed consensus on the procedures
required.
Verify shared data has not been altered as a result of an
unauthorized access. Malicious files that may have been left
Shared data behind during the incident should be listed and removed
from the system. Make a list of files that have changed
during the incident window and verify them.
Remove any temporary or cached data and rebuild from
Temporary or
scratch. If this procedure is not feasible, verify the local
Cached Data
cache against a known good remote cache.
3.4.3. Re-secure Environment Plan
The Re-secure Environment Plan is designed to ensure the attacker has not left back
doors or other malicious software on covered hosts. Even if the intruder has been
blocked from re-entry through the original unauthorized access point, it is possible
for an intruder to leave alternate re-entry points using certain files on the file
system. Verification of each file is a time-consuming process. Therefore simply
rebuilding hosts is often a faster and more reliable alternative. This possibility is one
of the reasons for a robust configuration management policy.
Secure Environment Sign off

Sign
Task Description
off
Secure Ensure the tasks below have been completed
Environment successfully.
Secure Environment

Complet
Task Description
e
Rebuild any hosts that have been compromised or are suspected
Host of compromise. Work with the incident coordinator and task
Rebuilds coordinator to develop a strategic order for rebuilding if
necessary.
http://www.da.ks.gov/ITEC/Documents/ITECITPolicy7320.htm

Information Technology Policy 7400 ­ Enterprise Computer 
Incident Response Policy
1.0 TITLE: Enterprise Computer Incident Response Policy 
1.1 EFFECTIVE DATE: October 23, 2008
1.2 TYPE OF ACTION: New Policy
1.3 KEY WORDS: Kansas Information Technology Security Council, Enterprise Security Policy, Information 
Security, User Security, Personally Identifiable Information, Security Incident Response.
2.0 PURPOSE: To define the requirements related to actions and activities before, during and after an IT system security 
incident. Agencies may require other policies to address needs relating to privacy or other losses not related to paragraph 5.1 
below.
3.0 ORGANIZATIONS AFFECTED: All Branches, Boards, Commissions, Departments, Divisions and Agencies of state 
government, hereafter referred to as Entities.
4.0 REFERENCES:
4.1 K.S.A. 1998 Supp. 75­7203 authorizes the ITEC to: Adopt information resource policies and procedures and 
provide direction and coordination for the application of the state's information technology resources for all state 
agencies.
4.2 Kansas Information Technology Executive Council (ITEC), ITEC Policy 7300R1, Information Technology 
Security Council Charter 
4.3 Kansas Information Technology Executive Council (ITEC), ITEC Policy 7230, Revision 1, General Information 
Technology Enterprise Security Policy.
4.4 Regents Information Technology Council (RITC) Security Incident Policy and Procedure, RITC Security Incident 
Policy 
4.5 Department of Administration Intrusion Detection Incident Response Security Policy and Procedure.
4.6 USDA Cyber Security Incident Handling Procedures manual (March 20, 2006)
4.7 National Institute of Standards and Technology Special Publication 800­61 “Computer Security Incident Handling 
Guide”
4.8 National Institute of Standards and Technology Special Publication 800­100 “Information Security Handbook: A 
Guide for Managers.
4.9 Carnegie Mellon University Software Engineering Institute “Handbook for Computer Security Incident Response 
Teams (CSIRTs)”
4.10 Forum of Information Response and Security Teams (FIRST)
http://www.first.org/resources/guides/csirt_case_classification.html (November 17, 2004)
5.0 DEFINITIONS:
5.1 Security incident is defined as a compromise of a system that has critical, sensitive, or confidential data; any 
compromise that significantly affects agency resources; the act of violating an explicit or implied security policy; the 
act of violating any Federal, State or local law which may result in the loss of confidentiality, integrity or availability. 
Compromises may be the result of failed or successful unauthorized access attempts; unwanted disruption of service; 
or use of a system to change or damage system hardware, firmware or software.
5.2 Incident response is defined as the activities and actions undertaken before, during and after a security incident. 
This includes the four phases of the Incident Response Life Cycle: 1) preparation, 2) detection and analysis, 3) 
containment, eradication and recovery, and 4) post­incident activity.
  
6.0 POLICY:
6.1 Statement of Responsibility: The Chief Information Security Officer (CISO) is designated as the central point of 
contact and coordinating authority for enterprise IT Security incidents.
6.2 The CISO is responsible for establishing a Computer Security Incident Response Team (CSIRT) and for the 
conducting activities according to the Enterprise IT Security Reporting Protocols (ITEC 7320A).
6.3 The CISO is responsible for notification of incidents to entities and Regents institutions according to parameters 
and guidelines contained in the Enterprise IT Security Reporting Protocols (ITEC 7320A) 
6.4 Entities are responsible for following the Enterprise IT Security Reporting Protocols (ITEC 7320A).
6.5 Regents institutions will report enterprise IT security incidents to the KBOR President & CEO and/or KBOR 
Chief Information Officer (CIO) of the Board of Regents within 24 hours of a major security incident. The KBOR 
President & CEO or KBOR CIO will then notify the CISO and Executive Branch CITO.
7.0 PROCEDURES:
7.1 The practices and procedures for Enterprise Computer Incident Response shall conform to the requirements set 
forth in the “Enterprise IT Security Reporting Protocols”, as amended, included as Attachment A to this policy.
8.0 RESPONSIBILITIES:
8.1 Heads of entities are responsible for establishing procedures for their organizations to comply with the 
requirements of this policy.
8.2 The Chief Information Security Officer is responsible for the maintenance of this policy.
9.0 CANCELLATION: None
http://articles.techrepublic.com.com/5100-10878_11-5755543.html

Create an incident response policy

by Michael "Mullins CCNA, MCP" | Jul 05, 2005 7:00:00 AM
Tags: Michael Mullins CCNA, MCP, incident response policy, security incident, security...
0 comment(s)
• Email

• Share

○ Digg

○ Yahoo! Buzz

○ Twitter

○ Facebook

○ Google

○ del.icio.us

○ StumbleUpon

○ Reddit

○ Newsvine

○ Technorati

○ LinkedIn

• Save

• Print

• Recommend

• 8

Takeaway: Even the most secure networks need an incident response policy (IRP). Take a look at eight key areas that an 
effective IRP should address. 
Does your organization have an incident response policy (IRP)? You may not think
you need one. You've locked down your organization's network, and your disaster
recovery plan effectively details how to respond to a security incident--so you feel
relatively secure.
But even the most secure networks need an IRP. Regardless of the severity of the incident, it's essential that your company has 
a policy in place that outlines steps to take during potentially disastrous times. 
Every organization should include an IRP as part of its overall business continuity plan (BCP). Knowing how to minimize 
security vulnerabilities and respond to security incidents in a well­organized and thorough manner should be a critical 
component of any company's BCP. 
A security incident is any adverse event or threat that affects your organization's information systems or network. Incidents can 
include unauthorized access, malicious code (such as viruses), network probes, and denial­of­service attacks. 
Get the TR Blog Roundup
Find out who's offering the best advice, the quirkiest comments, and the most compelling life stories every week with 
TechRepublic's Blog Roundup. Click here to automatically sign up to receive it every Wednesday. 
Use tags to find blog posts about Windows and security.

An effective IRP should address eight key areas. Let's take a closer look. 
Demonstrate management support 
First and foremost, your policy should clearly outline management's support of the policy. A member of senior management­­or 
anyone with the same authority to address the included provisions­­should sign the policy. These provisions might include any 
financial resources, personnel, equipment, and training dedicated to implementing the policy as well as internal consequences 
of violation. 
Decide an organizational approach 
There are two common methods of dealing with an incident: Contain, clean, and deny, or monitor and record. The method your 
organization chooses should depend on whether the goal is to seek prosecution and/or compensation or to quickly restore 
services. 
Determine outside notification procedures 
Allowing your network to participate in a distributed attack and remaining silent is a legal landmine waiting to explode. In our 
collaborative world, it's important to determine procedures for notifying third parties if you're involved in a distributed event. 
Decide whom you'll inform as well as when and how. 
Discuss remote connections 
Your policy must address remote connections. This should encompass all remote employees or contractors, and it needs to 
outline your rights to disconnect and remove access during a security incident. 
Define partner agreements 
Describe downstream and upstream agreements with your service providers and customers that define your right to monitor 
and disconnect the network as required. 
Develop an incident team 
Identify by position (not name) the members of the team that will enforce the policy, and describe their roles, responsibilities, 
and functions. The team should encompass a variety of skills and areas of expertise, including security, administrators, human 
resources, and legal. 
Design an internal communications plan 
Develop an internal communications plan that identifies who you will notify and how you will contact them. In addition, 
decide on the person who's responsible for initiating this contact. 
Demand a follow­up report 
Define a method for reporting and historically archiving the incident. Use that information to tune your operations to prevent a 
similar incident from reoccurring. 
Every network is unique, and the type of business your organization conducts on the Internet will influence the level of your 
response to a security incident. As your network changes, make sure you adjust your IRP accordingly and address newly 
discovered vulnerabilities as they occur. 
Final thoughts 
If your organization has no established, coherent plan of action, it can easily make the wrong decisions both during and after a 
security incident. An IRP policy can't solve your problems, but it can offer a cool­headed method for dealing with a hot issue. 
For more in­depth information on incident response, check out SANS' Information Security Reading Room, which offers a 
wealth of available information that can help you create a comprehensive incident response policy. 
Worried about security issues? Who isn't? Automatically sign up for our free Security Solutions newsletter, delivered each  
Friday, and get hands­on advice for locking down your systems.
http://www.upenn.edu/almanac/volumes/v53/n18/or.html

OF RECORD 

January 16, 2007, Volume 53, No. 18  Print Issue
We have adopted a new policy, Information Systems Security Incident Response Policy, which is designed to ensure that 
computer security incidents are properly identified, contained, investigated, and remedied. The policy also provides a process 
for documentation, appropriate reporting internally and externally, and communication to the community as part of an ongoing 
educational effort. Finally, the policy establishes responsibility and accountability for all steps in the process of addressing 
computer security incidents.  

The policy provides that all Penn faculty, staff, consultants, contractors, students, or any agent of any of the above, must report  
“Computer Security Incidents” to their Local IT Management, who in turn must notify ISC Information Security. In cases 
involving “Confidential University Data,” an Immediate Response Team will be assembled to investigate, contain, mitigate, 
and share learning from computer security incidents. In certain cases, a Senior Response Team is convened as well to address 
the need for any additional communications and actions.  

This policy helps us meet our compliance obligations regarding applicable security breach notification laws, including 
Pennsylvania’s Breach of Personal Information Notification Act, by requiring that each computer security incident be reported 
and handled in accordance with applicable law.  

We appreciate your compliance with this important policy.

—Robin Beck, Vice President for Information Systems and Computing
—Mary Lee Brown, Associate Vice President for Audit, Compliance, and Privacy

Information Systems Security Incident Response Policy

I. Title

A. Name: Information Systems Security Incident Response Policy 
B. Number: : 20070103­secincidentresp
C. Author(s): David Millar (ISC Information Security) and Lauren Steinfeld (Chief Privacy Officer)
D. Status: Approved   
E. Date Proposed: 2005­10­24
F. Date Revised:
G. Date Approved: 2007­01­03
H. Effective Date:  2007­01­16

II. Authority and Responsibility

Information Systems and Computing is responsible for the operation of Penn’s data networks (PennNet) as well as the 
establishment of information security policies, guidelines, and standards. The Office of Audit, Compliance and Privacy has 
authority to develop and oversee policies and procedures regarding the privacy of personal information. These offices therefore 
have the authority and responsibility to specify security incident response requirements to protect those networks as well as 
University data contained on those networks. 

III. Executive Summary
This policy defines the response to computer security incidents.

IV. Purpose

This policy defines the steps that personnel must use to ensure that security incidents are identified, contained, investigated, 
and remedied.  It also provides a process for documentation, appropriate reporting internally and externally, and 
communication so that organizational learning occurs. Finally, it establishes responsibility and accountability for all steps in 
the process of addressing computer security incidents. 

V. Risk of Non­compliance

Without an effective incident response process, corrective action may be delayed and harmful effects unnecessarily 
exacerbated.  Further, proper communication allows the University key learning opportunities to improve the security of data 
and networks. Individuals who fail to comply are subject to sanctions as appropriate under Penn policies.

VI. Definitions

Confidential University Data includes:

 * Sensitive Personally Identifiable Information–Information relating to an individual that reasonably identifies the 
individual and, if compromised, could cause significant harm to that individual or to Penn.  Examples may include, but are not 
limited to: Social Security numbers, credit card numbers, bank account information, student grades or disciplinary information, 
salary or employee performance information, donations, patient health information, information Penn has promised to keep 
confidential, and account passwords or encryption keys used to protect access to Confidential University Data.

 * Proprietary Information–Data, information, or intellectual property in which the University has an exclusive legal interest 
or ownership right, which, if compromised could cause significant harm to Penn.  Examples may include, but are not limited 
to, business planning, financial information, trade secret, copyrighted material, and software or comparable material from a 
third party when the University has agreed to keep such information confidential.

* Any other data the disclosure of which could cause significant harm to Penn or its constituents.

Security Incident.  There are two types of Security Incidents: Computer Security Incidents and Confidential Data Security 
Incidents.

* A Computer Security Incident is any event that threatens the confidentiality, integrity, or availability of University systems, 
applications, data, or networks.  University systems include, but are not limited to: servers, desktops, laptops, workstations, 
PDAs, network servers/processors, or any other electronic data storage or transmission device.

* A Confidential Data Security Incident is a subset of Computer Security Incidents that specifically threatens the security or 
privacy of Confidential University Data.

User.  A Penn user is any faculty, staff, consultant, contractor, student, or agent of any of the above.

VII. Scope

This policy applies to all Users. It applies to any computing devices owned or leased by the University of Pennsylvania that 
experience a Computer Security Incident.  It also applies to any computing device regardless of ownership, which either is used 
to store Confidential University Data, or which, if lost, stolen, or compromised, and based on its privileged access, could lead 
to the unauthorized disclosure of Confidential University Data.  Examples of systems in scope include, but are not limited to, a 
User’s personally owned home computer that is used to store Confidential University Data, or that contains passwords that 
would give access to Confidential University Data.

This policy does not cover incidents involving the University of Pennsylvania Health System (UPHS) information systems, 
which has a separate incident response policy. ISC Information Security will coordinate with UPHS as appropriate when 
UPHS computing devices, data, or personnel are involved.

VIII. Statement of Policy
A. Overview of Penn’s Incident Response Program

i. All Computer Security Incidents must be reported to ISC Information Security promptly. See Section B below.

ii. All Confidential Data Security Incidents must:

a. Generate the creation of an Immediate Response Team, as designated by the Information Security Officer (ISO), on a per 
incident basis. See Section C below.

b. Follow appropriate Incident Handling procedures. See Sections C and D below.

iii. ISC Information Security, under the direction of the Vice President for Information Systems and Computing (VP­ISC) is 
responsible for logging, investigating, and reporting on security incidents.  See Sections D and E below.

B. Identifying and Reporting Computer Security Incidents

i. Users and Local Support Providers (LSPs).  In the event that a User or an LSP detects a suspected or confirmed Computer 
Security Incident, the User must report it to his or her Local Security Officer or IT Director for issues including but not limited 
to viruses, worms, local attacks, denial of service attacks, or possible disclosure of Confidential University Data.  

ii. Local IT Management.  Local IT Management must notify ISC Information Security of all Computer Security Incidents, 
except for categories of incidents that ISC Information Security may designate in Appendix I of this policy.

iii. ISC Information Security.  ISC Information Security shall notify appropriate systems administrators and other personnel of 
all emergency and attack incidents, as well as all suspicious activity incidents when it believes that an administrator’s system is 
at risk. The system’s administrators will then work with ISC Information Security to properly address the incident and 
minimize the risk of future occurrences. 

C. Immediate Response Team 

i. Purpose.  The purpose of each Immediate Response Team is to supplement Penn’s information security infrastructure and 
minimize the threat of damage resulting from Computer Security Incidents.

ii. Per Incident Basis.  An Immediate Response Team shall be created for Confidential Data Security Incidents.

iii. Membership.  Membership on the Immediate Response Team shall be as designated by the ISO.  In most cases, members 
shall include a representative from ISC Information Security and from the affected School or Center’s technical and 
management staff.   

iv. Responsibilities.  Responsibilities of the Immediate Response Team are to assess the incident and follow incident handling 
procedures, appropriate to the incident as determined by the ISO.

v. Confidentiality.  Immediate Response Team members will share information about security incidents beyond the Immediate 
Response Team only on a need­to­know basis, and only after consultation with all other team members.

D. Incident Handling. For incidents requiring the formation of an Immediate Response Team, the following is a list of response 
priorities that should be reviewed and followed as recommended by the ISO.  The most important items are listed first:

i. Safety and Human Issues.  If an information system involved in an incident affects human life and safety, responding to any 
incident involving any life­critical or safety­related system is the most important priority.

ii. Address Urgent Concerns.  Schools and Centers may have urgent concerns about the availability or integrity of critical 
systems or data that must be addressed promptly.  ISC Information Security shall be available for consultation in such cases. 

iii. Establish Scope of Incident.  The Immediate Response Team shall promptly work to establish the scope of the incident and 
to identify the extent of systems and data affected.  If it appears that personally identifiable information may have been 
compromised, the Immediate Response Team shall immediately inform the VP­ISC and the Chief Privacy Officer (CPO). 
iv. Containment.  Once life­critical and safety issues have been resolved, the Immediate Response Team shall identify and 
implement actions to be taken to reduce the potential for the spread of an incident or its consequences across additional 
systems and networks.  Such steps may include requiring that the system be disconnected from the network. 

v. Develop Plan for Preservation of Evidence.  The Immediate Response Team shall develop a plan promptly upon learning 
about an incident for identifying and implementing appropriate steps to preserve evidence, consistent with needs to restore 
availability.  Preservation plans may include preserving relevant logs and screen captures.  The affected system may not be 
rebuilt until the Immediate Response Team determines that appropriate evidence has been preserved. Preservation will be 
addressed as quickly as possible to restore availability that is critical to maintain business operations.

vi. Investigate the Incident.  The Immediate Response Team shall investigate the causes of the incident and future preventative 
actions.  During the investigation phase, members of the incident response team will attempt to determine exactly what 
happened during the incident, especially the vulnerability that made the incident possible.  In short, investigators will attempt 
to answer the following questions:  Who?  What?  Where?  When?  How?

vii. Incident­Specific Risk Mitigation.  The Immediate Response Team shall identify and recommend strategies to mitigate risk 
of harm arising from the incident, including but not limited to reducing, segregating, or better protecting personal, proprietary, 
or mission critical data.  

viii. Restore Availability.  Once the above steps have been taken, and upon authorization by the Immediate Response Team, the 
availability of affected devices or networks may be restored.

ix.  Penn­Wide Learning.  The Immediate Response Team shall develop and arrange for implementation of a communications 
plan to spread learning from the security incident throughout Penn to individuals best able to reduce risk of recurrence of such 
incident. 

E. Senior Response Team (SRT).  If the ISO or CPO in their judgment believe that the incident reasonably may cause 
significant harm to the subjects of the data or to Penn, each may recommend to the VP­ISC or Associate Vice President for 
Audit, Compliance and Privacy (AVP­OACP) that a Senior Response Team be established. The Senior Response Team shall be 
comprised of senior­level officials as designated by the VP­ISC or AVP­OACP.  The Senior Response Team shall:

i. Establish whether additional executive management should be briefed and the plan for such briefing. 

ii. Determine, with final approval by the General Counsel, whether Penn shall make best efforts to notify individuals whose 
personal identifiable information may have been at risk. In making this determination, the following factors shall be 
considered:  

a.  legal duty to notify
b.  length of compromise
c.  human involvement
d. sensitivity of data
e. existence of evidence that data was accessed and acquired
f.  concerns about personnel with access to the data
g. existence of evidence that machine was compromised for reasons other than accessing and acquiring data
h. additional factors recommended for consideration by members of the Immediate Response Team or the Senior Response 
Team. 

iii. Review and approve any external communication regarding the incident.

F. Documentation

i. Log of security incidents.  ISC Information Security shall maintain a log of all reportable security incidents recording the 
date, School or Center affected, whether or not the affected machine was registered as a critical host, the type of Confidential 
University Data affected (if any), number of subjects (if applicable), and a summary of the reason for the intrusion, and the 
corrective measure taken.
ii. Critical Incident Report.  ISC Information Security shall issue a Critical Incident Report for every reportable security 
incident affecting machines qualifying as Critical Hosts, or other priority incidents in the judgment of ISC Information 
Security describing in detail the circumstances that led to the incident, and a plan to eliminate the risk.

iii. Annual Summary Report.  ISC Information Security shall provide annually for the VP­ISC and AVP­OACP a report 
providing statistics and summary­level information about all significant incidents reported, and providing recommendations 
and plans to mitigate known risks.

IX. Best Practices

A. Preserving Evidence: It is essential to consult Penn Information Security when handling Computer Security Incidents.  
However, if Information Security is not available for emergency consultation, the following practices are recommended:

i. Generally, if it is necessary to copy computer data to preserve evidence for an incident, it is a good idea to use bit­wise file­
system copy utilities that will produce an exact image, (e.g.UNIX dd) rather than to use file level utilities which can alter some 
file meta­data.

ii. When making forensic backups, always take a cryptographic hash (such as an SHA­1 hash) of both the original object and of 
the copied object to verify the authenticity of the copy.  Consult your System Administrator if you have questions.

iii. Assigning members to an Immediate Response Team: In cases where an incident involves an investigation into misconduct, 
the School or Center should consider carefully whom to assign to the Immediate Response Team. For example, one may not 
wish to assign an IT professional who works closely with the individual(s) being investigated.

X. Compliance

A. Verification:  ISC Information Security and the Office of Audit, Compliance and Privacy will verify any known computing 
security incidents as having been reported and documented as defined by this policy.  

B. Notification:  Violations of this policy will be reported by ISC Security and the Office of Audit, Compliance and Privacy to 
the Senior Management of the Business Unit affected.

C. Remedy:  The incident will be recorded by ISC Information Security and any required action to mitigate the harmful affects 
of the attack will be initiated in cooperation with the Business Unit Security Officer/Liaison.  

D. Financial Implications:  The owner of the system shall bear the costs associated with ensuring compliance with this policy.

E. Responsibility:  Responsibility for compliance with this policy lies with the system administrator, system owner, and 
Business Unit’s Senior Manager.

F. Time Frame:  All incidents involving critical hosts systems and networks must be reported immediately.   All other incidents 
should be reported within one business day of determining something has occurred. 

G. Enforcement:  Compliance with this policy will be enforced by disconnecting any machines that may compromise the 
University network, or other machines with Confidential University Data.  Workforce members not adhering to the policy may 
be subject to sanctions as defined by University policies.

H. Appeals:  Appeals are decided by the Vice President for Information Systems and Computing.

XI. References

1. PennNet Computer Security Policy at www.net.isc.upenn.edu/policy/approved/20040524­hostsecurity.html
2. Critical PennNet Host Security Policy at www.net.isc.upenn.edu/policy/approved/20000530­hostsecurity.html
3. Policy on Computer Disconnection from PennNet at www.upenn.edu/computing/policy/disconnect.html
4. Adherence to University Policy at www.hr.upenn.edu/policy/policies/001.asp
5. Policy on Security of Electronic Protected Health Information (ePHI) at 
www.upenn.edu/computing/security/policy/ePHI_Policy.html

Appendix I
The following category of incidents need not be reported to Penn Information Security:  

* Unsuccessful network scans
http://www.datasecuritypolicies.com/tag/incident-response-policy
http://www.datasecuritypolicies.com/tag/incident-response-policy