Cyber Incident Response Plan (draft)

This document is the key document for the Act step of the University’s Cybersecurity Strategy Framework. It is also used in the Report phase, which leads to the Prevent and Enhance phases. It provides:

• definitions and processes to determine the type of event
• procedures in the event of an incident
• an overview of communication(s) required
• indicators of regulatory and legal requirements for incidents
• mechanisms for organisational learning

Related documents and policies

• Cybersecurity Strategy Framework
• Data Breach Response Plan (DBRP)
• ACSC Cyber Incident Response Plan Guidance

Definitions

Incident progression

The following definitions are based on the ACSC definitions. The progression of an incident flows as follows:

Threat -> Event ( -> alert ) -> Incident

• Threat - “circumstance or event with the potential to harm systems or information”
• Event - “an occurrence of a system, service or network state indicating a possible breach of security policy, failure of safeguards or a previously unknown situation that may be relevant to security. A cyber security event has the potential to become, but is not confirmed to be, a cyber incident.”
• Alert - “a notification generated in response to a deviation from normal behaviour”
• Incident - “an unwanted or unexpected cyber security event, or a series of such events, that have a significant probability of compromising business operations. A cyber incident requires corrective action”

Due to the nature of the organisation, incidents would be categorised by ACSC as between C5 and C3 (see Appendix K)

Common types of Cyber Incidents

The following provides a set of incident types and their definitions. These are considered the most likely to occur to the University are addressed by the CIRP.

Roles and responsibilities

Cyber Incident Response Team (CIRT)

Process

Detect

Due to the nature of the University’s servers and configuration, the majority of incidents will be not be detected by ourselves, but rather through notification by our vendors or service providers.

If there is evidence, through notification, logs, alerts, etc then investigation is necessary.

Investigate

Possible investigation questions include:

• Which system(s) has been affected?
• What was the initial intrusion vector?
• What post-exploitation activity occurred?
  • Have accounts been compromised?
  • What level of privilege were obtained?
  • Does the actor have persistence on the network or device?
• Is lateral movement suspected or known?
  • Where has the actor laterally moved to and how?
• How is the actor maintaining command and control?
• Has data been accessed or exfiltrated and, if so, what kind of data?

Classify

The next step in responding is to classify the incident. The following criteria are used in that determination:

• Is a critical system offline? Where critical refers to:

  • Authentication service
  • Cloud storage of University documents
  • Learning Management System
  • Student Management System
  • Online Library services
  • Staff data system

• What is the scope of staff impacted? (individual, group, all)

• What is the scope of students impacted? (individual, group, all)

• Is there a high likelihood of a data breach of student or staff personal or sensitive data?

• What is the likely financial impact?

• What is the likely impact to the University’s reputation?

• Rate the incident as: Critical, High, Medium, or Low

Act

Containment

Documentation

For an incident classified as Critical or High For an incident classified as Medium or Low

Evidence Collection

Remediation to resolve the incident

• Do we Contain, Eradicate or Recover?
• Who will act to do this?
• What resources need co-ordination to achieve this?

Report

• See the reporting section below
• An incident report is to be written

Incident report

The following information is to be included in the Post-incident Report:

• Issue
• Impact
• Response
• Communications
• Known impacts
• Future avoidance

Prevent

• Does anything need to be updated in this Cyber Incident Response Plan or the Data Breach Response Plan?
• Could any form(s) of training reduce the impact of a similar incident in the future?
• What in the ‘future avoidance’ section of the Post-incident Report can be actioned?

Enhance

• Would any additional tools, software reduce the impact of a similar incident in the future?
• Could any form(s) of training reduce the impact of a similar incident in the future?

Communications and Reporting

Information on website. Notification to staff and/or students via email.

• Communication to the public and/or media is only to be made by SEMT
• The Media and Communications role works with SEMT to produce the information for release
• The SEMT Chair authorises the publication

Internal Communications

In the event of a major incident

• A brief summary of the incident and business impact
• Actions staff can take to assist (if applicable)
• Business continuity options for staff who are affected by the incident
• Messaging for external stakeholders
• Key points of contact for enquiries
• Expected time-frames for further updates.

External Communications

In the case of a significant incident external parties will likely need to be engaged in order to support our incident response. These may include government agencies, third party incident response, law enforcement and/or sector organisations.

• Stakeholders seeking information about the incident such as customers, government agencies, clients, shareholders, suppliers and/or sector organisations
• Media and the general public
• Other stakeholders, such as insurance providers.

Formal Reporting/Notifications

Legal and Regulatory Reporting

Document Control and Review