16
DPC/G4.12a GOVERNMENT GUIDELINE ON CYBER SECURITY ISMF Guideline 12a- Cyber security incident reporting scheme Background Reporting cyber security incidents is a source of intelligence information that assists in the development of a greater understanding of any threats to South Australian Government assets. A holistic picture of the cyber threat environment can be used to assist other at-risk agencies as well as aid in developing new policies, procedures, techniques and training measures to help prevent future incidents. The Cyber Security Incident Reporting Scheme is aimed at helping gain a greater understanding of all incidents that are impacting, or have the potential to impact, SA Government assets. Guidance This guideline has been developed to assist agencies understand the Cyber Security Incident Reporting Scheme and implement it in to their agency’s internal processes. This document should be read in conjunction with ISMF Standard 140 . Page 1 of 16 Public-I2-A1

Background  · Web viewPage 1 of 2. Public-I2-A1. Page 1 of 2. ... (refer Figure 4 below for full workflow). ... To attribute this material,

  • Upload
    vonga

  • View
    216

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Background  · Web viewPage 1 of 2. Public-I2-A1. Page 1 of 2. ... (refer Figure 4 below for full workflow). ... To attribute this material,

DPC/G4.12a

GOVERNMENT GUIDELINE ON CYBER SECURITY

ISMF Guideline 12a- Cyber security incident reporting schemeBackgroundReporting cyber security incidents is a source of intelligence information that assists in the development of a greater understanding of any threats to South Australian Government assets. A holistic picture of the cyber threat environment can be used to assist other at-risk agencies as well as aid in developing new policies, procedures, techniques and training measures to help prevent future incidents. The Cyber Security Incident Reporting Scheme is aimed at helping gain a greater understanding of all incidents that are impacting, or have the potential to impact, SA Government assets.

GuidanceThis guideline has been developed to assist agencies understand the Cyber Security Incident Reporting Scheme and implement it in to their agency’s internal processes. This document should be read in conjunction with ISMF Standard 140.

Document relationship

Page 1 of 11 Public-I2-A1

Page 2: Background  · Web viewPage 1 of 2. Public-I2-A1. Page 1 of 2. ... (refer Figure 4 below for full workflow). ... To attribute this material,

What is the Cyber Security Incident Reporting Scheme?

As the Control Agency for ICT Failure, the Department of the Premier and Cabinet [DPC] is tasked with the control and coordination of whole-of-government operational responses to cyber incidents. The Cyber Security Incident Reporting Scheme assists the Department fulfil this role.

This scheme is a replacement for the previous Notifiable Incident system and is based on similar incident reporting systems used within the other Australian government jurisdictions and draws on the principles of the international standard for Information Security Incident Management (ISO/IEC 27035).

All South Australian Government agencies and applicable suppliers have a requirement to report cyber security incidents and events which disrupt or are likely to disrupt ICT services in the South Australian Government to the Watch Desk of the Control Agency for ICT Failure (Watch Desk).

Does the Cyber Security Incident Reporting Scheme replace my agency’s incident management processes?

The Scheme does not replace an agency’s internal incident management processes and procedures. The Scheme runs in parallel and compliments existing agency arrangements to provide a holistic picture of the threat environment for government systems, as well as allowing the Watch Desk to provide assistance to other agencies who may also be at risk.

Why is there a need for the Cyber Security Incident Reporting Scheme?

By being adequately informed the SA Government, can undertake a number of preventative or response measures, including:

notifying agencies of current threats that they need to be aware of and measures they can take to mitigate these threats.

developing new policies, procedures, techniques and training measures to help prevent future incidents.

implementing additional technical preventative measures such as blocking or filtering.

coordinating and prioritising government resources to investigate or respond to significant or multi-agency incidents.

reporting the information to relevant national resources and intelligence services.

providing regular reports to relevant governance committees on quantity and type of incidents occurring.

feedback to agencies via ad-hoc Security Bulletins and regular newsletters outlining the types of Events and Incidents occurring within the SA Government ICT environment.

As the Control Agency for ICT Failure, DPC is committed to working with agencies to help ensure that the Cyber Security Incident Reporting Scheme improves the government’s security posture as well as provides value to all relevant parties.

Page 2 of 11 Public-I2-A1

Page 3: Background  · Web viewPage 1 of 2. Public-I2-A1. Page 1 of 2. ... (refer Figure 4 below for full workflow). ... To attribute this material,

Cyber Security Incident

Threat Unwanted or unexpected action Vulnerability

Cyber Security Event

Government Information Asset

Causes Exploits

Occurrence of

Assessed as

Implications on information security

Exposes

What is a cyber security incident?

The Cyber Security Incident Reporting Scheme uses two key definitions that must be considered:

Cyber Security Event: 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.

Cyber Security Incident: a single or a series of unwanted or unexpected Cyber Security Events that have a significant probability of compromising business operations and threatening information security.

All Agencies are responsible for reporting Cyber Security Events to the Watch Desk. A Cyber Security Event being identified will not necessarily mean that an attempt has been successful or that there are any consequences for the security of the government’s information or cyber assets – not all Cyber Security Events will be classified as Cyber Security Incidents. The Watch Desk will make an assessment at the time of an Event being reported.

The reporting agency will aid in the assessment process to determine whether the Event constitutes a Cyber Security Incident. If it is assessed as an Event then nothing further will be required of the agency, however, if it is determined that an Incident then additional follow up activities will be required (refer Figure 4 below for full workflow).

Relationship of objects in the Cyber Security Incident chain

Page 3 of 11 Public-I2-A1

Cyber Security Incidents

Cyber Security Events

Incidents make up only a small portion of Cyber Security Events

Diagram adapted from ISO/IEC 27035: Information Technology - Security techniques - Information security incident management

Page 4: Background  · Web viewPage 1 of 2. Public-I2-A1. Page 1 of 2. ... (refer Figure 4 below for full workflow). ... To attribute this material,

What should or should not be reported?

Not all unwanted or unexpected actions are going to result in the occurrence of a Cyber Security Event nor are they going to of interest for reporting or recording purposes. The following is examples of the types of occurrences that the Watch Desk is less likely to be interested in:

Examples of what does not need to be reported

Non-ongoing malware or virus activity on a standard user device that is easily remediated.(e.g. single case of a user device with a virus that is automatically detected and cleaned by the existing controls)

Short term outages on non-critical services.(e.g. non-business critical machine has an unplanned outage which is easily recovered from within recovery time objectives).

Single cases of standard spam e-mails without any malicious links or attachments.(e.g. marketing or advertisement spam, or “Nigerian” scams without any malicious links or attachments)

Normal background activity detected in logs.(e.g. standard, regular activity seen in log managers or SIEM systems)

Users breaching agency specific policies or guidelines for appropriate usage of government internet.(e.g. single user browsing inappropriate, but not illegal or malicious, websites during work time)

Unexploited vulnerability in non-critical information systems, services or networks.(e.g. unpatched vulnerabilities of desktop machines which have not been exploited)

The following are examples of the types of occurrences that the Watch Desk is interested in and should be reported.

suspicious or seemingly targeted emails with attachments or links

compromise or corruption of official information

data breaches

theft or loss of electronic devices that have processed or stored government information

intentional or accidental introduction of malware or potentially unwanted programs to a network

denial of service attacks

suspicious or unauthorised network activity

reduced capacity or failure of government systems, services or networks.

web or online presence defacement or compromise

The above examples are not a complete list but can be used as a guide for the types of things that should or should not be reported.

Consideration should also be given to whether any occurrence may be part of a wider incident, whether it may impact on essential or important services, or whether the findings within one agency may assist another. If in doubt, report it. It is better to over report than under report.

Page 4 of 11 Public-I2-A1

Page 5: Background  · Web viewPage 1 of 2. Public-I2-A1. Page 1 of 2. ... (refer Figure 4 below for full workflow). ... To attribute this material,

Cyber Security Incident Reporting Scheme workflow

Page 5 of 11 Public-I2-A1

Page 6: Background  · Web viewPage 1 of 2. Public-I2-A1. Page 1 of 2. ... (refer Figure 4 below for full workflow). ... To attribute this material,

When, where and how should events and incidents be reported?

The reporting process is intended to be simple and the Watch Desk will work with agencies to make sure it is easy and useful for all stakeholders.

When: Cyber Security Events and Incidents should be reported immediately.

the timing of incident reporting is vital to the response process and as such Cyber Security Events and Incidents should be reported to the Watch Desk immediately. In many cases this may result in incomplete and potentially inaccurate information; however, the risk posed by early reporting is outweighed by the advantage gained from early action.

Where: The Watch Desk is the contact point for Cyber Security Event and Incident Reporting. The Watch Desk may be contacted via the following means:

Phone (business hours): (08) 8226 7513

E-mail (business hours): [email protected]

Watch Desk Duty Officer (emergency/out of hours number): (08) 8232 3049

How: Reports should initially be made via phone or e-mail to the details listed above. In the case of a Cyber Security Event then there will be no further formal action required of the agency. If it is determined that a Cyber Security Incident has occurred, then agencies will be asked to complete an Incident Report Form (see Appendix 1) and there will also be a request to submit a Post Incident Review (see Appendix 2) once the incident has been closed.

Who from my agency is responsible for reporting?

Each agency will already have their own internal incident management processes which are likely to determine who handles the operational information regarding Cyber Security Events and Incidents. This person may or may not be the agency ITSA. Because of this, initial reports of Cyber Security Events or potential Incidents may be received from whomever an agency considers appropriate to do so (e.g. ICT Security Analysts, Service Desk staff etc.). The moment an Event is considered an Incident there is an expectation the ITSA will be involved.

The Watch Desk will not, however, accept a Cyber Security Incident Report that has not been reviewed by the ITSA.

Additional considerations

Illegal Activity: incidents involving illegal activity must be reported to SA Police in addition to the Watch Desk. The Watch Desk will report illegal activity to the SA Police if the agency does not.

Reports to Australian Cyber Security Centre: the Watch Desk is the single point of contact for the Australian Cyber Security Centre in regard to cyber security incidents.

Post Incident Reports: post incident reporting is an important part of the incident management process. Post incident reports provide opportunities to improve technical security measures, response processes and government policy. An incident cannot be closed by the Watch Desk until a Post Incident Report has been submitted. The Post Incident Report Form (Appendix 3) should be submitted within 30 days of the incident response process being completed.

Page 6 of 11 Public-I2-A1

Page 7: Background  · Web viewPage 1 of 2. Public-I2-A1. Page 1 of 2. ... (refer Figure 4 below for full workflow). ... To attribute this material,

References, links and additional information PC030 Protective Security Management Framework

Information Security Management Framework

ISMF Standard 140 – Notifiable Incidents - Cyber Security Incident Reporting

ISO/IEC 27035:2011 Information technology - Security techniques - Information security incident management

State ICT Support Plan

State Emergency Management Plan

This guideline does not aim to provide the reader with all of the responsibilities and obligations associated with Cyber Security Incident Reporting. It is highly recommended that agencies review all related documents in their entirety. The individual requirements of agencies will have direct bearing on what measures are implemented to mitigate identified risk(s).

Document Control

Licence

With the exception of the Government of South Australia brand, logos and any images, this work is licensed under a Creative Commons Attribution (CC BY) 4.0 Licence. To attribute this material, cite Department of the Premier and Cabinet, Government of South Australia, 2019.

Page 7 of 11 Public-I2-A1

ID DPC/G4.12

Version 1.2

Classification/DLM Public-I2-A1

Compliance Mandatory

Original authorisation date February 2014

Last approval date February 2019

Next review date February 2020

Page 8: Background  · Web viewPage 1 of 2. Public-I2-A1. Page 1 of 2. ... (refer Figure 4 below for full workflow). ... To attribute this material,

Appendix 1: Incident categoriesThese incident categories are used by the Watch Desk for categorisation and reporting purposes.

Term Description

Phishing or Social Engineering

Attempts to acquire information such as usernames, passwords or other sensitive using social engineering or technical subterfuge.

Spear Phishing Phishing or social engineering attempts that are specifically targeted against an individual or groups. These attempts make use of specific details which are unique to those being targeted to increase their probability of success.

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 government information.

Unauthorised access to information/systems

Unauthorised access from internal and external sources to Government information and systems.

Unauthorised release of or disclosure of information

Unauthorised release or disclosure of Government information to an unknown environment.

Malware infections Software programs designed to cause damage to Government systems.

Intrusions against networks

Intrusions specifically targeting Government internal infrastructure. This includes but is not limited to:

denial-of-service (DoS)/distributed denial-of-service (DDoS)

website defacements

brute force attempts.

Intrusion 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 Changes to privilege use settings on stand-alone or networked equipment including network profiles, local user or device configuration files that have not been approved through the agency’s change management process.

Unauthorised changes to information, applications, systems or hardware

Any unauthorised changes to an organisation’s file system, including media, through insertion, modification or deletion: e.g. changes to standard operating environments (SOEs), addition of executables or the modification of an executable’s configuration.Any unauthorised installation of additional processing, communications or storage equipment into the IT network. This includes but is not limited to: modems, portable games units, smart phones, PDAs or wireless access points.

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.

Page 8 of 11 Public-I2-A1

Page 9: Background  · Web viewPage 1 of 2. Public-I2-A1. Page 1 of 2. ... (refer Figure 4 below for full workflow). ... To attribute this material,

Term Description

Password confidentiality Sharing/stealing/loss of passwords or other authentication token.

Sabotage/physical damage

Any damage or destruction of physical information 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 fire, flood, excessive heat, storms, biological agents, toxic dispersion, riots, power outages.

Page 9 of 11 Public-I2-A1

Page 10: Background  · Web viewPage 1 of 2. Public-I2-A1. Page 1 of 2. ... (refer Figure 4 below for full workflow). ... To attribute this material,

Appendix 2; Cyber Security Incident Report FormThis form is only required for those occurrences that are deemed to be a cyber security incident. This form may be submitted at any stage of completion

Name Phone

Agency Email

Brief Description

Date & Time of Incident:

Incident Status

Reporting & Assistance

Has this incident been reported to any other agencies or organisations (SAPOL, Suppliers etc.?). If so, please list:

Do you require any assistance responding to this incident at this time? If so, please specify

Report SubmissionE-mail: [email protected] (business hours)Phone: (08) 8226 7513 (business hours)If you require immediate assistance out of hours, please contact the duty Watch Desk Officer on (08) 8232 3049.

Appendix 3: Post Incident Report FormPage 10 of 11 Public-I2-A1

Incident Impact

Is this incident affecting State Government Critical ICT Infrastructure (SGCII)?☐ Yes ☐ No

How do you rate the impact of this incident on your agency? (this may be an informal rating based on currently known information)

☐ High ☐Medium ☐Low

Incident Resolved Incident Ongoing Unknown

Page 11: Background  · Web viewPage 1 of 2. Public-I2-A1. Page 1 of 2. ... (refer Figure 4 below for full workflow). ... To attribute this material,

An incident cannot be closed by the Watch Desk until a Post Incident Report has been submitted. Please include all additional documentation

Reference Number (if provided)

Incident Title/Description

Date(s) of Incident:

Incident Outcome

Provide a short description of the incident outcome (resolutions, workarounds, findings, recommendations).

Attachments

List any attachments (e.g. Copies of internal post incident reports, log files, etc.).

Post Incident Report SubmissionThis form should be submitted within 30 days of the incident response process being completed.

E-mail: [email protected] (business hours)Mail: Watch Desk (Control Agency ICT Failure)

GPO Box 1484ADELAIDE SA 5001

DX: 142

Page 11 of 11 Public-I2-A1