• Section 1 - Guidelines
• Audience
• Executive Summary
• Purpose
• Section 2 - Information Security Incident Management Process
• Introduction
• Phase 1:  Preparation
• Phase 2: Detection / Incident Analysis
• Phase 3:  Containment, Eradication and Recovery
• Phase 4:  Post-Incident Activity
• Section 3 - Roles and Responsibilities
• ISIRT Team
• Incident Handlers / Investigators

Section 1 - Guidelines

Audience

(1) The intended audience of this guide are:

1. Individuals / Information Security Incident Response Team (ISIRT)tasked with Information Security incident response and management activities.
2. Individuals that interface with ISIRT.

Executive Summary

(2) This guideline document governs the actions required for reporting, responding and managing information security incidents involving University's ICT services and system resources.

(3) To ensure effective and consistent reporting and handling of such events, an incident response capability is necessary for rapid detection, to minimise loss and destruction, mitigate the weaknesses that were exploited, and to restore University ICT services and systems.

(4) Safe use of the University's ICT services and systems is essential to keep it working effectively. All users of the University’s ICT services and systems have a responsibility to:

1. Minimise the risk of vital or confidential information being lost or falling into the hands of people who do not have the right to see it.
2. Protect the security and integrity of IT systems on which vital or confidential information is held and processed.
3. Report suspected information security incidents promptly so that appropriate action can be taken to minimise harm.

Purpose

(5) The intent of this guideline document is to provide a framework and procedures for managing and responding to information security incidents. Fostering a culture of proactive incident reporting and logging will help reduce the number of security incidents which go unreported and unnoticed, often without resolution.

(6) This document provides guidance to the Information Incident Response Team (ISIRT) and associated stakeholders to better respond to information security events and incidents and provides a structured approach to:

1. Detect, report and assess information security incidents.
2. Respond to and manage information security incidents.
3. Continuously improve incident response as a result of managing information security incidents.

Section 2 - Information Security Incident Management Process

Introduction

(7) Information Security Incident Management is a structured approach, and is composed of four major phases:

1. Preparation:  Policies, ISIRT member nomination, stakeholder notification and ISIRT technology acquisition.
2. Detection / Incident Analysis: Detecting and confirming an Incident has occurred; categorising the Nature of the Incident and then prioritising the incident.
3. Containment, Eradication and Recovery:  Minimising loss, theft of information or service disruption; eliminating the threat and restoring services quickly and securely.
4. Post-Incident Activity: Submitting a formal closure report including lessons learned. This report must also contain recommendations for improvement, mitigation of exploited weaknesses and additional security controls to prevent similar incidents from occurring in the future.

Phase 1:  Preparation

(8) The first phase deals with preparing a team to be ready to handle an incident at short notice. Regardless of the cause of the incident, preparation is the most crucial phase, as it will determine how well the team will be able to respond to the event.

Preparing to handle an Incident

(9) There are several key actions that must be taken care of while responding to an incident:

1. Policies – the University’s Critical Incident Management Policy, Information Security Policy, and Information Technology Conditions of use Policy must readily be available for use as reference.
2. ISIRT Member nomination – Appropriately skilled ISIRT members must selected from employees deemed capable of adequately responding to a security incident, either from the IT services department or any external source.
3. The ISIRT members must be apprised of their responsibilities as a team, and must prepare to undertake the relevant activities to ensure that the ISIRT is operational.
4. The ISIRT will be managed by the Chief Information Officer (CIO), who will oversee and coordinate operations.
5. Stakeholder notification – In cases of Severe and Major Category incidents, ISIRT must immediately send an Incident Notification communication in accordance with applicable policy, legal, regulatory, or contractual requirements.  Refer Critical Incident Management Communication Procedure, for notification to parties outside the University.
6. Technology – Required technology must be acquired to support the information security incident management process. This may include a clean laptop (ie not vulnerable to any network or virus attack that may be involved in the incident), a mobile internet connection (if network access is impacted) and access to copies of necessary documents such as policies and guidelines.

Phase 2: Detection / Incident Analysis

(10) When an incident is reported or assigned to the IT Security team/ISIRT, the team must perform a detailed incident analysis and risk assessment.

(11) The risk analysis considers the range of potential consequences. The risk rating determines the level of risk management required by the University. Consequence and likelihood are combined to produce a risk rating. This is achieved by applying criteria in the Risk Management Matrix to determine the level of risk to the University. These criteria include the following

1. Likelihood of the risk, which reflects how often a risk may occur.
2. Consequence defines the actual/potential impact that would/might occur.

(12) Refer to the University Risk Management Framework for detailed Risk Analysis guidelines to be followed.

(13) Process steps:

1. IT Security shares the Incident Notification with ISIRT team for analysis.
2. The IT Security / ISIRT teams will perform the incident analysis to determine whether or not a security incident has occurred.
3. The ISIRT team will perform a detailed risk analysis of the incident as per the University Risk Management Framework.
4. ISIRT team determines the priority of the incident as per Incident Categorisation, Prioritisation and responds as per Incident SLAs.
5. Thereafter, it assigns the case to Department Representative / Incident Handler for action.
6. Once sufficient details are available, the Department Representative / Incident Handler will take necessary action required for the incident.
7. Where an incident receives a priority of Severe or Major, the University Management must be notified as soon as possible.

Incident Categories

Incident Prioritisation

(14) The ISIRT shall perform an assessment of the incident priority using the factors in the table below.

(15) Given the established priority, the incident will be allocated a Service Level which determines the timelines attached to next steps.

Incident Service Level Agreements (SLA)

(16) The ISIRT team shall ensure that the incidents are managed and responded to as per the below SLA. This SLA applies to the Incident Response commitments for all types of information security incidents. Incident response times vary according to the priority level assigned to the incident.

1. Notification – Initial notification of a suspected incident to ISIRT / IT Security Teams.
2. Contain / Remediate – Maximum time to either contain the threat/exposure or permanently remediate.

Incident

(17) Based on the analysis of the incident category and classification, the information security incident can be addressed in the following ways:

Escalation

(18) Severe and Major category incidents will require escalation so that senior management within the University are made aware of, and may respond accordingly to, serious and potentially serious information security incidents. The Crisis/Escalation Team consists of senior members of the relevant departments of the University. Not all members of the Crisis/Escalation Team will need to be alerted to all information  security incidents immediately.

(19) Refer to the Critical Incident Management Communication Procedure for escalation procedures to be followed for Severe and Major Category incidents.

Phase 3:  Containment, Eradication and Recovery

(20) This phase begins once the suspected event has been classified as a Confirmed Incident. This phase involves identifying the immediate response actions to deal with the information security incident and informing the appropriate team about the required actions. The primary objective is to confine any adverse impact to the University's operations, followed by eradication of the threat and the return of the ICT services and systems to its normal productive state.  

(21) The department representative / incident handler shall manage this phase. Incident containment,eradication and recovery steps may vary based on the incident type, and the Incident Response Responsibility may be split over multiple teams which shall be managed and coordinated by the Incident Handlers.

(22) Incident Handlers may require investigation expertise during the course of a response or must have access to or agreements with third parties with appropriate skill sets to perform investigations.

(23) An appropriate combination of the following actions must be used to complete this phase:

1. Initial containment of the incident:
   1. Acquire, preserve, secure and document evidence.
   2. Confirm containment of the incident.
   3. Further analyse the incident and determine if containment was successful.
   4. Implement additional containment measures, if necessary.
2. Eradicate the incident:
   1. Identify and mitigate all vulnerabilities that were exploited.
   2. The ISIRT team will undertake the necessary activities to resolve the problem, and restore the affected services to their normal state. If external support has been requested, the external bodies will also be involved in resolving the problem.
   3. Remove the components of the systems causing the incident.
3.  Recover from the incident:
   1. Return affected systems and services to a state that is ready for operation.
   2. Confirm that the affected systems and services are functioning normally.

Phase 4:  Post-Incident Activity

(24) This phase takes place once the information security incident has been resolved or closed.

Compile Summary of Actions and Findings

(25) The Incident Handler(s) must document the actions taken during the process. If the incident involved support from external Investigators or Forensic Investigators, their steps and reports must also be documented and shared with the Incident Handler.

(26) The Incident Handle shall collate the details and prepare the Closure report.

Closure Report

(27) The Incident Handler is responsible for documenting an incident report which contains (at the minimum) the following information:

1. Summary of the incident
2. Incident actors
3. Incident handlers
4. Detailed Incident Description
5. Relevant evidences
6. Technical details
7. Eradication actions
8. Conclusion
9. Lessons Learnt

(28) The completed incident report is shared with ISIRT team for review and approval.  Once the incident report is approved, it is ready for circulation to relevant stake-holders report.

Submit Recommendations to Appropriate Management

(29) The IT Security Team (or a designated member of the Incident Response team) delivers recommendations for changes in technology, process or policy to appropriate stakeholders fo the development of a follow-up action plan.

Lessons Learnt

(30) Information security incident management activities are iterative, and thus, it is imperative that regular improvements are made to a number of information security elements over time. These improvements must be proposed on the basis of reviews of the information security incidents.

Section 3 - Roles and Responsibilities

ISIRT Team

(31) The primary function for tracking and managing incidents within the area of defined responsibility rests with this role. ISIRT team shall be the first responders to any incident that is reported. The responsibilities include the following: 

1. Ensure all incidents are appropriated reported, prioritised, categorised, tracked, assigned, responded to and closed with clear documentation.
2. Ensure that all follow-up activities are conducted, e.g. work to strengthen security controls, or weaknesses, that allowed the incident to occur.
3. Ensure incident response is conducted in compliance with this guide.
4. Ensure incident handlers and investigators are assigned and fully supported throughout the Incident Response process,and that they have performed an adequate analysis of the incident.
5. Ensure incidents are handled within the agreed SLA.
6. Review and Approve authority of all incident reports as the need arises.
7. Refer Information Security incidents that may have legal implications to responsible teams for advice and action.
8. Liaison between the CIO office and Legal / Risk Committee on incident matters.

Incident Handlers / Investigators

(32) The main responsibilities of the team are:

1. Ensure all relevant information necessary to understand the incident is gathered.
2. Initiate incident response procedures as outlined in this guide.
3. Instruct other constituents on the response actions that may be required to contain/remediate the incident at hand.
4. Provide periodic status updates to ISIRT team on the incident.
5. Prepare incident closure report and submit to the ISIRT team for reviews.
6. In the course  of the incident response, provide assistance on queries that may be raised.
7. Request, carve, collect and manage relevant artefacts for secure storage as part of the incident response.
8. Close incident tickets are the ISIRT Team has accepted and approved them.
9. Adhere to Incident Response SLAs.