Comments

Document Feedback - Review and Comment

Step 1 of 4: Comment on Document

How to make a comment?

1. Use this Protected Document to open a comment box for your chosen Section, Part, Heading or clause.

2. Type your feedback into the comments box and then click "save comment" button located in the lower-right of the comment box.

3. Do not open more than one comment box at the same time.

4. When you have finished making comments proceed to the next stage by clicking on the "Continue to Step 2" button at the very bottom of this page.

 

Important Information

During the comment process you are connected to a database. Like internet banking, the session that connects you to the database may time-out due to inactivity. If you do not have JavaScript running you will recieve a message to advise you of the length of time before the time-out. If you have JavaScript enabled, the time-out is lengthy and should not cause difficulty, however you should note the following tips to avoid losing your comments or corrupting your entries:

  1. DO NOT jump between web pages/applications while logging comments.

  2. DO NOT log comments for more than one document at a time. Complete and submit all comments for one document before commenting on another.

  3. DO NOT leave your submission half way through. If you need to take a break, submit your current set of comments. The system will email you a copy of your comments so you can identify where you were up to and add to them later.

  4. DO NOT exit from the interface until you have completed all three stages of the submission process.

 

Information Security Incident Management Guidelines

Section 1 - Introduction

Purpose

(1) This guideline document describes the standard approach for planning for, and responding to, information security incidents involving the University's ICT resources and information assets. It specifies an appropriate incident response based on the nature and severity of the incident, the data involved, and other factors.

(2) This document provides guidance to the Incident Handler 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; and
  3. continuously improve incident response as a result of managing information security incidents.

(3) These guidelines form part of the University's hierarchy of IT related incident management processes:

  1. IT Incident Management Process;
  2. Information Security Incident Management Guidelines (this document);
  3. Digital Technology Solutions’ Critical Incident Management Guide; and
  4. University's Business Continuity Management Policy and Business Continuity Management Framework.

(4) 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 stored or processed; and
  3. report suspected or actual information security incidents promptly so that appropriate action can be taken to minimise harm.

Scope

(5) This guideline applies to the ICT resources and the information assets of the University, and to any person or device who gains access to these systems or data.

(6) This guideline document must be read in conjunction with the IT Services Critical Incident Management Guide, and the University's Business Continuity Management Framework, Business Continuity Management Policy, Information Security Policy, and Information Technology Conditions of Use Policy

Interface with IT Incident Management

(7) IT Incident Management is responsible for incident processes related to a significant deterioration, degradation, or disruption of an IT business process or service. 

(8) The Information Security Team is responsible for information security incident management processes, running in conjunction with the IT incident management process.

(9) While investigating a particular IT incident, it may become evident or there may be indications that the root cause is information security related. 

(10) If, during an standard IT incident response, ITS staff suspect that an outage or service disruption may be security-related, these guidelines should be followed.

(11) If it is determined that an incident is not information security related, the Information Security Team will discontinue its participation in that incident response process.

Interface with IT Services’ Critical Incident Management

(12) Major and significant incidents require immediate escalation to the IT Service Continuity Coordinator, who is responsible for the Digital Technology Solutions’ Critical Incident Management process.

(13) Digital Technology Solutions Critical Incident Management process will in turn interface with the University Business Continuity process should an incident require such escalation.

Top of Page

Section 2 - Information Security Incident Management Process

Introduction

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

  1. Preparation:  policies, stakeholder notification and technology acquisition.
  2. Detection: detecting and confirming an incident has occurred; categorising the nature of the incident and then prioritising the incident.
  3. Containment, Eradication and Recovery:  minimising the loss or 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.

(15) The sensitivity of information communicated during all phases of incident response must be carefully considered.  The University's Information Security Data Classification and Handling Manual defines the four security classification levels in use across the University

(16) The Incident Handler may, whilst undertaking incident response, liaise with external organisations such as the ACSC, ASD, ASIO, AusCERT, CERT Australia, security consultants, application vendors and specialists in order to manage the technical incident response.  This will not form part of any official notification process, and must be done in strict confidence.

(17) In cases where the Incident Handler communicates with external parties, the industry standard Traffic Light Protocol (TLP) should be used. The four University data security classifications align closely with those of the TLP:

Table 1 – TLP Classifications and University Data Classifications

University Information Security
Data Classification
TLP Classification
Highly Restricted RED
Restricted AMBER
X-in-Confidence GREEN
Public WHITE

Phase 1:  Preparation

(18) 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

(19) Preparation includes those activities that enable the Incident Handler to respond to an incident:

  1. Policies – the University's Information Security Policy, Information Technology Conditions of use Policy, Business Continuity Management Policy, Business Continuity Management Framework, Risk Management Framework must readily be available for use as reference.
  2. Stakeholder notification – in cases of incidents categorised as major or significant, the Incident Handler must immediately send an incident notification communication in accordance with the Digital Technology Solutions Critical Incident Management Guide and the University's Business Continuity Management Policy.
  3. Technology – required technology must be acquired to support the information security incident management process. This may include a laptop, a mobile internet connection (if network access is impacted), and access to copies of necessary software and documents, such as policies and guidelines.

Phase 2: Detection and Incident Analysis

(20) An information security incident begins when a security-related event is reported. This could come from an automated system diagnostic, an incident ticket submitted by a user to the IT Service Desk, or other sources.

(21) When an information security incident is reported or assigned to the Information Security Team, the incident is assigned to an Incident Handler who is responsible for investigating the incident and coordinating the response until the incident is resolved, closed or escalated to the IT Service Continuity Coordinator as an ITS Critical Incident.

(22) The first step for an Incident Handler is to perform a detailed incident analysis and risk assessment, using the University's Risk Management Framework.

(23) Process steps:

  1. an information-security-related event is identified and assigned to an incident handler for management;
  2. the Incident Handler will perform the incident analysis to determine whether or not a security incident has occurred;
  3. the Incident Handler will perform a risk analysis of the incident as per the University Risk Management Framework.
  4. the Incident handler determines the Incident Categorisation and Incident Prioritisation, and the resultant service levels;
  5. for major or significant incidents the case is assigned to the IT Service Continuity Coordinator for management, as per the ITS Critical Incident Management Guide; and
  6. incidents involving personally identifiable information (PII) or protected health information (PHI) breaches must be reported to the CIO for referral to the Privacy Office.

Table 2 – Incident Categories

Category Description
Unauthorised Access Unauthorised and successful / unsuccessful logical access to the University's ICT services and systems.
Denial of Service (DoS) An attack that successfully prevents or impairs the normal authorised functionality of networks, systems or applications by exhausting resources.  This activity includes being the victim of, or participating in, a DoS.
Malware Successful installation of malicious software (e.g. virus, worm, Trojan horse, or other code-based malicious entity) that infects the ICT services and systems.
Information Leakage Security incident involving loss of the University's critical information that can have a negative impact on the University.
Improper Usage
Actions involving ICT services and systems that violate the Information Technology Conditions of Use Policy, e.g:
a. downloading and/or using unauthorised security tools;
b. use of peer to peer applications to acquire or distribute copyrighted material;
d. mis-use of University ICT services and systems; and
e. other improper usage per the Information Technology Conditions of Use Policy.
Unconfirmed Unconfirmed incidents that have been contained, that are potentially malicious or anomalous activity deemed by the Information Security Incident Response Team (ISIRT) that warrant further review.
Collateral damage Incidents that impact the confidentiality, integrity or availability of information, that are caused by failure of the very systems that are meant to protect University information; such as a failed security software update that impacts system availability.

Incident Prioritisation

(24) The Incident Handler shall perform an assessment of the incident priority using the factors in the table below.

Table 3 – Incident Prioritisation Levels

Priority Factor Examples
Major An incident effecting the entire University.
- Substantial, possibly wide-ranging, actual or potential damage to the confidentiality, integrity or availability of the University's information assets and ICT resources.
- An incident that impacts the availability of perimeter security infrastructure.
- Bulk exposure of University PHI, PII or intellectual property (IP) into the public domain, where such exposure results in compliance and\or reputational consequences.
Significant An incident effecting multiple facilities, User Groups or campuses.
- Contained actual or potential damage to the confidentiality, integrity or availability of the University's information Assets and ICT resources.
- >10% of University users unable to use ICT resources.
- Exposure of a small amount of confidential or sensitive University information (PHI, PII or IP) into the public domain or to an unauthorised individual.
Escalated An incident affecting a facility or campus.
-Malware incident that doesn’t fall into a higher severity.
-Data loss incidents not involving PHI or PII.
-Confirmed phishing campaign that impacts more than 100 users.
Normal Minor Incident -Some localised inconvenience, but no significant impact to the University.

(25) Given the established priority, the incident will be allocated a service level which determines the timelines attached to next steps.

Incident Service Levels

(26) The Incident Handler shall ensure that an incident is managed and responded to as per the below service levels. This service level 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.

Table 4 – Incident Service Levels

Incident Category Notification* Contain / Remediate** Stakeholders to notify
Major Immediate 8 hours - IT Service Continuity Coordinator
- Associate Director, Cyber Security and IT GRC
- CIO
Significant 4 Hours 24 Hours - IT Service Continuity Coordinator
- Associate Director, Cyber Security and IT GRC
- CIO
Escalated 24 Hours 5 Business Days - Associate Director, Cyber Security and IT GRC
Normal N/A N/A - N/A
ANY Involving PII or PHI Immediate 24 Hours - Associate Director, Cyber Security and IT GRC
- CIO for referral to the Privacy Office
*Notification – Initial notification of a suspected or actual incident to the relevant stakeholders.
**Contain / Remediate – Maximum time to either contain the threat or to permanently remediate.

Incident

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

Status Reason
Confirmed An incident has been confirmed and response is underway.
Disposition Reason
Unidentified A confirmed incident involving an ICT service or system which cannot be located may be resolved as Unidentified.
Transferred A confirmed incident may be investigated and transferred to another department for further investigation or action.
Deferred
A confirmed incident may be deferred due to resource constraints, or information type.
Note:  Critical / High Priority cases cannot be deferred without CIO approval.
False Indicator Investigation reveals that the source indicator used as the basis for incident detection was a faulty Indicator.
Misconfiguration An event that appeared to be a malicious activity was subsequently proven to be a false alert and determined to be a misconfiguration (malfunction) of a system.
Duplicate An incident may be a duplicate of another record in the Service Desk, and must be merged with the existing workflow.

Escalation

(28) Major and significant incidents 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 initial point of escalation is to the IT Service Continuity Coordinator, who is responsible for the Digital Technology Solutions’ Critical Incident Management Guide.

Phase 3:  Containment, Eradication and Recovery

(29) 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, where applicable, informing the appropriate team of 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 their normal state.  

(30) The 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 Handler.

(31) Incident Handlers will require investigation expertise to effectively manage the incident response, or must have access to or agreements with third parties with appropriate skill sets to perform investigations.

(32) 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; and
    4. implement additional containment measures, if necessary.
  2. eradicate the incident:
    1. identify and mitigate all vulnerabilities that were exploited;
    2. the Incident Handler 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; and
    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, and are not in a state prone to repeat compromise; and
    2. confirm that the affected systems and services are functioning normally.

Phase 4:  Post-Incident Activity

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

Compile Summary of Actions and Findings

(34) The Incident Handler(s) must document the actions taken during the process. If the incident involved support from external parties such as AusCERT, CERT Australia, or contracted security consultants, their steps and reports must also be documented by the Incident Handler.

(35) The Incident Handler shall collate the details and prepare the closure report.

Closure Report

(36) The Incident Handler is responsible for documenting an incident closure 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; and
  9. lessons learnt.

(37) The completed incident closure report is shared with CIO for review and approval.

Submit Recommendations to Appropriate Management

(38) The Incident Handler delivers the incident closure report, including recommendations for changes in technology, process or policy, to appropriate stakeholders for the development of a follow-up action plan.

Lessons Learnt

(39) Information security threats evolve over time, and thus it is imperative that regular improvements are made to information security controls.  Any proposed control improvements should consider the outcomes and findings of information security incidents investigations.

Top of Page

Section 3 - Roles and Responsibilities

Information and Technology Services (ITS) Staff

(40) As service owners and users of IT resources, ITS staff are expected to recognise potential security incidents.  Responsibilities include:  

  1. promptly reporting all security incidents to the Information Security Team;
  2. working with the Information Security Team to follow these Information Security Incident Management Guidelines. This includes checking with Information Security Team prior to communicating with any external unit or department about issues or problems that may have security-related components; and
  3. the adequate protection of all Incident-related information that is considered Restricted or Highly-Restricted information.

Information Security Team

(41) The Information Security Team is the team of IT security professionals within Digital Technology Solutions assigned to handle the information security needs for Digital Technology Solutions. Responsibilities include:

  1. maintaining it-security@newcastle.edu.au as the mailbox to report security incidents within Digital Technology Solutions (DTS);
  2. receiving notification of detected or reported information security events and incidents from users and service owners of IT resources, automated detection systems, or other sources;
  3. ensuring all relevant information necessary to understand the incident is gathered;
  4. initiating incident response procedures as outlined in this guideline; and
  5. in the course of the incident response, and where appropriate to do so, providing assistance on queries that may be raised.

Incident Handler

(42) The Incident Handler will typically be a member of the Information Security Team who is assigned operational responsibility for the management of an Information Security Incident. Responsibilities include:

  1. development of an incident containment, eradication, and recovery plan;
  2. instructing incident response team members of the response actions that are required;
  3. requesting, collecting and managing relevant artifacts for secure storage as part of the incident management response;
  4. ensuring incidents are promptly reported to management and appropriate business owners as appropriate;
  5. ensuring that incidents are promptly escalated to the IT Service Continuity Coordinator when deemed major or significant;
  6. preparing a written report of the incident, corrective actions taken, and recommendations to prevent recurrence; and
  7. reporting Incidents involving PII or PHI breaches to the CIO for referral to Privacy Office.

Definitions

(43) In the context of this document:

  1. event is defined as an exception to the normal operation of IT infrastructure, systems, or services. Not all events become incidents.
  2. an Information Security Incident (or “incident”) is an adverse event that affects an information system and/or a network that poses a threat to the confidentiality, integrity or availability of the University's information assets; or a violation of explicit or implied University policy (e.g. the University's Information Technology Conditions of Use Policy), IT standard, or code of conduct. Examples of information security incidents include, but are not limited to:
    1. compromised user credentials;
    2. interference with the intended use of information technology resource;
    3. loss or theft of equipment used to store private or sensitive information;
    4. unauthorised change to hardware, software or data;
    5. unauthorised use of systems or data; and
    6. computer system intrusion.