Information security incident reporting standard
Final | September 2018 | v3.0.0 | OFFICIAL - Public |QGCIO
Introduction
Purpose
A Queensland Government Enterprise Architecture (QGEA) standard provides information for Queensland Government departments on the recommended practices for a given topic area. They are intended to help departments understand the appropriate approach to addressing a particular issue or doing a particular task. Unlike a guideline, which is better practice advice, a standard is enforced by policy.
The Information security incident reporting standard was developed to provide departments advice in meeting their information security incident reporting requirements under the Information security policy (IS18:2018). This standard should be read in conjunction with the Information security incident management guideline.
Audience
This document is primarily intended for departmental staff and operational areas involved in information security incident management, response and reporting.
Scope
This standard relates to reporting requirement within the Information security policy (IS18:2018).
Mandatory reporting requirements are indicated by the word must. All other elements are either informative or are recommendations and are indicated by the word should.
The Information security incident management guideline provides guidance on meeting reporting obligations.
Definitions
Information security event
A security event is an identified occurrence of a system, service or network state indicating a possible breach of information security, policy or failure of controls, or a previously unknown situation that may be security relevant [ISO/IEC 27000:2018].
Information security incident
An information security incident is defined as a single or a series of unwanted or unexpected information security events that have a significant probability of compromising business operations and threatening information security [ISO/IEC 27000:2018].
Background
This standard has been developed to centrally coordinate reporting and monitoring processes for information security incidents within Queensland government. The Queensland Government Chief Information Office (QGCIO) houses the Queensland Government Information Security Virtual Response Team (QGISVRT). The QGISVRT are the central point of contact for information security incident reporting, and are responsible for incident coordination from a whole-of-government perspective.
Incident reporting provides significant benefits for both Queensland Government departments and the QGISVRT:
- reporting obligations ensure information is provided in a timely manner through appropriate channels to the intended audience
- QGISVRT can advise departments how to contain/limit the impact from an incident, or direct them to other sources for incident management or resolution
- mandatory incident reporting fields ensure information is accurate, complete and actionable
- quarterly reporting builds a comprehensive security risk profile which can be used for trend analysis
- continuous improvement of incident response processes and appropriate control selection through the application of lessons learned
- allows consistent response plans to be developed by the QGISVRT.
Mandatory reporting
Reporting obligations
The Business Impact Level (BIL) reporting table determines a departments reporting obligations in relation to an information security incident.
BILs are defined in the Queensland Government Information Security Classification Framework (QGISCF) and are determined by the business owner of the system.
If a system does not have a BIL assigned, the business owner of the system must be consulted to determine the appropriate level.
Systems which have not been assessed under the Queensland Government Information Security Classification Framework v4.0.0 (QGISCF) should use Appendix C - Mapping between old and new confidentiality classifications to determine immediate reporting requirements.
It should be noted this is based on confidentiality only, and a full assessment of the system should be completed once the incident has concluded to determine the systems integrity and availability BILs.
Departments must report:
- immediately for security incidents affecting a system with a Medium BIL or above
- immediately for security incidents affecting multiple systems / departments
- quarterly for all other security incidents.
Departments should:
- report and share all security related events or incidents.
Business impact level reporting table
The table below will determine a departments reporting requirements.
| Breadth of the incident | Business impact level | ||
|---|---|---|---|
| Low | Medium | High | |
| Single department / system | Quarterly | Immediately | |
| Multiple departments / systems | Immediately | ||
What to report
Departments must:
- submit to the QGISVRT data for all information security incident reporting fields (see 3.4 Information security incident reporting fields section)
- report incidents as per the BIL reporting table to the QGISVRT.
Departments should:
- group and summarise similar incidents which do not meet the immediate reporting obligations, which are to be included in quarterly reporting
- document and maintain all information security incidents within an auditable information security incident register.
When and how to report
For immediate reporting, departments must:
- report incidents at the point they are determined to correspond with an immediate requirement in the BIL reporting table (see 3.1 Reporting obligations) to the QGISVRT
- use any of the following communications channels:
- phone -07 3215 3951
- email qgisvrt@qld.gov.au
- formally agreed upon channel between the department and CSU prior to the incident occurring
For quarterly reporting, departments must:
- provide a copy of the departments information security incident register for that quarter to the QGISVRT
- ensure reports are submitted no later than two weeks after the final day in each quarter
- Chief Information Officers (CIO) can seek a temporary extension for their department by emailing QGISVRT@qld.gov.au
- QGISVRT will notify a departments CIO of non-compliance with this standard if reports are not received within the given timeframe.
Departments should:
- ensure incidents are reported to the QGISVRT by a person whose roles and responsibilities include information security
- operate a platform which allows for the aggregation of security event and incident information / logs, which is made available to the QGISVRT (read-only access)
- report and share all security related events or incidents.
Departments who opt to provide the QGISVRT with read-only, real-time access to their information security incident register (or SIEM) will be noted as meeting their quarterly reporting obligations.
Reporting quarters
Reporting quarter 1 (Q1)1 January to 31 March
Reporting quarter 2 (Q2)1 April to 30 June
Reporting quarter 3 (Q3)1 July to 30 September
Reporting quarter 4 (Q4)1 October to 31 December
Information security incident reporting fields
Information security incident management can involve making critical business decisions. To support these decisions, information must be timely, accurate and complete.
The mandatory information security incident reporting fields standardise the minimum incident information that must be captured by departments and reported to the QGISVRT.
Where information is incomplete or not yet available, departments must provide an update when it becomes available.
Departments must report:
- Contact information
- Date and time discovered
- Incident scope
- Business impact level
- Incident summary
- Impact to the department
- Incident type (see Appendix B)
- Indicators of compromise (IOCs)
Departments should report:
- all remaining fields defined in the Information security incident reporting spreadsheet.
How QGISVRT uses incident information
The QGISVRT collects and maintains a register of information security incidents which enables it to:
- effectively coordinate whole-of-government incident response
- maintain visibility of incidents which may impact other government departments
- provide advice and guidance to departments handling incidents.
QGCIO will:
- collect and securely store information relating to information security incidents
- by default, share de-identified threat intelligence (where possible) gathered during an incident, such as indicators of compromise, unless requested not to by a department
- analyse and interpret incident information to identify trends or patterns, provide advice to agencies, determine the impact to whole-of-government and publish de-identified materials relating to the analysis of incidents.
QGCIO will not:
- Provide information to entities outside of Queensland Government which may identify a department / agency without their express permission.
Appendix A
Mandatory information security incident reporting fields
Successful information security incident management relies on data consistency and data quality
The benefits of consistent and quality data include:
- quicker response times
- actionable information
- reduced uncertainty
- reduced duplication of effort
- increased confidence in information and recommendations.
To ensure the QGISVRT is able to fulfil its role effectively and efficiently, the following fields must be completed when submitting an incident report to the QGISVRT.
Mandatory Field | Description |
|---|---|
Contact Information | This is the primary contact point for the incident in your department. Recommended details include:
|
Date and time discovered | Date and time (GMT+10) the incident was first discovered Note: Cloud-based services may use UTC, these should be translated into GMT+10 to ensure accurate timelines are maintained. |
Incident scope | The departments determination of how wide spread is the incident. Particularly relevant for Service Providers where one incident may affect multiple customers. |
BIL rating | Business Impact Level (if not known) must be determined by referring to the Queensland Government Information Security Classification Framework (QGISCF). Note: Initial reporting can include the BIL by itself however, ideally the Confidentiality, Integrity and Availability ratings should be made available to provide context around the affected asset. |
Incident summary | A brief description of the incident Example: External webserver compromised via a publicly available remote code execution exploit |
Impact to the department | A brief description of how the business has been impacted i.e. the real-world consequences. Example 1: Customers are unable to submit renewals requests via the website, causing increased call centre traffic and complaints. Example 2: A Director-Generals email account has been compromised and is sending malicious emails |
Incident type | What type of incident has occurred based on the definitions in Appendix B Incident type |
Indicators of compromise | These are the artefacts of the event or incident which can be used to determine if a compromise may have occurred, for example:
|
Appendix B
Incident type
For the purposes of information security event and incident reporting, incidents must be assigned an incident classification from the table below
Term | Description |
|---|---|
Theft/loss of assets | The theft or loss of any information or technology asset/device (including portable and fixed media) that might have been or has been used to either process or store Queensland Government information. |
Account Compromise | The compromise of Queensland Government account credentials providing unauthorised access to a malicious 3rd party. This often involves leveraging the targets position of trust, or escalating privileges to move laterally. Types of account compromises include:
|
Phishing | Emails or domains which masquerade as a legitimate entity with the goal of compromising a users information such as:
|
Unauthorised access to information/systems | Unauthorised access from internal and external sources to Queensland Government information and systems. Use this type if the incident does not fit into account compromise or intrusions against networks. |
Unauthorised release of or disclosure of information | Unauthorised release or disclosure of Queensland Government information. |
Malware infections | Software programs designed to cause damage to Queensland Government systems. |
Ransomware infections | Software programs designed to extort a payment, usually financial, by denying authorised user access to Queensland Government information systems. |
Intrusions against networks | Intrusions targeting Queensland Government internal infrastructure. This includes but is not limited to:
Intrusions that cannot be attributed, after analysis, to what is considered consistent with Internet noise. For example intrusion attempts that consistently target internal network infrastructure, users or services provided for external use such as web applications. |
Abuse of privileges | Unauthorised changes to privileged user settings on stand-alone or networked equipment including network profiles, local user or device configuration files that have not been approved through the Departments change management process. |
Unauthorised changes to information, applications, systems or hardware | Any unauthorised changes to an organisations file system, including media, through insertion, modification or deletion. For example, changes to the standard operating environments (SOEs), addition of executables or the modification of an executables configuration. Any unauthorised installation of additional processing, communications or storage equipment into the IT network. This includes but is not limited to:
|
Violation of information security policy | Any violation of information security policy or the information security related aspects of the code of conduct. |
Suspicious system behaviour or failure (hardware/software) or communications) | Unknown network activities affecting/degrading network performance with increased network bandwidth usage and decreased response time, using excessive CPU, increased suspicious network requests or increased Intrusion Detection System (IDS)/Intrusion Prevention System (IPS) alerts leading to application crashes. Includes a malfunction within the electronic circuits, electromechanical components of a computer/communications system, or malfunction/inability of a program to continue processing due to erroneous logic. |
Password confidentiality | Sharing/stealing/loss of passwords or other authentication token. |
Sabotage/physical damage | Any damage or destruction of physical information assets or electronic devices. |
Other events | Natural events and other events which result in damage to information and systems. This includes but is not limited to:
|
Appendix C
Mapping between old and new confidentiality classification
Click the thumbnail below to download
