Document Feedback - Review and Comment
Step 1 of 4: Comment on Document
How to make a comment?
1. Use this 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:
-
DO NOT jump between web pages/applications while logging comments.
-
DO NOT log comments for more than one document at a time. Complete and submit all comments for one document before commenting on another.
-
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.
-
DO NOT exit from the interface until you have completed all three stages of the submission process.
(1) This guideline document describes the standard approach for planning for, and responding to, information security incidents involving the (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: (3) These guidelines form part of the (4) All users of the (5) This guideline applies to the (6) This guideline document must be read in conjunction with the IT Services Critical Incident Management Guide, and the (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 (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. (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 (14) Information Security Incident Management is a structured approach, and is composed of four phases: (15) The sensitivity of information communicated during all phases of incident response must be carefully considered. The (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 (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. (19) Preparation includes those activities that enable the Incident Handler to respond to an incident: (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 (24) The Incident Handler shall perform an assessment of the incident priority using the factors in the table below. (25) Given the established priority, the incident will be allocated a service level which determines the timelines attached to next steps. (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. (27) Based on the analysis of the incident category and classification, the information security incident can be addressed in the following ways: (28) Major and significant incidents require escalation so that senior management within the (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 (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 (32) An appropriate combination of the following actions must be used to complete this phase: (33) This phase takes place once the information security incident has been resolved or closed. (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. (36) The Incident Handler is responsible for documenting an incident closure report which contains (at the minimum) the following information: (37) The completed incident closure report is shared with CIO for review and approval. (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. (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. (40) As service owners and users of IT resources, ITS (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: (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: (43) In the context of this document:Information Security Incident Management Guidelines
Section 1 - Introduction
Purpose
Scope
Interface with IT Incident Management
Interface with IT Services’ Critical Incident Management
Section 2 - Information Security Incident Management Process
Introduction
Table 1 – TLP Classifications and University Data Classifications
University Information Security
Data ClassificationTLP Classification
Highly Restricted
RED
Restricted
AMBER
X-in-Confidence
GREEN
Public
WHITE
Phase 1: Preparation
Preparing to handle an Incident
Phase 2: Detection and Incident Analysis
Table 2 – Incident Categories
Category
Description
Unauthorised Access
Unauthorised and successful / unsuccessful logical access to the
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
Improper Usage
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
Incident Prioritisation
Table 3 – Incident Prioritisation Levels
Priority
Factor
Examples
Major
An incident effecting the entire
Significant
An incident effecting multiple facilities, User Groups or campuses.
Escalated
An incident affecting a facility or campus.
Normal
Minor Incident
-Some localised inconvenience, but no significant impact to the
Incident Service Levels
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 OfficeIncident
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
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
Phase 3: Containment, Eradication and Recovery
Phase 4: Post-Incident Activity
Compile Summary of Actions and Findings
Closure Report
Submit Recommendations to Appropriate Management
Lessons Learnt
Section 3 - Roles and Responsibilities
Information and Technology Services (ITS) Staff
Information Security Team
Incident Handler
Definitions