Plans

• 1: Cyber Incident Response Plan (draft)
• 2: Data breach response plan

1 - 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

2 - Data breach response plan

This document defines the University’s Data Breach Response Plan (DBRP). It describes the processes that the University will enact in response to an identified data breach. The plan is based on the Office of the Australian Information Commissioner’s guidance on Data breach preparation and their own Data Breach Response Plan and the Office of the Victorian Information Commisioner guidance document

Related documents, policies and legislation

• Cyber Incident Response plan
• Privacy Act 1988
• Privacy (Tax File Number) Rule 2015
• Privacy and Data Protection Act 2014 (Vic)
• Health Records Act 2001 (Vic)
• the Health Privacy Principles (HPPs) set out in Schedule 1 of the Health Records Act 2001
• Victorian Protective Data Security Framework Business Impact Levels

Definitions

• data breach - an incident where personal information that the University holds is subject to unauthorised access or disclosure, or is lost. This may be through system fault, malicious attack or human error.
• personal information - includes contact (home address, email, phone number), financial (TFN, banking), identity (passport, licence), health and sensitive (religious, political, sexual) information on persons.
• serious harm - may include serious physical, psychological, emotional, financial, or reputational harm. See the OAIC definition of Serious Harm for a list of ‘relevant matters’ that assist in determining this.
• Cyber Incident Response Team (CIRT) - the team identified in the Incident Response plan to respond to Cyber Incidents, including a suspected Data Breach.

Process

The process for responding moves through 5 phases:

1. Raise
2. Contain
3. Assess
4. Notify
5. Review

A potential breach can be discovered or reported through a variety of people - it could be a member of the IT or Student Services Team, a person from the OVC, the University, one of its vendors, one of its College’s staff, a student or member of the public.

1. Raise

If you become aware or are notified of a data breach record as much as possible of the following:

1. the time and date
   • you are being informed
   • the suspected breach was discovered
   • the suspected breach occurred (if different to its discovery)
2. the type of personal information involved (staff, student, academic, research, etc)
3. the
   • mechanism (email, URL, hack, etc)
   • cause (if immediately known - human error, system fault, malicious)
   • extent of the breach (how many names or records), and
   • the context of the affected information and the breach (OVC, college, vendor, etc).

Then immediately notify the IT Manager.

2. Contain

Once a Data Breach form has been received the CIRT will then:

1. Understand the nature of the suspected breach from (a) the report given, and if necessary, (b) their own initial diagnostic work

2. Be able to answer the following key questions:

   1. Is it clear as to how the data breach occurred?
   2. Is the personal information still being disclosed, shared, or lost without authorisation?
   3. Who had/has access to the personal information?
   4. What can be done to secure the information, or stop the unauthorised access or disclosure, and reduce the risk of harm to affected individuals?

3. Act to contain the breach. Depending on the nature of the breach, this may look like:

   • Contacting email recipients asking them to delete the email
   • Changing the configuration of a server or service
   • Asking a website owner to remove or hide page
   • Writing, testing, and deploying a bugfix
   • Contacting a vendor requesting a configuration or code change

4. Produce an initial breach report:

   • as to whether a data breach has or may have occurred
   • an estimate of the seriousness of the data breach or suspected data breach.
   • if one has occurred - steps taken to contain the breach and their result(s)
   • suggested further steps to take to contain the breach
   • any additional action(s)

The seriousness relates to the risk: the type(s) of information, the number of individuals impacted and who had/has access to the information. The type of information is listed under Definitions in increasing likely significance, though that may not automatically be the case.

This report should be produced within two hours of the data breach being raised. The Vice-Chancellor is to then be notified of the breach and sent the report.

3. Assess

The Raise a data breach form submission and the initial report are then assessed to

• evaluate the risks, including potential harm to affected individuals and,
• where possible, take action to remediate any risk of harm.

A more detailed assessment report is then written. This will collate and present the following:

• the date, time, duration, and location of the breach
• the type(s) of personal information involved in the breach
• how the breach was discovered and by whom
• the cause and extent of the breach
• a list of the affected individuals, or possible affected individuals
• the risk of serious harm to the affected individuals
• the risk of other harms.

This assessment is to be reported to the University’s Management and Senior Leadership Teams.

The timeline for assessment is within 30 calendar days after the day the entity became aware of the grounds (or information) that caused it to suspect an eligible data breach.

4. Notify

In this phase the question of ‘who needs to be notified?’ are addressed.

• Determine if other organisations need to be made aware of the breach at this preliminary stage

  • the Australian Cyber Security Centre (ACSC), police/law enforcement, or
  • other agencies or organisations that:
    • may be affected by the breach, or
    • can assist in containing the breach, or
    • can assist individuals affected by breach, or
  • where the University is contractually required or required under the terms of an MOU or similar obligation to notify specific parties.

• Determine whether and how to notify affected individuals.

• Determine whether to escalate the data breach to the response team.

• Convene the response team, if necessary.

• Determine whether the breach has a Business Impact Level (BIL) of 2 or higher

• Notify OVIC of the breach if necessary

• Determine whether the breach is an eligible data breach under the NDB scheme.

• Notify the AIC of the NDB, if necessary (see below)

Notifiable Data Breach (NDB)

The University is an Entity covered by the NDB scheme as

1. we have an annual turnover of more than AU$3 million
2. we are a TFN recipient (in the case of student data)

If there are reasonable grounds to believe an eligible data breach has occurred, the OAIC must promptly notify any individual at risk of serious harm and notify the AIC using the NDB form on the OAIC’s website.

An eligible data breach occurs when the following criteria are met:

1. There is unauthorised access to or disclosure of personal information held by an organisation or agency (or information is lost in circumstances where unauthorised access or disclosure is likely to occur). I.e. a breach has been confirmed by step 3 (Assess).
2. This is likely to result in serious harm to any of the individuals to whom the information relates.
3. The organisation or agency has been unable to prevent the likely risk of serious harm with remedial action.

If this is the case, affected individuals must be notifed.

There are three options for notification. We can

1. Notify all individuals
2. Notify only those at risk of serious harm
3. If the above are not practicable, publish a statement on the website and publicise it

Internal Communication

External Communication

The notification should include, as appropriate:

• A description of the data breach including when it occurred;
• A description of the personal information involved in the breach;
• The steps the University has taken, or is taking, to contain the incident and minimise any potential harm arising from the incident;
• The steps the affected individuals can take to reduce or avoid the risk of harm;
• Contact information of an individual or a department within your organisation that affected individuals can speak to about the incident; and
• The OVIC contact information and advice that affected individuals have a right of complaint to OVIC if they are not satisfied with the organisation’s response to their direct complaint.

5. Review

The review part of this process aims to help (1) prevent further data breaches in the source system or process and more broadly, and (2) improve the University’s response to future breaches.

• Implement a strategy to identify and address any weaknesses in data handling by the University or one of its Colleges that contributed to the breach(es).
• Conduct a post-breach review and report to Management Team, Senior Leadership Team, and the Executive on outcomes and recommendations.
• Establish a system for a post-breach assessment of your entity’s response to the data breach and the effectiveness of your data breach response plan

A Vendor has a data breach

Jointly held information

Regarding a breach of a vendor,“an eligible data breach of one entity will also be considered an eligible data breach of other entities that hold the affected information”.

And “the entity with the most direct relationship with the individuals at risk of serious harm may be best placed to notify. This will allow individuals to better understand the notification, and how the eligible data breach might affect them.”

Therefore, a vendor may conduct the investigation and report this to the University, but it would be the University who notifies, for example, impacted students of the breach.

Questions for the vendor

• What type of information was exposed?
• What impact will this have on their organisation?
• What impact (if any) will the breach have on public safety or services?
• What volume of records/data was exposed?
• Was it a misconfiguration/error, or was it a malicious exfiltration or theft of data identified?
• Has it been/will it be reported to the Office of the Australian Information Commissioner (OAIC)?
• Is it considered to be a Notifiable Data Breach (NDB)?