Information Security - Incident Response Policy

Information Security Incident Response Policy & Procedures
INFORMATION SECURITY
INCIDENT RESPONSE
POLICY & PROCEDURES
(IS IRPP)
October 2007
Page 1 of 31

Information Security Incident Response Policy & Procedures
POLICY STATEMENT
A rapid response to incidents that threaten the confidentiality, integrity, and availability (CIA) of
university information assets, information systems and the networks that deliver the information is
required to protect those assets. Without a rapid response, those assets could be compromised and
the university could be in breach of UK Legislation, JANET acceptable use policy and our own stated
policies, there is also the potential of breaching the trust of our customers and users.
The Information Services Management Team has identified improvement of Incident Response as a
strategic task and has identified improvement of Information Security as a strategic goal.
Information Security incidents will occur that require full participation of Information Services (IS)
and IS technical personnel as well as management leadership to properly manage the outcome. To
accomplish this IS will establish an incident response policy and procedures that will ensure
appropriate leadership and technical resources are involved to:
• assess of the seriousness of an incident
• assess the extent of damage
• identify the vulnerability created
• estimate what additional resources are required to mitigate the incident
It will also ensure that proper follow‐up reporting occurs and that procedures are adjusted so that
responses to future incidents are improved.
INFORMATION SECURITY INCIDENT RESPONSE POLICY &
PROCEDURES
These policies and procedures underlie the establishment and ongoing deployment of a trained
incident response team, formed with the purpose of managing information security incidents at the
University. This effort is being taken to improve the response time to incidents, to provide
consistent response, and improve incident reporting. The purpose of the Information Security
Incident Response Procedure is to establish procedures in accordance with applicable legal and
regulatory requirements and University policy to address instances of unauthorised access to or
disclosure of University Information, to be known as an Incident.
This policy applies to Information Services (IS) and all system and services for which it is
responsible.
Nothing in this Information Security Incident Response Policy & Procedure document should be
taken to be in conflict with the following higher level policies:
• Computer Use policy
• Acceptable Use Policy
Page 2 of 31

Information Security Incident Response Policy & Procedures
• Memoranda from the University Directorate
These policies and procedures specifically exclude the following:
• Non‐electronic information including paper mail.
• Copier and fax.
• Physical security.
• Contingency Planning, Business Continuity and Disaster Recovery are governed by a
different set of policies. An event may initially be declared an ‘Information Security
Incident’ and subsequently declared to be a ‘Disaster’ by the appropriate body. In this case,
an Incident Response Team (IRT) would be included into the Disaster Recovery process.
In addition to all the defences that have been mounted in protection of the infrastructure and the
information processed within, conventional wisdom recommends a high level of preparedness for a
information security incident. This policy and procedures describes the response to such events,
the conditions whereby this process is invoked, the resources require and the course of
recommended action. Central to this process is the Information Services Incident Response Team
(IRT), assembled with the purpose of addressing that particular circumstance where there is
credible evidence of an incident. See “Appendix A ­ Process Flow –” for a graphical representation
of the information flow and decision process.
The primary emphasis of activities described within this policy is the return to a normal
(secure) state as quickly as possible, whilst minimising the adverse impact to the University.
The capture and preservation of incident relevant data (e.g., network flows, data on drives,
access logs, etc.) is performed primarily for the purpose of problem determination and
resolution, and methods currently employed are suitable for that purpose. It is understood
and accepted that strict forensic measures are not used in the data capture and retention.
Forensic measures will be determined on a case by case basis.
This document may reference other documentation, policies and procedures that support this
protocol but are not contained within the document, e.g., policy that defines sensitive data, scripts
to be followed by the IS Service Desk, IS personnel, or documented IS IRT (Information Services
Incident Response Team) procedures. Where this occurs, instructions to obtain these materials will
be specified.
Circumstances may dictate the activation of other operational teams and execution of other
procedures. The IS IRT must monitor and co‐ordinate all activities occurring under other
operational teams and protocols, and communicate to all interested parties in a timely manner to
ensure accurate assessments and avoid efforts that may be duplicated or at cross‐purposes.
SCOPE
Page 3 of 31

Information Security Incident Response Policy & Procedures
It is critical that the IS IRT provide consistent and timely response to the customer, and that
sensitive information is handled appropriately. This document provides the guidelines needed for
IRT Incident Managers (IM) to classify the case category, criticality level, and sensitivity level for
each IRT case. This information will be entered into the Incident Response Incident Tracking
System (IRIMS) when a case is created. Consistent case classification is required for the IRT to
provide accurate reporting to management on a regular basis. In addition, the classifications will
provide IRT IM’s with proper case handling procedures and will form the basis of Service Level
Agreements (SLA) between the IRT and other University business areas.
Information Security Incident
DEFINITIONS
An Information Security Incident is generally defined as any known or highly suspected
circumstance that results in an actual or possible unauthorised release of information
deemed sensitive by the University or subject to regulation or legislation, beyond the
University’s sphere of control.
Examples of an Information Security Incident may include but are not limited to:
• the theft or physical loss of computer equipment known to hold files containing financial
details
• a server known to hold sensitive data is accessed or otherwise compromised by an
unauthorised party
• an outside entity is subjected to a Distributed Denial of Service (DDoS) attack originating
from within the University network
• a firewall is accessed by an unauthorised entity
• a network outage is attributed to the activities of an unauthorised entity
CATEGORIES
For the purposes of this protocol, incidents are categorised as “Unauthorised Access” or
“Unauthorised Acquisition”, and can be recognised by associated characteristics.
UNAUTHORISED ACCESS
The unauthorised access to or disclosure of University information through network and/or
computing related infrastructure, or misuse of such infrastructure, to include access to
related components (e.g., network, server, workstation, router, firewall, system, application,
data, etc.)
Page 4 of 31

Information Security Incident Response Policy & Procedures
Characteristics of security incidents where unauthorised access might have occurred may include
but are not limited to:
• Evidence (e‐mail, system log) of disclosure of sensitive data
• Anomalous traffic to or from the suspected target
• JANET CERT alerts
• Unexpected changes in resource usage
• Increased response time
• System slowdown or failure
• Changes in default or user‐defined settings
• Unexplained or unexpected use of system resources
• Unusual activities appearing in system or audit logs
• Changes to or appearance of new system files
• New folders, files, programs or executables
• User lock out
• Appliance or equipment failure
• Unexpected enabling or activation of services or ports
• Protective mechanisms disabled (firewall, anti‐virus)
UNAUTHORISED ACQUISITION
The unauthorised physical access to, disclosure or acquisition of assets containing or
providing access to University information (e.g., removable drives or media, hardcopy, cable
rooms, file or document storage, appliance hardware, etc.)
Characteristics of security incidents where unauthorised acquisition might have occurred may
include but are not limited to:
• Theft of computer equipment where sensitive data is stored
• Loss of storage media (removable drive, CD‐Rom, DVD, flash drive, magnetic tape)
• Illegal entry (burglary)
• Suspicious or foreign hardware is connected to the network
Page 5 of 31

Information Security Incident Response Policy & Procedures
• Normally‐secured storage areas found unsecured
• Broken or non‐functioning locking mechanisms
• Presence of unauthorised personnel in secured areas
• Disabled security cameras or devices
SEVERITY AND CRITICALITY
Incidents are further delineated by the actual and potential impact on the business of the
University. For additional information on severity assignments and associated symptoms, see
“Appendix B ­ Incident Severity and Criticality Levels,”. The primary focus of this policy is the
handling of Severity 1 incidents.
INCIDENT RESPONSE TEAM (IRT)
The Incident Response Team (IRT) is comprised of individuals with decision‐making authority from
within IS and charged by the Directorate with the responsibility of assisting in the process
described within this document.
UNIVERSITY INFORMATION
University Information is any information asset which is maintained by or on behalf of the
University that is used in the conduct of University business regardless of the manner in which such
information is maintained or transmitted.
SENSITIVE DATA
Sensitive Data is:
• Any University Information declared to be Highly Confidential, Confidential, or Restricted
by University policy, and
• Any personally identifiable information as determined or governed by The Data Protection
Act 1998 or University policy requiring protection from disclosure.
Examples include but are not limited to:
• Network ID and Password
• Student records
• Personnel Records
• Name in combination with address
Page 6 of 31

Information Security Incident Response Policy & Procedures
• Credit or Debit Card Number and Access Code (e.g., PIN or Password)
• Personal Medical Records
• Unpublished results of research or financial investment strategies
• Intellectual Property (e.g., protected formulas or patents)
UNIVERSITY CUSTOMER
A University Customer is:
• any faculty, student, staff or group affiliated with the University, or
• any department or school of the University, or
• any employee (permanent, temporary and contract personnel; past or present)
3 RD PARTY
A 3 rd party is:
• any entity having a relationship with the University not described as a customer (e.g.,
business partner, research subject, vendor), or
• any external entity initiating contact with the University (e.g., JANET CERT, RIAA , target of
DDoS attack, student applicant, member of the general public).
TEAM OBJECTIVES
The IS IRT Chair (Director of Information Services) or delegated Incident Manager (IM) will lead the
IRT team; the IRT’s objective is to:
1. Co­ordinate and oversee the response to Incidents in accordance with the
requirements of UK Legislation, JANET and University policy;
2. Minimise the potential negative impact to the University, Customers and and 3 rd
Parties as a result of such Incidents;
3. Where appropriate, inform the affected Customer and 3 rd Party of action that is
recommended or required on their behalf;
4. Restore services to a normal and secure state of operation.
5. Provide clear and timely communication to all interested parties.
RESPONSIBILITIES
Page 7 of 31

Information Security Incident Response Policy & Procedures
To ensure an appropriate and timely execution of this protocol, the IRT Chair (or designated IRT
IM) is required to:
1. Confirm the occurrence of an Information Security Incident requiring the execution
of this protocol.
2. Confirmation activities include but are not limited to:
• examination or analysis of anomalies or untoward events
• review of system logs or audit records
• direct conversation with Customer, 3rd Party, Service Desk, IS personnel,
“on call” engineer, IRT members or others having information about the event
collection of any evidence supportive of the event
• Supervise and direct the consistent, timely, and appropriate response to an
Information Security Incident
• Provide appropriate communication to parties having a vested interest in
the incident.
• Offer support to the Customer or 3 rd Party as appropriate until the Incident
is resolved.
• Conduct a Post‐Incident Review (PIR).
• Maintain the procedures contained in this document.
CRITICAL INCIDENT RESPONSE TEAM COMPOSITION
The IRT consists of a Primary Team and if deemed necessary a Secondary Team. Each member of
the Primary Team will designate an Alternate member to participate if the Primary Member is
unavailable. See Appendix C ­ “Primary and Alternate Contact List ­” for a listing of individual
members. The Primary Team will consist of representatives from the following areas:
A1. PRIMARY TEAM (REQUIRED)
1. Director of IS (Chair)
2. Senior Service Delivery Manager (SSDM)
3. University Information Group Manager (UIG)
4. University Applications Group Manager (UAG)
5. IS Technical Personnel
Page 8 of 31

Information Security Incident Response Policy & Procedures
6. Security Architect (SA)
7. Change Manager (CM)
8. Administration Support
A2. SECONDARY TEAM (AS REQUIRED)
The circumstances surrounding each incident may differ and require personnel with expertise or
skills beyond that of the Primary Team. Members of the Primary Team will determine what, if any,
additional resources are required and a Secondary Team may be established with:
• Individuals with decision‐making authority identified to have a vested interest in the
resolution of the incident.
• Individuals identified as subject matter experts or having skills required for resolution of
the incident.
Information Security Coordinators representing an affected Customer or 3 rd Party, or known to
have an established relationship with an affected Customer or 3 rd Party may be seconded to the
Secondary Team.
ACCOUNTABILITY
Individual IRT members are accountable to the IS Senior Management Team and University
Directorate for the timely and effective execution of this policy, procedures and associated
activities.
REPORTING A SECURITY INCIDENT
Anyone receiving notification of an Incident must contact the Service Desk immediately.
Service Desk personnel will provide the customer and the user with a Single Point of Contact
(SPOC). The Service Desk own the Incident Management Process and as such the will be
responsible for monitoring and escalation according to all SLA’s
• The e‐mail addresses is servicedesk@port.ac.uk
Note: The email address may be used but is less effective than the direct notification to the Service
Desk via the telephone.
• Telephone Ext: 3265
Service Desk personnel use scripts (e.g., lists of predetermined questions) to assist in problem
determination and resolution. These scripts assist support personnel to identify those events that
may be classified as an Information Security Incident. Additional information may be found in
Appendix D – “Guidelines for Service Desk and IS Personnel”.
Page 9 of 31

Information Security Incident Response Policy & Procedures
ACTIVATION OF TEAM
Once the IRT Lead has determined an Information Security Incident has occurred, the IRT Lead or
delegated IRT IM will activate this protocol within 24 hours after Incident determination.
Notification to the Primary Team member or Alternate should occur via a direct communication by
telephone or face‐to‐face contact. Voice‐mail and e‐mail are not considered direct notification.
Respective Primary and Alternate Team members should exchange information frequently to
ensure their knowledge of the information security incident is current.
Consult Appendix – E “Notification Tree” for details and notification assignments.
KEY COMPONENTS OF CRITICAL INCIDENT RESPONSE PROTOCOL
The Critical Incident Response Protocol consists of five key components:
• Assessment
• Notification/Communication
• Containment,
• Corrective Measures
• Closure
ASSESSMENT
The IRT Lead or IRT IM will determine the category and severity of the Incident and undertake
discussions and activities to best determine the next best course of action, i.e., decide if protocol
execution is required. Appendix F ­ “Critical Incident Assessment Checklist” is used in the initial
assessment process conducted by the IRT Lead. Once the IRT is assembled, the Assessment
Checklist is executed and reviewed to ensure all pertinent facts are established. All discussions,
decisions and activities are to be documented.
NOTIFICATION/COMMUNICATION
Designated persons will take action to notify the appropriate internal and external parties, as
necessary.
INTERNAL NOTIFICATION (WITHIN THE UNIVERSITY)
All Internal Notification and communication must be approved by the Primary IRT Lead or
IRT IM.
Primary Team members notify Alternate Team members (and vice‐versa). The IRT will notify
members of Secondary Team (if assembled).
Page 10 of 31

Information Security Incident Response Policy & Procedures
1. IRT Lead will notify University Administration and IT Committee of the Incident and provide
ongoing status.
2. IRT Lead will issue or direct all “sensitive” internal communications.
3. Service Desk will issue all public internal communication.
EXTERNAL NOTIFICATION (OUTSIDE THE UNIVERSITY)
All External Notification and communication must be approved by the Directorate.
1. 3 rd Party ‐ IRT Lead or IRT IM and the Directorate will establish communication with any 3 rd
Party, as appropriate for the circumstance.
2. Law Enforcement ‐ Security Architect in consultation with IRT Lead or IRT IM to notify Law
Enforcement as appropriate.
3. Regulatory ‐ Directorate notifies the appropriate regulatory agencies.
4. IRT members will assist in determining if other parties should be notified (e.g. Sun Security).
5. Media Interest ‐ Directorate and University Public Relations will determine if, how and when
media interest should be notified, and respond to all inquiries from the media.
6. Directorate will determine if government notification (e.g., Information Commissioner) is
required and take appropriate action.
7. Other affected parties – The IRT will determine if there are other parties of interest, with
communications issued accordingly (e.g., JANET CERT)
CUSTOMER NOTIFICATION
1. Customers should be informed that the Incident has been reported, recorded and an
investigation underway.
2. The Customer shall be kept abreast of the status of the Incident investigation in a timely
manner.
3. The Customer shall be notified of results, closure of investigation, and recommendations.
STATUS
1. IRT Lead assumes responsibility for preparing and issuing timely communication to IRT
members, Administration and other interested parties.
2. Communications may include meetings, video conferencing, teleconferencing, e‐mail,
telephone/messaging, voice recordings or other means as deemed appropriate.
Page 11 of 31

Information Security Incident Response Policy & Procedures
3. Frequency and timeliness of communications will be established and revised throughout
the life cycle of the incident.
CONTAINMENT
The IRT will determine and cause to be executed the appropriate activities and processes required
to quickly contain and minimise the immediate impact to the University, Customer and 3 rd Party.
Recommended activities addressing Unauthorised Access and Unauthorised Acquisition are
described in Appendix G ­ “Incident Containment Activities”.
Containment activities are designed with the primary objectives of:
• Counteract the immediate threat
• Prevent propagation or expansion of the incident
• Minimise actual and potential damage
• Restrict knowledge of the incident to authorised personnel
• Preserve information relevant to the incident
CORRECTIVE MEASURES
The IRT will determine and cause to be executed the appropriate activities and processes required
to quickly restore circumstances to a normal (secure) state. Recommended activities addressing
Unauthorised Access and Unauthorised Acquisition are described in Appendix H­ “Corrective
Measures”.
Corrective measures are designed with the primary objectives of:
• Secure the processing environment
• Restore the processing environment to its normal state
CLOSURE
The IRT will stay actively engaged throughout the life cycle of the Information Security Incident to
assess the progress/status of all containment and corrective measures and determine at what point
the incident can be considered resolved. Recommendations for improvements to processes,
policies, procedures, etc. will exist beyond the activities required for incident resolution and should
not delay closing the Information Security Incident.
REQUIRED DOCUMENTATION FOR CRITICAL INCIDENT RESPONSE
MEETINGS
All Incident activities, from receipt of the initial report through Post‐Incident Review, are to be
documented. The IRT Lead is responsible for ensuring all events are recorded, assembling these
Page 12 of 31

Information Security Incident Response Policy & Procedures
records in preparation and performance of the post‐incident review, and ensuring all records are
preserved for review. IRT members may be employed in these efforts.
1. General overview of the Incident
Summary of the Incident providing a general description of events, approximate timelines, and
parties involved, resolution of the incident, external notifications required and
recommendations for prevention and remediation.
2. Detailed review of the Incident.
Description of Incident events, indicating specific timelines, personnel involved, hours spent on
various activities, impact to Customer, 3 rd Party and user communities (e.g., system not
available, business continuity issues), ensuing discussions, decisions and assignments made,
problems encountered, successful and unsuccessful activities, notifications required or
recommended, steps taken for containment and remediation, recommendations for prevention
and remediation (short‐term and long‐term), identification of policy and procedure gaps,
results of post‐incident review.
3. Retention.
All relevant documentation will be retained by IRT Lead for archival in a central repository.
Access to the documentation and repository is typically restricted to IRT membership.
POST‐INCIDENT REVIEW (PIR)
A review of Information Security Incident‐related activities is a required element of this policy. All
members of the IRT primary and secondary teams are recommended participants.
Discussion
The IRT Lead or IRT IM will host a PIR after each Incident has been resolved; this discussion should
be scheduled within 2‐3 weeks of the Information Security Incident’s remediation. The review is an
examination of the Incident and all related activities and events. All activities performed relevant
to the Incident should be reviewed with the aim of improving and honing the over‐all incident
response process.
1. Recommendations
The IRT’s recommendations on changes to policy, process, safeguards, etc. are both an input to
and by‐product of this review. “Fix the problem, not the blame” is the focus of this activity. All
discussions, recommendations and assignments are to be documented for distribution to the
IRT and follow‐up by IRT Lead.
2. Follow­up
The IRT Lead will follow‐up with the Client and 3 rd Party or other parties, as required and
appropriate.
Page 13 of 31

Information Security Incident Response Policy & Procedures
GLOSSARY
The following terms should be used to assure commonality of reporting:
Confidentiality. “Confidentiality provides the ability to ensure that the necessary level of security
is enforced at each junction of data processing and prevention of unauthorised disclosure. This
level of confidentiality should prevail while data resides on systems and devices within the
network, as it is transmitted, and once it reaches its destination.” Harris 2003,p55
Integrity. “Integrity is upheld when the assurance of accuracy and reliability of information and
systems is provided, and unauthorised modification of data is prevented.” Harris 2003, p. 55.
Availability. “Systems and networks should provide adequate capacity in order to perform in a
predictable manner with an acceptable level of performance.” Harris 2003, p. 54.
Vulnerability. “Vulnerability is a software, hardware, or procedural weakness that may provide an
attacker the open door he is looking for to enter a computer or network and have unauthorised
access to resources within the environment. Vulnerability characterises the absence or weakness
of a safeguard that could be exploited”. Harris 2003, p. 56.
Threat. “A threat is any potential danger to information systems. The threat is that someone or
something will identify a specific vulnerability and use it against the organisation or individual”.
Harris 2003, p. 56.
Risk. “A risk is the likelihood of a threat agent taking advantage of vulnerability. A risk is the
possibility and probability that a threat agent will exploit vulnerability”. Harris 2003, p. 56.
Exposure. “An exposure is an instance of being exposed to losses from a threat agent.
Vulnerability can cause an organisation to be exposed to possible damages”. Harris 2003, p. 56.
Countermeasure. “A countermeasure, or safeguard, mitigates a potential risk. A countermeasure
is a software configuration, hardware, or procedure that eliminates vulnerability or reduces the risk
of a threat agent from being able to exploit vulnerability”. Harris 2003, p. 57.
Page 14 of 31

Information Security Incident Response Policy & Procedures
APPENDICES
A – Process Flow
B – Incident Severity and Criticality Level
C – Primary and Alternate Contact List
D – Guidelines for Service Desk and IS Personnel
E – Notification Tree
F – Incident Assessment Checklist
G – Incident Containment Activities
H – Corrective Measures
APPENDIX A ‐ PROCESS FLOW
Page 15 of 31

Information Security Incident Response Policy & Procedures
Page 16 of 31

Information Security Incident Response Policy & Procedures
APPENDIX ‐ B INCIDENT SENSITIVITY AND CRITICALITY LEVELS
SCOPE
It is important that the SPOC provide consistent and timely response to the customer, and that sensitive
information is handled appropriately. This document provides the guidelines needed for IRT Incident
Managers (IM) to classify the case category, sensitivity level, and criticality level for each IRT case. This
information will be entered into the IRIMS when a case is created. Consistent case classification is required
for the IRT to provide accurate reporting to management on a regular basis. In addition, the classifications
will provide IRT IM’s with proper case handling procedures and will form the basis of SLA’s between the IRT
and IS Service Delivery and other university clients.
INCIDENT CATEGORY AND SENSITIVITY LEVELS
All incidents managed by the IRT should be classified into one of the categories listed in the table below:
Incident
Sensitivity* Description
Category
Denial of service S3 • DOS or DDOS attack.
Forensics S1 • Any forensic work to be done by IRT.
Compromised
Information
S1 • Attempted or successful destruction, corruption, or disclosure of sensitive university
information or Intellectual Property.
Compromised Asset S1, S2 • Compromised host (root account, Trojan, rootkit), network device, application, user
account. This includes malware‐infected hosts where an attacker is actively
controlling the host.
Unlawful activity S1 • Theft / Fraud / Human Safety / Child Pornography. Computer‐related incidents of a
criminal nature, likely involving law enforcement or Loss Prevention.
Internal Hacking S1, S2, S3 • Reconnaissance or Suspicious activity originating from inside the university network,
excluding malware.
External Hacking S1, S2, S3 • Reconnaissance or Suspicious Activity originating from outside the university network
(partner network, Internet), excluding malware.
Malware S3 • A virus or worm typically affecting multiple university devices. This does not include
compromised hosts that are being actively controlled by an attacker via a backdoor or
Trojan. (See Compromised Asset)
Email S3 • Spoofed email, SPAM, and other email security‐related events.
Consulting S1, S2, S3 • Security consulting unrelated to any confirmed incident.
Policy Breaches S1, S2, S3 • Sharing offensive material, sharing/possession of copyright material.
• Deliberate violation of Information Security policy.
• Inappropriate use of university asset such as computer, network, or application.
• Unauthorised escalation of privileges or deliberate attempt to subvert access
controls.
* ‐ Sensitivity will vary depending on circumstances.
SENSITIVITY CLASSIFICATION EXAMPLES
Page 17 of 31

Information Security Incident Response Policy & Procedures
The IRT should always apply the “need to know” principle when communicating case details with other
parties. The sensitivity matrix below helps to define “need to know” by classifying cases according to
sensitivity level. The ‘Required’ column defines the parties that “need to know” for a given sensitivity level.
The ‘Optional’ column defines the other parties that may be included on communications, if necessary.
Typically the SPOC who own the incident will initially determine the sensitivity level. In some cases it will be
appropriate for the SPOC to work with the customer to determine the sensitivity level and then if deemed
necessary escalate the incident to the IRT.
Sensitivity Classification
Sensitivity
Level
S1
S2
S3
Sensitivity
Level
Definition
Extremely
Sensitive.
Sensitive.
Not Sensitive.
Typical Incident Categories
Global Investigations
Initiated
Forensics Request
Destruction of property
Compromised asset
Compromised Information
Unlawful activity
Inappropriate use of
property
Policy violations
External Hacking
Internal Hacking
Unauthorised Access
Denial of service
Virus / Worm
Email
Required On Case
Communications **
IRT Lead or IRT IM,
Security Architect or
SPOC
IRT Lead or IRM IM,
Security Architect ,
SPOC
IRT Lead or IRT IM, ,
Security Architect or
SPOC
Optional On Case
Communications **
JANET CERT
JANET CERT
OWNERS
ANY
OWNERS
ANY
IRIMS Access
IRT Lead or IRT IM
Security Architect
or SPOC
Security Architect
or SPOC
Service Desk
personnel with
access to IRIMS
Security Architect
Definitions:
• SPOC: The service delivery single point of contact, the person that initiated the case with the IRT. This is the person in the Service
Desk team that initiated a case with the IRT.
• IRT: This includes the dedicated IRT members, and the IRT Lead/IRT IM handling the case.
• OWNERS: The owners of the affected device/application (system administrator, webmaster, etc.)
• ANY: Any other relevant parties that may be affected including various university customers. It is left to the discretion of the IRT IM to
determine who should be included.
• IRIMS: Incident Response Information Management System,
Notes:
** “Case Communications” include the following: Initial email from SPOC to customer, periodic case reports to customer, and final case report to
customer. It is not necessary to include these parties on all interim communications that occur throughout the life of a case, just the case updates
and summary.
CRITICALITY CLASSIFICATION
Page 18 of 31

Information Security Incident Response Policy & Procedures
The criticality matrix defines the minimal customer response time and ongoing communication requirements
for a case. The criticality level should be entered into the IRIMS when a case is created, and it should not be
altered at any point during the case lifecycle except when it was incorrectly classified in the first place.
Typically the SPOC will determine the initial criticality level and in some cases it will be appropriate to
escalate to the IRT Lead or IRT IM to work with the SPOC and the customer to determine the criticality level.
Level
C1
Criticality Level
Definition
Incident affecting critical
systems or information
with potential to be
revenue or customer
impacting.
Typical Incident
Categories
Denial of service
Compromised Asset
(critical)
Internal Hacking
(active)
External Hacking
(active)
Virus / Worm
(outbreak)
Destruction of property
(critical)
Criticality Classification
Initial
Respon
se Time
60
Minutes
Ongoing
Response
(Critical Phase)
IRT Lead or IRT
Incident Manager
assigned to work
case on 24x7 basis.
Ongoing
Response
(Resolution
Phase)
IRT Incident
Manager
assigned to work
on case during
normal business
hours.
Ongoing
Communication
Requirement
Case update sent to
appropriate parties
on a daily basis
during critical
phase. If IRT
involvement is
necessary to
restore critical
systems to service
then case update
will be sent a
minimum of every
2 hours.
Case update sent to
appropriate parties
on a weekly basis
during resolution
phase.
C2
Incident affecting noncritical
systems or
information, not revenue
or customer impacting.
Employee investigations
that are time sensitive
should typically be
classified at this level.
C3 Possible incident, noncritical
systems.
Incident or employee
investigations that are
not time sensitive.
Long‐term investigations
involving extensive
research and/or detailed
forensic work.
Internal Hacking (not
active)
External Hacking (not
active)
Unauthorised access.
Policy breaches
Unlawful activity.
Compromised
information.
Compromised asset.
(non‐critical)
Destruction of property
(non‐critical)
Email
Forensics Request
Inappropriate use of
property.
Policy breaches.
4 Hours IRT Lead or IRT
Incident Manager
assigned to work
case on 24x7 basis.
48 Hours Case is worked as
IRT time/resources
are available.
IRT Incident
Manager
assigned to work
on case during
normal business
hours.
Case is worked as
IRT
time/resources
are available.
Case update sent to
appropriate parties
on a daily basis
during critical
phase.
Case update sent to
appropriate parties
on a weekly basis
during
resolution phase.
Case update sent to
appropriate parties
on a weekly basis.
Page 19 of 31

Information Security Incident Response Policy & Procedures
e.g. A compromised root account on a Sun Solaris Server containing personnel information would be:
• Compromised Asset ­ Sun Solaris Server
• Sensitivity ­ S1
• Criticality Classification ­ C1
Definitions:
• Initial Response Time – This specifies the maximum amount of time that should elapse before the Service
Desk responds to the customer/user. Again, this is the maximum amount of time. In most cases the IRT
Lead or IRT IM will respond sooner than the specified response time. At a minimum, the following should
occur within this timeframe:
•
1. Initial assessment and triage.
2. Case classification is determined.
3. The case will be entered into the IRIMS.
4. The case will be owned by the Service Desk
5. An email will be sent to the customer. This is the initial “we have your case” email. This email will
include various information ( to be defined in another document ) such as the date/time of the
request, IRT case number, the name, phone, and email of the IRT Lead or IRTM IM, a SPOC
escalation contact, the criticality and sensitivity level of the case, and an indication of when the
customer will receive case updates. Ideally, the IRIMS will generate this email automatically when a
case is entered into the system.
• Ongoing Response Requirement ‐ This specifies the level of service that the customer will receive from the
IRT.
• Ongoing Communication Requirement – This specifies the frequency in which communications with the
customer should occur throughout the case lifecycle. These are the minimum requirements and
communications may occur more frequently as required.
Incident Phases:
Incident Phase Description Typical Activities
Critical Phase
The period of time in the case lifecycle when active incident
response is required in order to ensure the successful
resolution of the case. Typically this includes system or service
outages, and/or urgent evidence preservation.
Detection, assessment, triage, containment,
evidence preservation, initial recovery
Resolution Phase
The period of time in the case lifecycle when active incident
response is not required to successfully resolve the case.
Evidence collection, analysis and investigation,
forensics, remediation, full recovery, post‐mortem.
Notes:
The IRIMS should be modified to include a drop‐down selection for incident phase ( ‘Critical’, ‘Resolution’, ‘N/A’ ). For
cases that are classified as C1 or C2 this field will be set to Critical when the case is opened, and will be reset to
‘Resolution’ at the appropriate time in the case lifecycle. For cases that are not time‐sensitive (typically C3) the SPOC
will set this field to ‘N/A’. Having this distinction will allow IRT personnel and IS Management to easily distinguish
between cases that are critical and active from those that are not being actively worked.
Page 20 of 31

Information Security Incident Response Policy & Procedures
APPENDIX D ‐ GUIDELINES FOR SERVICE DESK AND IS STAFF
PRIMARY OBJECTIVE
The primary objective is to determine if the problem being reported is a security incident. In most
instances, the problem being reported will not constitute an incident as defined within the policy ‐
(see Definitions – Information Security Incident ‐ Categories).
No set of questions will address every circumstance; previous experience with an individual and
intuition may be relied upon to help determine if an incident has occurred. Service Desk personnel
are accountable for asking the questions about an incident, making a reasonable attempt at
determining if an incident has occurred, recording facts and responses to questions, and forwarding
pertinent information to the responsible parties.
PROBLEM REPORTING
Familiarity with the policy definitions and glossary will assist support personnel in making a
determination if a security incident has occurred. Individuals reporting problems and/or incidents
should be informed as to the reason for the questions (i.e., the University is attempting to
determine if sensitive data is at risk or compromised) and all individuals should be encouraged to
openly discuss the problem being reported. Any information provided by an individual that helps
in the determination is of considerable value; the individual’s cooperation is critical, greatly
appreciated and should be recognised.
INQUIRIES
For those individuals who may be reporting a security incident, questions that might be asked
include but are not limited to:
• Were Network ID’s and/or passwords accessed or released?
• Were medical records of individuals present or accessed?
• Were credit card numbers or financial information disclosed?
• Did physical theft of computer equipment occur?
• Was “foreign” or unauthorised equipment connected to the network?
DISCOVERY AND REPORTING
If the answers to the inquiries indicate that an incident may have occurred, service desk staff
personnel should assume that an incident has actually occurred and perform the following
activities:
• Obtain and record the contact information for the individual reporting the problem
(name, telephone numbers, e­mail address)
• Record relevant information about the incident (e.g., time/date of suspected
occurrence, type of information compromised, location of the compromise)
Page 21 of 31

Information Security Incident Response Policy & Procedures
• Inform the individual to expect contact from a member of the Incident Response
Team
• Request the individual to treat the incident as a confidential matter
• Contact a member of the IRT team or “on call” IS IRT IM for further assistance.
ESCALATION
The Service Delivery Team SPOC is responsible for making an early determination if an incident has
occurred or might be indicated. If the SPOC believes an incident has occurred, might be indicated,
or unsure, the IRT Lead or IRT Incident Manager should be contacted immediately, using the
department’s notification procedures.
Page 22 of 31

Information Security Incident Response Policy & Procedures
APPENDIX E ‐ NOTIFICATION TREE
Page 23 of 31

Information Security Incident Response Policy & Procedures
APPENDIX F ‐ INCIDENT ASSESSMENT CHECKLIST
The activities described in this checklist are designed to assist in the initial assessment process
performed and/or conducted by the Service Desk SPOC.
Completion of this checklist is essential for any incident that calls for the execution of the IS
Incident Response Procedures. Once the IS IRT is assembled, the Assessment Checklist is reviewed
for completion to ensure all pertinent facts have been established.
A. DESCRIPTION OF INCIDENT ­ DATA RELEVANT TO THE INCIDENT SHOULD BE
COLLECTED FOR USE IN THE PROCESS OF INCIDENT DETERMINATION.
A1. Record the current date and time.
A2. Provide a brief description of the Incident.
A3. Who discovered the Incident? Provide name and contact information.
A4. Indicate when the incident occurred and when it was discovered.
A5. How was the Incident discovered?
A6. Describe the evidence that substantiates or corroborates the Incident (e.g., eye‐witness, timestamped
logs, screenshots, video footage, hardcopy, etc.).
A7. Identify all known parties with knowledge of the Incident as of current date and time.
A8. Have all parties with knowledge of the Incident been informed to treat information about the
Incident as “sensitive or confidential”?
B. TYPES OF INFORMATION, SYSTEMS AND MEDIA ­ PROVIDE INFORMATION ON THE
NATURE OF THE DATA THAT IS RELEVANT TO THE INCIDENT.
B1. Provide details on the nature of the data (e.g., student information, research data, personnel
information etc.).
B2. Does the information (if compromised) constitute a breach of of regulatory requirements (e.g.,
Data Protection or University policy? Describe what is known.
B3. Was the compromised information maintained by a University Client or a 3 rd Party? Provide
details.
B4. How was the information held? Identify the types of information systems and/or the media on
which the information was stored (e.g., hardcopy, laptop, CD‐Rom, etc.).
Page 24 of 31

Information Security Incident Response Policy & Procedures
B5. If the information was held electronically, was the data encrypted or otherwise disguised or
protected (e.g., redacted, partial strings, password required, etc.)? If so, describe measures taken.
B6. If a customer held the information:
‐ Establish the customer point of contact. (e.g. JANET )
‐ Assign responsibility to IRT member to contact the customer.
B7. If a 3 rd Party held the information:
‐ Identify the individual within the University who best represents the 3 rd Party. If there is no
suitable University contact, an IRT member will be assigned responsibility for directly contacting
the 3 rd Party.
‐ Assign responsibility to IRT member to contact that individual.
‐ IRT member will work with the University contact or 3 rd Party to obtain a copy of any contract or
confidentiality agreement and ascertain what knowledge of the Incident the 3 rd Party might have
and what action if any has been taken.
B8. Who currently holds evidence of the Incident? Provide name and contact information.
B9. What steps are required or being taken to preserve evidence of the Incident? Describe.
C. RISK/EXPOSURE ­ ATTEMPT TO DETERMINE TO WHAT EXTENT RISK AND/OR
EXPOSURE IS PRESENTED BY THIS INCIDENT.
C1. Can we reasonably determine the risk or exposure?
C2. To what degree are we certain that the data has or has not been released?
C3. Do we have contact with someone who has “firsthand” knowledge of the circumstance (e.g., the
owner of a stolen laptop)? Provide name and contact information.
C4. What firsthand knowledge have we determined? Describe what is known.
C5. Can we identify and do we have contact with the party that received the data or caused the
compromise? Describe what is known.
C6. Identify the impacted parties, if possible. Are they University Customers or 3 rd Parties? Provide
estimated number, if known.
C7. What is the risk or exposure to the University? Describe.
Page 25 of 31

Information Security Incident Response Policy & Procedures
C8. What is the risk or exposure to the Customer? Describe.
C9. What is the risk or exposure to the 3 rd Party? Describe.
C10. Can we determine to what extent the media may know of this Incident? Describe.
D. NEXT STEPS ‐ DETERMINE WHAT INFORMATION OR ACTION IS REQUIRED TO BETTER
ASSESS OR ADDRESS THIS INCIDENT.
D1. Do we have enough information to establish the category and severity of the Incident?
‐ If “yes”, declare the Incident category and severity.
‐ If “no”, describe what else might be required.
D2. If additional data collection data is required, assign responsibility to IRT member for collection
and reporting to IRT.
D3. Is there any deadline or reporting requirement (self‐imposed or regulatory) we need to
address? Provide details.
D4. Based on current knowledge, do we require resources of the Secondary Team? If so, determine
the makeup and assign responsibility for contact to IRT members.
D5. What communications need to be established? Provide details.
D6. Are there any immediate issues that have not been addressed? Describe.
D7. Recap all work and responsibility assignments.
D8. When do we meet again to follow‐up? Provide details.
Page 26 of 31

Information Security Incident Response Policy & Procedures
APPENDIX G ‐ INCIDENT CONTAINMENT ACTIVITIES
The IRT will determine and execute the appropriate activities and processes required to quickly
contain and minimise the immediate impact to the University, Customer and 3 rd Parties.
Containment activities are designed with the primary objectives of:
• Counteract the immediate threat
• Prevent propagation or expansion of the incident
• Minimise actual and potential damage
• Restrict knowledge of the incident to authorised personnel
• Preserve information relevant to the incident
A. CONTAINMENT ACTIVITIES ­ UNAUTHORISED ACCESS
ACTIVITIES THAT MAY BE REQUIRED TO CONTAIN THE THREAT PRESENTED TO
SYSTEMS WHERE UNAUTHORISED ACCESS MAY HAVE OCCURRED.
A1. Disconnect the system or appliance from the network or access to other systems.
A2. Isolate the affected IP address from the network.
A3. Power off the appliance(s), if unable to otherwise isolate.
A4. Disable the affected application(s).
A5. Discontinue or disable remote access.
A6. Stop services or close ports that are contributing to the incident.
A7. Remove drives or media known or suspected to be compromised.
A8. Where possible, capture and preserve system, appliance and application logs, network flows,
drives and removable media for review.
A9. Notify IRT of status and any action taken.
Page 27 of 31

Information Security Incident Response Policy & Procedures
B. CONTAINMENT ACTIVITIES ­ UNAUTHORISED ACQUISITION
ACTIVITIES THAT MAY BE REQUIRED TO CONTAIN THE THREAT PRESENTED TO
ASSETS WHERE UNAUTHORISED ACQUISITION MAY HAVE OCCURRED.
B1. Identify missing or compromised assets.
B2. Gather, remove, recover and secure sensitive materials to prevent further loss or access.
B3. Power down, recycle or remove equipment known to be compromised.
B4. Where possible, secure the premises for possible analysis by local management and law
enforcement.
B5. Gather and secure any evidence of illegal entry for review by local management and law
enforcement.
B6. Where possible, record identities of all parties who were a possible witness to events.
B7. Preserve camera logs and sign‐in logs for review by local management and law enforcement.
B8. Notify IRT of disposition of assets and any action taken.
Page 28 of 31

Information Security Incident Response Policy & Procedures
APPENDIX G ‐ PRIMARY AND ALTERNATE CONTACT LIST
Department or
Function
Director of
Information
Services
University
Applications
Group
University
Systems Group
University Mobile
Communications
Group
Security Architect
Primary Contact
Andrew Minter
Peter Datchens
Julian Lintell‐Smith
Robert Cox
Nigel Jeffries
Alternate Contact
Dave Rowen
Martin McNaught
Administration Sharon Cole Sandy Wells
IS Technical
Mike Meredith , Dave Early, James
Holland
(others as required)
Change Management
Service Delivery
Jackie Dwyer
Dave Gratton
In the event of an IRT Team member not being available then their role must be delegated by
the IRT Chair or IRT IM
Page 29 of 31

Information Security Incident Response Policy & Procedures
APPENDIX H ‐ CORRECTIVE MEASURES
The IRT will determine and cause the execution of the appropriate activities and processes
required to quickly restore circumstances to a normal secure state.
Corrective measures are designed with the primary objectives of:
• Secure the processing environment
• Restore the processing environment to its normalized state
A. CORRECTIVE MEASURES – UNAUTHORISED ACCESS
ACTIVITIES THAT MAY BE REQUIRED TO RETURN CONDITIONS FROM UNAUTHORISED
ACCESS TO A NORMAL AND SECURE PROCESSING STATE.
A1. Change passwords on all local user and administrator accounts or otherwise disable the accounts
as appropriate.
A2. Change passwords for all administrator accounts where the account uses the same password
across multiple appliances or systems (servers, firewalls, routers).
A3. Re image systems to a secure state.
A4. Restore systems with data known to be of high integrity.
A5. Apply OS and application patches and updates.
A6. Modify access control lists as deemed appropriate.
A7. Implement IP filtering as deemed appropriate.
A8. Modify/implement firewall rule sets as deemed appropriate.
A9. Ensure anti‐virus is enabled and current.
A10. Make all personnel “security aware”.
A11. Monitor/scan systems to ensure problems have been resolved.
A12. Notify IRT of status and any action taken.
B. CORRECTIVE MEASURES – UNAUTHORISED ACQUISITION
PAGE 30 OF 31

Information Security Incident Response Policy & Procedures
ACTIVITIES THAT MAY BE REQUIRED TO RETURN CONDITIONS FROM AN UNAUTHORISED
ACQUISITION TO A NORMAL AND SECURE PROCESSING STATE.
B1. Retrieve or restore assets where possible.
B2. Store all sensitive materials in a secure manner (e.g., lockable cabinets or storage areas/container).
B3. Install/replace locks and issue keys only to authorised personnel.
B4. Restore security devices and/or apparatus to working condition.
B5. Remove and retain unauthorised equipment from network/area.
B6. Implement physical security devices and improvements (e.g., equipment cables, alarms) as deemed
appropriate.
B7. Make all personnel “security aware”.
B8. Notify IRT of status and any action taken.
PAGE 31 OF 31