Incident management guideline

Final | September 2018 | v3.0.0 | PUBLIC |QGCDG

Introduction

Purpose

The information security incident management guideline has been developed to help departments meet their information security event and incident management requirements under the Information security policy (IS18:2018) and Information security information standard (IS18:2009). This guideline maintains consistency, wherever possible, with ISO27035 Information security incident management and covers the ISO27001 information security incident management domain (A.16).

A QGEA guideline is non-mandatory and provides information for Queensland Government departments on the recommended practices for a given topic area.

Audience

This document is primarily intended for:

• departmental staff and operational areas involved in information security incident management
• information security governance bodies.

Scope

This guideline relates to the incident management and compliance management requirements of the Information security policy (IS18:2018) and Information security information standard (IS18:2009).

This guideline does not cover technical incident response activities. Containment, eradication, and recovery activities should be determined by the affected department or agency.

Background

Why was this guideline developed?

This guideline has been developed to assist departments in establishing and implementing an information security incident management policy as well as ensure a planned, systematic approach to handling incidents. Departments or agencies that already have an information security incident management policy in place may use this guideline to assist in conducting reviews to ensure their approach is consistent with information security incident management expectations of the Queensland Government. Additional guidance can be found in ISO/IEC 27035-2:2023 Information technology - Information security incident management - Part 2: Guidelines to plan and prepare for incident response.

Benefits of information security incident management

A comprehensive approach to information security incident management can help departments and agencies to:

• develop proactive controls to reduce the number of information security incidents within their environment
• define and develop response plans and mitigation strategies
• effectively and efficiently identify and respond to incidents
• update their information security policies and plans, including supporting procedures, techniques and training measures to prevent the recurrence of similar information security incidents
• assess business risks and incident impact within the department
• reduce adverse impacts caused by information security incidents.

Guideline structure

This guideline is structured to:

• provide departments a guide to developing their information security incident management policies
• provide an overview of managing information security incidents
• identify the five key phases of event and incident management
• provide details appropriate actions within each of the five phases
• assist in understanding the requirements of the management process.

Event and incident management

The management of information security incidents consists of five key phases as illustrated in figure 1, and forms a repeatable process designed to continually improve internal procedures. The five phases are explained in detail in sections 'Plan and prepare' to 'Lessons learnt' of this guideline.

Plan and prepare

A departments ability to successfully manage information security incidents will depend on how thoroughly they plan and prepare their response. Recommended preparatory activities that should be completed in this phase are detailed below. This list is by no means exhaustive and agencies should complete activities in alignment with their risk tolerance and appetite.

Figure 1: Incident management process

Key activities

• Develop a departmental or agency specific information security incident management policy.
• Educate executive and senior management staff on their role during an incident and ensure they have endorsed the incident management policy.
• Identify and document the information security incident response team.
• Creation of incident response processes and procedures, along with specific playbooks for common events and incidents.
• Establish training programs to be provided to staff detailing how to identify and how to report an information security incident
• Perform Incident response training for response team members.
• Testing the above activities against simulated and real events/incidents.
• Ongoing review of policy, processes, procedures, and training programs to ensure they meet current and emerging threats.

Policy

Departments should consider the following elements for inclusion within their information security incident management policy to meet their overall Information Security Management System policy requirement.

The departments incident management policy should identify legislation that impacts the way departments can manage their information security incidents such as, but not limited to the:

• Information Privacy Act 2009
• Public Records Act 2002
• Privacy Amendment (Notifiable Data Breaches) Bill 2016
• Telecommunications Interception Act 2009.

For more information, departments should refer to section 5.2 of the ISO/IEC 27035:2023 and control domain A.16.1 of the ISO/IEC 27001:2015 which details the requirements for, and provides guidance on, the development and implementation of an information security incident management policy.

As part of the incident management policy a department should include:

• an overview that highlights the business value of the incident management processes
  • senior managements commitment to the policy
  • clear linkages to incident response as a risk management activity.
• an overview of the departments event detection capabilities, and how this information should be used to determine information security incidents (see Detection and reporting).
• an overview of the reporting requirements for: (see Information security incident response team)
  • internal stakeholders
  • external stakeholders.
• an overview of the information security event and incident assessments formal escalation routes of information to internal and external stakeholders (see Detection and reporting)
  • this section of the policy should refer to the Information security incident reporting standard as the basis for the event/incident categorisation and severity assessment.
• a summary of the activities that follow the confirmation that an information security event is an information security incident (see Assessment and decision - Response activities).
• a reference to the need for logging and documentation of all activities in the incident response process, to ensure the collection and preservation of evidence (see Logging and information capture).
• a summary of the activities in the lessons learnt phase of the incident response process (see Lessons learnt).
• details of where the department incident response procedures and playbooks are held.
• an overview of the information security incident response team (ISIRT) structure relevant to the context of the department (see Detection and reporting).
• an overview of the security incident management and awareness training program (see Training and Testing).
• an overview of the technical tools and other support mechanisms available.
• a summary of the legal and regulatory aspects that should be addressed.

Information security incident response team

The establishment of the Information security incident response team (ISIRT) is an important part of a departments management of information security incidents. The goal of establishing the ISIRT is to provide the department with the capability for assessing and responding to information security events and incidents.

The size, structure and composition of the ISIRT should be appropriate to the context, size, and structure of the department establishing the team. Whenever possible it is recommended that the ISIRT is run by the most senior member as the permanent incident response manager. Refer to figure 2 for a minimum recommended ISIRT structure.

Figure 2: Example incident response roles and structure

An ISIRT should be sourced with relevant skills in mind, some examples of ISIRT members include:

• chief information security officer
• network officers/administrators
• IT managers/officers
• security officers/analysts
• business operations
• human resources
  • legal
  • media and communications
  • external extensions

Some of these skill sets will not be represented within the ICT or security departments and some members of the ISIRT can be used ad-hoc from external sources and business units. Departments and agencies who are not resourced to assign full time incident response staff should consider establishing a pool of staff trained for roles within the incident response process.

Processes and procedures

Information security event and incident management processes and procedures should be developed to support the incident management policy. Departments should note the mandatory requirements of the QGEA while developing their internal processes and procedures (e.g. Information security incident reporting standard, IS18, Records governance policy).

Processes

A department should:

• develop internal processes regarding information security response activities
  • these processes can be developed by modelling the roles, responsibilities, and specific tasks that have been defined in their information security incident management policy
• develop or attain a series of generalised and specific incident response playbooks for handling a variety of incident types.

A sample incident response process model/playbook has been developed for departments to use as a guide for their internal response processes (see appendix C).

Procedures

To support established processes, department procedures should

• include any forms and support tools used by employees and response teams to detect, report, document, assess, respond or recover from information security incidents
• include ISIRT and departmental operating procedures regarding internal and external correspondence, such as
  • briefing of departmental executive management on incidents
  • escalating incidents within an agency
    • engaging internal communications teams for media holding statements or public release/media notification
    • informing external stakeholders through threat intelligence sharing with partners or IT alerts / correspondence outside of government.

Training

Training should be provided to maximise awareness, competence and efficiency in the management of information security incidents. All employees should be aware of their individual roles and responsibilities regarding the management, documentation, and reporting of information security incidents. Departments can refer to ISO/IEC 27035 (Section 5.7) for guidance on implementing employee training and awareness programs.

Training programs agencies should consider include:

• induction training for all staff including coverage of basic security concepts
• incident response training for responders
• ICT forensics training
• topic specific training (phishing, password management, etc).

Departments are also encouraged to contact the Cyber Security Unit via email at cybersecurity@qld.gov.au, for assistance in the development of employee training.

Testing

A thorough test of the processes and procedures should take place prior to implementation into the department as an operational workflow. This allows for any initial refinements to be made before an information security event or incident occurs. For departments with information security event and incident management already in place, a test of their current operations can be used to refine and improve their information security incident handling processes and procedures.

Departments should:

• perform regular testing of their incident response processes and procedures through:
  • simulation involving mock scenarios whereby the ISIRT are deployed as if responding to an active incident. In these scenarios production systems are not interrupted and business and executive staff should participate through communication activities and business impact decision making and/or
  • table top exercises whereby staff with incident response roles or responsibilities gather and work through paper-based scenarios to validate whether established controls / processes / procedures would be effective at detecting and responding to potential incidents.
• train all staff in general security awareness and appropriate response activities (i.e. notifying security teams, recording events, and saving evidence).

Tests run against the information security incident management processes and procedures should be realistic and unique from one another to appropriately test against various scenarios

Detection and reporting

Detection and reporting is the first operational phase of the information security incident management process, it involves the detection and collection of information associated with an information security event or incident. This phase also includes the initial reporting of the event or incident to key stakeholders and applicable personnel within the department.

Early detection of information security events will assist in the early mitigation of an event or incident and reduce the chances of impact to the business. Threat intelligence generated and shared through incident reporting can also be used to mitigate potential incidents for other actors that may also be vulnerable.

Key activities

During the detection and reporting phase of the incident response process, a department should ensure the following key activities are performed by appropriate personnel:

• detection of the information security event or the existence of an information security vulnerability
• collection and logging of information related to the information security event
  • accurate logging of all actions, results, and decisions in the incident response process is highly important, these logs will be invaluable during the lessons learnt phase
  • incident response logs can also be produced as evidence and proof of procedure compliance
• gathering of and secure storing of digital evidence
• escalation of the incident as required throughout the phase.

Detection

Information security events can be detected from various sources and it is important to be aware of all the potential sources of notification a department has, this provides departments an opportunity to fill gaps in their detection systems.

• Standard information security event detection sources can include:
• automated alerts from security and/or network monitoring systems
• vulnerability scanning or penetration testing
• analysis of system logs
• escalation of an event detected from a user (event escalation is one of the many values gained from training internal and external users for security awareness)
• notifications from external third parties, including:
  • QGCDG
  • federal departments e.g. Australian Cyber Security Centre, Australia
  • AusCERT
  • ISPs and MSPs e.g. CITEC, government external providers.
  • information security services
  • telecommunication providers
  • threat intelligence partners.

Departments should:

• have defined processes based on the source of the event detection information. For example, event information that has been received from an entity external to the Queensland Government may require different levels of assessment and sensitivity
• have detection systems which appropriately cover the full range of ICT assets utilised within the department
• have regular security awareness training sessions for staff
• define their existing detection sources, their role, and confidence level (see the Information security incident reporting standard)
• establish processes to ensure incidents are entered the information security incident register upon detection.

Logging and information capture

The logging of information security events and incidents is one of the most important activities in the incident response process. Accurate and efficient capturing of relevant information and evidence during an incident is crucial to demonstrate compliance, explain decisions, document actions and conduct post incident reviews.

Departments should produce and securely store a detailed log, including date and time of all:

• decisions that are made and on what authority
• activities undertaken by the ISIRT
• source event detection details
• outcomes of actions and decisions.

Contemporaneous logging should be performed throughout all phases of the incident response process.

Initial reporting

Initial reporting is the action of informing applicable agents within the department of a potential information security event or incident. The initial reporting may come from person, organisation, or may be raised through an automated alerting system.

Departments should have defined:

• reporting procedures and contact points for the ISIRT
• procedures on when and how to escalate to business stakeholders and executives within the department
• reporting formats congruent to those outlined in the Information security incident reporting standard.

Assessment and decision

Assessment and decision is the second operational phase of the information security incident management process. This phase involves assessing the information gathered during the detection and reporting phase and covers the escalation of a security event to an incident.

Key activities

During the assessment and decision phase of the incident response process, a department should ensure the following key activities are performed by appropriate personnel:

• assessment to determine if the event is an information security incident or a false positive
• determine the incident type, scope, and business impact.
• establish initial reporting requirements for the information security incident, both internally along with adherence to the Information security incident reporting standard
• distribute initial information security incident notifications to relevant personnel
• identify and articulate incident response responsibilities within the ISIRT
• refer to whole-of-government and department specific incident response policies and guidelines
• update the information security incident register
• continue ongoing activities of logging actions and decisions along with gathering and securely storing digital evidence.

Assessment

Incident assessment is the key activity performed by a departments ISIRT during this phase of the incident response process. Assessment of an incident provides an easily understood explanation of the incident to less technical teams (legal, media, etc.). Assessment will also inform departments of their mandatory reporting requirements and can be used to inform other department specific decisions (escalation levels, affected business units, etc.)

Departments should:

• refer to the Information security incident reporting standard to assess information security incidents
• have defined escalation criteria based on the results of the incident assessment
• use the results of the assessment to determine the incident communication and reporting strategy.

Response

The response phase of the incident response process primarily involves the containment, removal/eradication, and recovery actions undertaken by the ISIRT. These actions should be documented within the departments existing incident response processes and playbooks.

Key activities

During the response phase of the incident response process, a department should ensure the following key activities are performed by appropriate personnel:

• review ongoing severity of the incident
  • determine needs for external incident response resources and assistance
  • if required escalate the incident to the crisis management team or the executive team via the delegated personnel or format.
• conduct relevant response activities with the intent to mitigate the incident
  • containment
  • eradication
  • recovery.
• communicating the security incident to relevant staff: asset owners, senior staff, ministerial staff, information owners, etc.
• Continue ongoing activities of logging actions and decisions along with gathering and securely storing digital evidence.

Incident review

The incident review activity is an ongoing task throughout the response phase of incident response, this activity is the decision point of the response phase and determines the relevant activities of the response team and if a response is still necessary.

Incident review should be completed by the incident manager with decisions receiving approval of appropriate seniority. During response activities it can be revealed that initial assessment and decision of the incident was incorrect, at this stage it can be beneficial to reassess the incident and alter the response activities or downgrade the severity of the incident.

Incident review should also identify if there is a need for external resources. External resources in this context can refer to external incident responders, additional tools, etc. In these cases, departments and agencies should have defined processes for the appropriation of external resources.

Escalation requirements should also be identified during the incident review activity. When escalation is required it should be handled by the incident manager or the communication co-ordinator. This ensures the communication of an incident is coming to and from a single source. Escalation criteria should be defined and agreed upon within the department or agency. Common escalation points include, disaster recovery, crisis management, and senior management.

When the incident review determines that there are no available response activities and the incident has been resolved the incident manager should move the incident to the lessons learnt phase of the incident response process.

Response activities

Response activities should be primarily determined by the incident review activity and the departments playbooks for different incident categories.

Departments should:

• have playbooks for most security incident types with defined activities and information flows
  • departments and agencies should use a recognised incident response standard as a base for their response playbooks. These standards include the SANS Handlers Handbook, NIST Computer Security Incident Handling Guide, ISO 270035, etc.
• exercise their internal response processes and playbooks to determine effectiveness and improve response times
• follow their internal change management policies and processes.

Forensic analysis

Some information security incidents may require an agency to conduct a full digital forensic analysis and response. Digital forensic response maybe needed for various reasons including, but not limited to, establishing attribution, evidence collection and preservation, or criminal offences.

In most cases it is likely departments will not have the tools or adequately trained staff to conduct digital forensic analysis and response. In these instances, agencies can access forensic capabilities by either;

• accessing the tools and/or trained staff via other Queensland Government departments
• engaging an accredited and recognised external digital forensic service
• contacting the Queensland Government Information Security Virtual Response Team (QGISVRT).

Lessons learnt

The last phase of the incident response process takes place once the incident has been resolved and involves evaluating and analysing the activities taken by the department during the incident response process. The purpose of the phase is to ensure the department takes the opportunity of a security incident to optimise their incident response processes and playbooks.

Key activities

During the lessons learnt phase of the incident response process, a department should ensure the following key activities are performed by applicable personnel:

• produce a post incident review (PIR)
  • identify the lessons learnt from the information security incident
  • identify improvements that could be made to departments or agencies controls, policies, processes, and procedures.
• sharing of the internal reviews to the trusted community and meeting the reporting requirements
• review costs associated with the incident response activities and remediations
• storing complete and reliable records of the activities completed in accordance with the Records governance policy.

Post incident review

The PIR should be a complete summary and review of all the actions and decisions made during the incident response process. The report should also be designed to include lessons learnt by noting the observations and recommendations. The PIR should be completed as soon as viable after the closing of the incident to ensure information is not lost.

The development of the PIR should be a collaborative process that includes the input of as many of the stakeholders including senior management as possible, this ensures the report includes a variety of viewpoints and covers various disciplines.

The output of the PIR should include specific and actionable changes to existing processes, procedures, ICT, systems, policies to increase efficiency in future incident response incidents.

Queensland Government Insurance Fund

The Queensland Government Insurance Fund (QGIF) is a self-insurance scheme for all Queensland Government agencies and applicable statutory bodies. The QGIF does provide coverage for the costs associated with recovering from cyber security incidents.

QGIFs policy includes cover for cyber-related events which cause loss or damage to the agency's IT systems. It also covers amounts an agency may be liable to pay to third parties because of a cyber event or data breach. The cover provided is included under the Property and General Liability sections of QGIFs policy

Departments should:

• contact QGIF on (07) 3035 6367 or qgif@qgif.qld.gov.au to ensure your agency is covered by the QGIF scheme
• ensure relevant agency staff are aware of who your agency's internal QGIF contact is
• ensure your incident response process considers early notification of breaches to QGIF and potential for making a QGIF claim.

Appendix A - Event and incident management policy checklist

The checklist aims to help agencies thoroughly plan and manage information security incidents. It provides tasks and activities which need to be completed in each of the information security event and incident management phases.

Download - Event and incident management policy checklist (DOCX, 42.46 KB).

Appendix B - Event and incident register

When the ISIRT responds to the detection of significant events or any incidents, several items of information should be sought immediately. This will facilitate the analysis of whole-of-government implications and reduce the overhead of dealing with the incident later. Securely collecting the following list of event and incident register data will allow an department to meet their whole-of-government incident reporting requirements, as indicated in the Information security incident reporting standard. As the register has some potential to contain confidential data, it is imperative that the registered be secured by controls appropriate to the security classification of the document. It is suggested that a copy of the incident reporting spreadsheet be used as a basis for this register as departments will need to report all security incidents with the following fields fulfil current whole-of-government reporting requirements. The spreadsheet has the following fields:

Appendix C - Example phishing playbook

Below is an example phishing playbook an agency could develop for use. This example has not been designed to be used as it is and should not be included as part of an agency incident response processes. Agency developed playbooks may include more detailed information including responsible actors, environment specific tasks and documents that need to be included.