A cyber security event is an occurrence of a system, service or network state indicating a possible breach of security policy, failure of safeguards or a previously unknown situation that may be relevant to security.
A cyber security incident is an unwanted or unexpected cyber security event, or a series of such events, that either has compromised business operations or has a significant probability of compromising business operations.
Cyber resilience is the ability to adapt to disruptions caused by cyber security incidents while maintaining continuous business operations. This includes the ability to detect, manage and recover from cyber security incidents.
One of the core elements of detecting and investigating cyber security incidents is the availability of appropriate data sources, such as event logs. The following event logs can be used by an organisation to assist with detecting and investigating cyber security incidents:
Further information on event logging can be found in the ‘Event logging and monitoring’ section of the Guidelines for system monitoring.
Further information on cyber security incident response plans can be found in the ‘System-specific cyber security documentation’ section of the Guidelines for cyber security documentation.
Further information on preparing for and responding to cyber security incidents can be found in ASD’s Cyber security incident response planning: Executive guidance and Cyber security incident response planning: Practitioner guidance publications.
Further information on understanding, identifying and preventing the insider threat can be found in the Attorney-General’s Department’s Countering the Insider Threat: A guide for Australian Government publication.
Further information on understanding, identifying and preventing the insider threat can also be found in the Australian Security Intelligence Organisation’s Countering the insider threat brochure and Countering the insider threat: A security manager’s guide publication.
Further information on understanding, identifying and preventing the insider threat can also be found on the United Kingdom’s National Protective Security Authority’s Insider Risk Guidance website.
Further information on developing, implementing and maintaining an insider threat mitigation program can be found in the United States’ Cybersecurity & Infrastructure Security Agency’s Insider Threat Mitigation Guide.
Further information on developing, implementing and maintaining an insider threat mitigation program can also be found in Carnegie Mellon University’s Software Engineering Institute’s Common Sense Guide to Mitigating Insider Threats, Seventh Edition publication.
Further information on reporting of cyber security incidents by service providers can be found in the ‘Managed services and cloud services’ section of the Guidelines for procurement and outsourcing.
Further information on reporting cybercrime incidents and reporting cyber security incidents, including ASD’s limited use obligation, is available from ASD.
Reporting cyber security incidents to the chief information security officer, or one of their delegates, as soon as possible after they occur or are discovered provides senior management with the opportunity to assess the impact to their organisation and to oversee any cyber security incident response activities. Note, an organisation should also be cognisant of any legislative obligations regarding the reporting of cyber security incidents to authorities.
Cyber security incidents are reported to the chief information security officer, or one of their delegates, as soon as possible after they occur or are discovered.
The Australian Signals Directorate (ASD) uses the cyber security incident reports it receives as the basis for providing assistance to organisations. In addition, cyber security incident reports are used to identify trends and maintain an accurate threat environment picture. Finally, ASD utilises this understanding to assist in the development of new and updated cyber security advice, capabilities, and techniques to better prevent and respond to evolving cyber threats. Note, under ASD’s limited use obligation, information voluntarily provided to ASD about cyber security incidents, or potential cyber security incidents, cannot be used for regulatory purposes.
An organisation is recommended to internally coordinate their reporting of cyber security incidents to ASD. In doing so, the organisation should be cognisant of any legislative obligations regarding the reporting of cyber security incidents to ASD.
The types of cyber security incidents that should be reported to ASD include:
Cyber security incidents are reported to ASD as soon as possible after they occur or are discovered.
Further information on cyber security incident response plans can be found in the ‘System-specific cyber security documentation’ section of the Guidelines for cyber security documentation.
Further information on handling malicious code infections can be found in National Institute of Standards and Technology Special Publication 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile.
Following a cyber security incident being identified, an organisation’s cyber security incident response plan should be enacted.
Following the identification of a cyber security incident, the cyber security incident response plan is enacted.
Where these guidelines refer to security clearances, it applies to Australian security clearances or security clearances from a foreign government which are formally recognised by Australia.
Further information on access to government resources, including required security clearances, can be found in the Department of Home Affairs’ Protective Security Policy Framework.
Further information on access to highly sensitive government resources, including required briefings, can be found in the Government Security Committee’s Australian Government Security Caveat Guidelines. This publication is available from the Protective Security Policy GovTEAMS community or the Australian Security Intelligence Organisation by email.
Further information on restricting the use of privileged user accounts can be found in ASD’s Restricting administrative privileges publication.
Further information on administering systems and their resources can be found in the ‘System administration’ section of the Guidelines for system management.
Further information on event logging can be found in the ‘Event logging and monitoring’ section of the Guidelines for system monitoring.
Privileged user accounts are considered those that can alter or circumvent system controls. This also applies to user accounts that may only have limited privileges but still have the ability to bypass some system controls.
Privileged user accounts are often targeted by malicious actors as they can potentially give full access to systems and their resources. As such, ensuring that privileged user accounts are prevented from accessing the internet, email and web services minimises opportunities for these accounts to be compromised. However, if privileged user accounts are explicitly authorised to access online services, they should be strictly limited to only what is required for users and services to undertake their duties.
Finally, centrally logging and analysing privileged access events, as well as privileged user account and security group management events, can assist in monitoring the security posture of systems and their resources, detecting malicious behaviour and contributing to investigations following cyber security incidents.
Requests for privileged access to systems and their resources are validated when first requested.
Privileged user accounts (excluding those explicitly authorised to access online services) are prevented from accessing the internet, email and web services.
Privileged user accounts explicitly authorised to access online services are strictly limited to only what is required for users and services to undertake their duties.
Privileged users are assigned a dedicated privileged user account to be used solely for duties requiring privileged access.
Privileged access events are centrally logged.
Privileged user account and security group management events are centrally logged.
Removing or suspending access to systems and their resources, ideally using an automatic mechanism, can prevent them from being accessed when there is no longer a legitimate business requirement for their use, such as when personnel change duties, leave an organisation or are detected undertaking malicious activities.
Privileged access to systems and their resources are disabled after 45 days of inactivity.
Privileged access to systems and their resources are disabled after 12 months unless revalidated.
Further information on cyber supply chain risk management can be found in the ‘Cyber supply chain risk management’ section of the Guidelines for procurement and outsourcing.
Further information on vendors that have made a pledge to implement Secure by Design and Secure by Default principles and practices can be found on the United States’ Cybersecurity & Infrastructure Security Agency’s Secure by Design Pledge website.
Further information on patching or updating operating systems can be found in the ‘System patching’ section of the Guidelines for system management.
Further information on hardening Microsoft Windows operating systems can be found in ASD’s Hardening Microsoft Windows 10 workstations and Hardening Microsoft Windows 11 workstations publications.
Further information on hardening Microsoft Windows operating systems can also be found in Microsoft’s Windows 11 Security Book and on the Microsoft Security Baselines Blog website.
Further information on hardening Linux workstations and servers can be found in ASD’s Hardening Linux workstations and servers publication.
Further information on exploit protection functionality within Microsoft Windows is available from Microsoft.
Further information on implementing application control can be found in ASD’s Implementing application control publication.
Further information on Microsoft’s recommended application blocklist and vulnerable driver blocklist are available from Microsoft.
Further information on command line process logging is available from Microsoft.
Further information on the use of PowerShell can be found in ASD’s Securing PowerShell in the enterprise publication.
Further information on the use of PowerShell by blue teams is available from Microsoft.
Further information on obtaining greater visibility through PowerShell logging is available from Google.
Further information on independent testing of security products’ ability to detect or prevent various stages of network intrusions is available from MITRE.
Further information on independent testing of antivirus applications is available from AV-Comparatives and AV-TEST.
Further information on the use of removable media can be found in the ‘Media usage’ section of the Guidelines for media.
Further information on event logging can be found in the ‘Event logging and monitoring’ section of the Guidelines for system monitoring.
Further information on security-relevant events to monitor for Apple macOS, Linux and Microsoft Windows operating systems can be found in the following ASD publications:
When operating systems are deployed in their default state, or with an unapproved configuration, it can lead to an insecure operating environment that may allow malicious actors to gain an initial foothold on networks. Many settings exist within operating systems to allow them to be configured in an approved secure state in order to minimise this security risk. As such, the Australian Signals Directorate (ASD) and vendors often produce hardening guidance to assist in hardening the configuration of operating systems. Note, however, in situations where ASD and vendor hardening guidance conflicts, precedence should be given to implementing the most restrictive guidance.
Internet Explorer 11 is disabled or removed.
Application control can be an effective way to not only prevent malicious code from executing on workstations and servers, but also to ensure only approved applications can execute. When developing application control rulesets, determining approved executables (e.g. .exe and .com files), libraries (e.g. .dll and.ocx files), scripts (e.g. .ps1, .bat, .cmd, .vbs and .js files), installers (e.g. .msi, .msp and .mst files), compiled HTML (e.g. .chm files), HTML applications (e.g. .hta files), control panel applets (e.g. .cpl files) and drivers based on business requirements is a more secure method than simply approving those already residing on a workstation or server. Furthermore, it is preferable that an organisation defines their own application control rulesets, rather than relying on those from application control vendors, and validate them on an annual or more frequent basis.
In implementing application control, an organisation should use a reliable method, or combination of methods, such as cryptographic hash rules, publisher certificate rules or path rules. Depending on the method chosen, further hardening may be required to ensure that application control mechanisms and application control rulesets cannot be bypassed by malicious actors.
Finally, centrally logging and analysing application control events can assist in monitoring the security posture of systems, detecting malicious behaviour and contributing to investigations following cyber security incidents.
Application control is implemented on workstations.
Application control is implemented on internet-facing servers.
Application control is applied to user profiles and temporary folders used by operating systems, web browsers and email clients.
Application control is applied to all locations other than user profiles and temporary folders used by operating systems, web browsers and email clients.
Application control restricts the execution of executables, libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organisation-approved set.
Microsoft’s recommended application blocklist is implemented.
Application control rulesets are validated on an annual or more frequent basis.
Allowed and blocked application control events are centrally logged.
The Command shell was the first shell developed by Microsoft to assist with the automation of routine system administration tasks, such as running Windows Commands via batch scripts. However, the Command shell can also be used by malicious actors to run Windows Commands on compromised systems. As such, centrally logging and analysing command line process creation events can assist in monitoring the security posture of systems, detecting malicious behaviour and contributing to investigations following cyber security incidents.
Command line process creation events are centrally logged.
PowerShell is a powerful scripting language developed by Microsoft and, due to its ubiquity and ease with which it can be used to fully control operating systems, is an important part of system administrator toolkits. However, PowerShell can also be a dangerous exploitation tool in the hands of malicious actors.
In order to prevent attacks leveraging vulnerabilities in earlier PowerShell versions, Windows PowerShell 2.0 should be disabled or removed from operating systems. Additionally, PowerShell’s language mode should be set to Constrained Language Mode to achieve a balance between security and functionality.
Finally, centrally logging and analysing PowerShell events can assist in monitoring the security posture of systems, detecting malicious behaviour and contributing to investigations following cyber security incidents.
PowerShell module logging, script block logging and transcription events are centrally logged.
This section is applicable to user applications typically installed on user workstations, such as office productivity suites, web browsers and their extensions, email clients, Portable Document Format (PDF) applications, and security products (e.g. antivirus applications, device access control applications, HIPS and software firewalls). Information on server applications can be found in the ‘Server application hardening’ section of these guidelines.
Further information on cyber supply chain risk management can be found in the ‘Cyber supply chain risk management’ section of the Guidelines for procurement and outsourcing.
Further information on vendors that have made a pledge to implement Secure by Design and Secure by Default principles and practices can be found on the United States’ Cybersecurity & Infrastructure Security Agency’s Secure by Design Pledge website.
Further information on patching or updating user applications can be found in the ‘System patching’ section of the Guidelines for system management.
Further information on the implementation and configuration of security products can be found in the ‘Operating system hardening’ section of these guidelines.
Further information on hardening Microsoft Office can be found in ASD’s Hardening Microsoft 365, Office 2021, Office 2019 and Office 2016 publication.
Further information on hardening Microsoft Office can also be found on the Microsoft Security Baselines Blog website.
Further information on hardening Microsoft Edge can be found on the Microsoft Security Baselines Blog website.
Further information on hardening Google Chrome can be found in Google’s Chrome Browser Enterprise Security Configuration Guide (Windows).
Further information on hardening Adobe Reader and Adobe Acrobat can be found in Adobe’s Security Configuration Guide for Acrobat publication.
Further information on Microsoft’s attack surface reduction rules can be found on Microsoft’s attack surface reduction rules overview website.
Further information on configuring Microsoft Office macro settings can be found in ASD’s Restricting Microsoft Office macros publication.
When user applications are deployed in their default state, or with an unapproved configuration, it can lead to an insecure operating environment that may allow malicious actors to gain an initial foothold on networks. This can be especially risky for office productivity suites, web browsers and their extensions, email clients, PDF applications, and security products as such applications are routinely targeted for exploitation. Many settings exist within such applications to allow them to be configured in an approved secure state in order to minimise this security risk. As such, ASD and vendors often produce hardening guidance to assist in hardening the configuration of these applications. Note, however, in situations where ASD and vendor hardening guidance conflicts, precedence should be given to implementing the most restrictive guidance.
Microsoft Office is blocked from creating child processes.
Microsoft Office is blocked from creating executable content.
Microsoft Office is blocked from injecting code into other processes.
Microsoft Office is configured to prevent activation of Object Linking and Embedding packages.
Office productivity suites are hardened using ASD and vendor hardening guidance, with the most restrictive guidance taking precedence when conflicts occur.
Office productivity suite security settings cannot be changed by users.
Web browsers do not process Java from the internet.
Web browsers do not process web advertisements from the internet.
Web browsers are hardened using ASD and vendor hardening guidance, with the most restrictive guidance taking precedence when conflicts occur.
Web browser security settings cannot be changed by users.
PDF applications are blocked from creating child processes.
PDF applications are hardened using ASD and vendor hardening guidance, with the most restrictive guidance taking precedence when conflicts occur.
PDF application security settings cannot be changed by users.
Microsoft Office files can contain embedded code, known as a macro, written in the Visual Basic for Applications programming language. A macro can contain a series of commands that can be coded or recorded and replayed at a later time to automate repetitive tasks. Macros are powerful tools that can be easily created by users to greatly improve their productivity. However, malicious actors can also create macros to perform a variety of malicious activities, such as assisting to compromise workstations in order to exfiltrate or deny access to data. To reduce this security risk, an organisation should disable Microsoft Office macros for users that do not have a demonstrated business requirement and secure their use for the remaining users that do.
Microsoft Office macros are disabled for users that do not have a demonstrated business requirement.
Microsoft Office macros in files originating from the internet are blocked.
Microsoft Office macro antivirus scanning is enabled.
Microsoft Office macros are blocked from making Win32 API calls.
Microsoft Office macro security settings cannot be changed by users.
The guidance within this section is equally applicable to all user accounts unless specified otherwise. This includes unprivileged user accounts and privileged user accounts, which includes break glass accounts and service accounts. In addition, the guidance is equally applicable to interactive authentication and non-interactive authentication.
Further information on implementing multi-factor authentication can be found in ASD’s Implementing multi-factor authentication publication.
Further information on event logging can be found in the ‘Event logging and monitoring’ section of the Guidelines for system monitoring.
Further information on randomly generating passphrases is available from the Electronic Frontier Foundation while a random dice roller is available from RANDOM.ORG.
Further information on how to secure group Managed Service Accounts in Microsoft Windows Server is available from Microsoft.
Further information on changing credentials for the Kerberos Key Distribution Center’s service account can be found in Microsoft’s Active Directory accounts and Active Directory Forest Recovery - Reset the krbtgt password publications. A script for changing credentials for this service account is also available from Microsoft.
Further information memory integrity functionality is available from Microsoft.
Further information on Local Security Authority protection functionality is available from Microsoft.
Further information on Credential Guard functionality and Remote Credential Guard functionality is available from Microsoft.
Multi-factor authentication uses two or more different authentication factors. This may include:
Users of online services, privileged users of systems and users with access to data repositories are more likely to be targeted by malicious actors due to their access. For this reason, it is especially important that multi-factor authentication is used for these user accounts. In addition, multi-factor authentication is vital to any administrative activities as it can limit the consequences of a compromise by preventing or slowing malicious actors’ ability to gain unrestricted access to assets. In this regard, multi-factor authentication can be implemented as part of jump server authentication where assets being administered do not support multi-factor authentication themselves.
When implementing multi-factor authentication, several different authentication factors can be implemented. Unfortunately, some authentication factors, such as biometrics or codes sent via Short Message Service, Voice over Internet Protocol or email, are more susceptible to compromise than others. For this reason, authentication factors that involve something users have should be used with something users know. Alternatively, something users have that is unlocked by something users know or are (often known as passwordless multi-factor authentication) can be used. Furthermore, for increased security, the use of phishing-resistant multi-factor authentication is recommended to protect against real-time phishing attacks.
Finally, centrally logging and analysing multi-factor authentication events can assist in monitoring the security posture of systems, detecting malicious behaviour and contributing to investigations following cyber security incidents.
Multi-factor authentication is used to authenticate users to their organisation’s online services that process, store or communicate their organisation’s sensitive data.
Multi-factor authentication is used to authenticate users to third-party online services that process, store or communicate their organisation’s sensitive data.
Multi-factor authentication (where available) is used to authenticate users to third-party online services that process, store or communicate their organisation’s non-sensitive data.
Multi-factor authentication is used to authenticate users to their organisation’s online customer services that process, store or communicate their organisation’s sensitive customer data.
Multi-factor authentication is used to authenticate users to third-party online customer services that process, store or communicate their organisation’s sensitive customer data.
Multi-factor authentication is used to authenticate customers to online customer services that process, store or communicate sensitive customer data.
Multi-factor authentication is used to authenticate privileged users of systems.
Multi-factor authentication is used to authenticate unprivileged users of systems.
Multi-factor authentication uses either: something users have and something users know, or something users have that is unlocked by something users know or are.
Multi-factor authentication used for authenticating users of online services is phishing-resistant.
Multi-factor authentication used for authenticating customers of online customer services provides a phishing-resistant option.
Multi-factor authentication used for authenticating users of systems is phishing-resistant.
Successful and unsuccessful multi-factor authentication events are centrally logged.
When built-in Administrator accounts, break glass accounts, local administrator accounts and service accounts use common usernames or weak credentials, it may allow malicious actors that compromise credentials on one workstation or server to easily compromise other workstations and servers. As such, it is critical that credentials for the built-in Administrator account, break glass accounts, local administrator accounts and service accounts in each domain are long, unique, unpredictable and managed.
To provide additional security and credential management functionality for service accounts, Microsoft introduced group Managed Service Accounts to Microsoft Windows Server. In doing so, service accounts that are created as group Managed Service Accounts do not require manual credential management by system administrators, as the operating system automatically ensures that they are long, unique, unpredictable and managed. This ensures that service account credentials are secure, not misplaced or forgotten, and that they are automatically changed on a regular basis. However, in cases where the use of group Managed Service Accounts is not possible, credentials for service accounts should still be unique, unpredictable and random with a minimum length of 30 characters.
Credentials for break glass accounts, local administrator accounts and service accounts are long, unique, unpredictable and managed.
System administration of cloud services brings unique challenges when compared to system administration of on-premises assets. Notably, responsibility for system administration of cloud services is often shared between service providers and their customers. As the system administration processes and procedures implemented by service providers are often opaque to their customers, customers should consider a service provider’s control plane to operate within a different security domain.
Further information on system administration can be found in the Australian Signals Directorate’s (ASD) Secure administration publication.
Further information on change and configuration management plans can be found in the ‘System-specific cyber security documentation’ section of the Guidelines for cyber security documentation.
Further information on the use of privileged user accounts for system administration activities can be found in the ‘Access to systems and their resources’ section of the Guidelines for personnel security.
Further information on network segmentation and segregation can be found in the ‘Network design and configuration’ section of the Guidelines for networking.
One of the greatest threats to the security of networks is the compromise of privileged user accounts. Providing a separate privileged operating environment for system administrators, in addition to their unprivileged operating environment, makes it much harder for administrative activities and privileged user accounts to be compromised by malicious actors.
Using different physical workstations, with one being a dedicated Secure Admin Workstation, is the most secure approach to separating privileged and unprivileged operating environments for system administrators. However, a trusted and hardened virtualisation-based solution may be sufficient for separating privileged and unprivileged operating environments on the same Secure Admin Workstation. In such cases, privileged operating environments should not be virtualised within unprivileged operating environments.
Privileged users use separate privileged and unprivileged operating environments.
Privileged operating environments are not virtualised within unprivileged operating environments.
Unprivileged user accounts cannot logon to privileged operating environments.
Privileged user accounts (excluding local administrator accounts) cannot logon to unprivileged operating environments.
The security of administrative activities can be improved by segregating administrative infrastructure from the wider network and the internet. In doing so, the use of a jump server (also known as a jump host or jump box) that allows only necessary ports and services to be used can be an effective way of simplifying and securing administrative activities. Specifically, a jump server can provide filtering of network management traffic while also acting as a focal point to perform multi-factor authentication; store and manage administrative tools; and perform logging, monitoring and alerting activities. In addition, using separate jump servers for the administration of critical servers (such as Microsoft Active Directory Domain Services domain controllers, Microsoft Active Directory Certificate Services Certification Authority servers, Microsoft Active Directory Federation Services servers and Microsoft Entra Connect servers), high-value servers (such as Domain Name System servers, database servers, email servers, file servers and web servers) and regular servers can further assist in protecting these assets.
Administrative activities are conducted through jump servers.
Further information on system patching can be found in ASD’s Patching applications and operating systems publication.
Further information on patching evaluated products can be found in the ‘Evaluated product usage’ section of the Guidelines for evaluated products.
Further information on managing risks associated with legacy IT can be found in ASD’s Managing the risks of legacy IT: Executive guidance and Managing the risks of legacy IT: Practitioner guidance publications.
Further information on cessation of support for Microsoft Windows operating systems, including potential compensating controls for use beyond their cessation date for support, can be found in ASD’s End of support for Microsoft Windows and Microsoft Windows Server publication.
Further information on hardening user applications can be found in the ‘User application hardening’ section of the Guidelines for system hardening.
Further information on hardening server applications can be found in the ‘Server application hardening’ section of the Guidelines for system hardening.
To ensure that patches or updates are being applied to applications, operating systems, drivers and firmware, it is essential that an organisation regularly identifies all assets within their environment using an automated method of asset discovery, such as an asset discovery tool or a vulnerability scanner with equivalent functionality. Following asset discovery, identified assets can be scanned for missing patches or updates using a vulnerability scanner with an up-to-date vulnerability database. Ideally, vulnerability scanning should be conducted in an automated manner and take place at twice the frequency in which patches or updates need to be applied. For example, if patches or updates are to be applied within two weeks of release then vulnerability scanning should be undertaken at least weekly.
An automated method of asset discovery is used at least fortnightly to support the detection of assets for subsequent vulnerability scanning activities.
A vulnerability scanner with an up-to-date vulnerability database is used for vulnerability scanning activities.
A vulnerability scanner is used at least daily to identify missing patches or updates for vulnerabilities in online services.
A vulnerability scanner is used at least weekly to identify missing patches or updates for vulnerabilities in office productivity suites, web browsers and their extensions, email clients, PDF applications, and security products.
A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in applications other than office productivity suites, web browsers and their extensions, email clients, PDF applications, and security products.
A vulnerability scanner is used at least daily to identify missing patches or updates for vulnerabilities in operating systems of internet-facing servers and internet-facing network devices.
A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in operating systems of workstations, non-internet-facing servers and non-internet-facing network devices.
When patches or updates are released by vendors for vulnerabilities, an organisation should apply them in a timeframe commensurate with the likelihood of attempted exploitation by malicious actors. For example, by prioritising patches or updates for vulnerabilities in online services as well as operating systems of internet-facing servers and internet-facing network devices. This is especially important when vulnerabilities are assessed as critical by vendors or working exploits exist.
If no patches or updates are available for vulnerabilities, mitigation advice from vendors, trustworthy authorities or security researchers may provide some protection until patches or updates are made available. Such mitigation advice may be published in conjunction with, or soon after, announcements made relating to vulnerabilities. Mitigation advice may cover how to disable or block access to vulnerable functionality, how to reconfigure vulnerable functionality, or how to detect attempted or successful exploitation of vulnerable functionality.
If a patch or update is released for high assurance IT equipment, ASD will conduct an assessment of the patch or update. Subsequently, if the patch or update is approved for deployment, ASD will provide guidance on the methods and timeframes in which it is to be applied.
Patches, updates or other vendor mitigations for vulnerabilities in online services are applied within 48 hours of release when vulnerabilities are assessed as critical by vendors or when working exploits exist.
Patches, updates or other vendor mitigations for vulnerabilities in online services are applied within two weeks of release when vulnerabilities are assessed as non-critical by vendors and no working exploits exist.
Patches, updates or other vendor mitigations for vulnerabilities in office productivity suites, web browsers and their extensions, email clients, PDF applications, and security products are applied within two weeks of release.
Patches, updates or other vendor mitigations for vulnerabilities in applications other than office productivity suites, web browsers and their extensions, email clients, PDF applications, and security products are applied within one month of release.
Patches, updates or other vendor mitigations for vulnerabilities in operating systems of internet-facing servers and internet-facing network devices are applied within 48 hours of release when vulnerabilities are assessed as critical by vendors or when working exploits exist.
Patches, updates or other vendor mitigations for vulnerabilities in operating systems of internet-facing servers and internet-facing network devices are applied within two weeks of release when vulnerabilities are assessed as non-critical by vendors and no working exploits exist.
Patches, updates or other vendor mitigations for vulnerabilities in operating systems of workstations, non-internet-facing servers and non-internet-facing network devices are applied within one month of release.
When applications, operating systems, network devices and networked IT equipment reach their cessation date for support, and become legacy IT, an organisation will find it increasingly difficult to protect them against vulnerabilities as patches, updates and other forms of support will no longer be made available by vendors. As such, unsupported applications, operating systems, network devices and networked IT equipment should be removed or replaced.
In planning for cessation of support, it is important to note that while vendors generally advise the cessation date for support of operating systems well in advance, some applications, network devices and networked IT equipment may cease to receive support immediately after newer versions are released.
Finally, when the immediate removal or replacement of unsupported applications, operating systems, network devices or networked IT equipment is not possible, compensating controls should be implemented until such time that they can be removed or replaced.
Online services that are no longer supported by vendors are removed.
Office productivity suites, web browsers and their extensions, email clients, PDF applications, Adobe Flash Player, and security products that are no longer supported by vendors are removed.
Operating systems that are no longer supported by vendors are replaced.
Further information on digital preservation planning and data retention is available from the National Archives of Australia.
Further information on the collection and retention of personal information can be found in the Office of the Australian Information Commissioner’s Australian Privacy Principles and the associated Australian Privacy Principles guidelines.
Further information on business continuity and disaster recovery planning can be found in the ‘Chief information security officer’ section of the Guidelines for cyber security roles.
To mitigate the security risk of losing system availability or data as part of a ransomware attack, or other form of destructive attack, backups of data, applications and settings should be performed and retained in accordance with an organisation’s business criticality and business continuity requirements. In doing so, backups of all data, applications and settings should be synchronised to enable restoration to a common point in time. Furthermore, it is essential that all backups are retained in a secure and resilient manner. This will ensure that should a system fall victim to a ransomware attack, or other form of destructive attack, data will not be lost and, if necessary, systems can be quickly restored.
Backups of data, applications and settings are performed and retained in accordance with business criticality and business continuity requirements.
Backups of data, applications and settings are synchronised to enable restoration to a common point in time.
Backups of data, applications and settings are retained in a secure and resilient manner.
To mitigate the security risk of unauthorised access to backups, an organisation should ensure that access to backups is controlled through the use of appropriate access controls.
Unprivileged user accounts cannot access backups belonging to other user accounts.
Privileged user accounts (excluding backup administrator accounts) cannot access backups belonging to other user accounts.
To mitigate the security risk of backups being accidentally or maliciously modified or deleted, an organisation should ensure that backups are sufficiently protected from unauthorised modification and deletion through the use of appropriate access controls during their retention period.
Unprivileged user accounts are prevented from modifying and deleting backups.
Privileged user accounts (excluding backup administrator accounts) are prevented from modifying and deleting backups.
To ensure that backups can be restored when the need arises, and that any dependencies can be identified and managed beforehand, it is important that the restoration of data, applications and settings from backups to a common point in time is tested in a coordinated manner as part of disaster recovery exercises.
Restoration of data, applications and settings from backups to a common point in time is tested as part of disaster recovery exercises.
These guidelines are intended for security-relevant event logs. They are not intended for non-security-relevant event logs, such as operating system and application performance-related event logs.
Further information on logging intrusion activity can be found in the ‘Managing cyber security incidents’ section of the Guidelines for cyber security incidents.
Further information on event logging for application-based security products can be found in the ‘Operating system hardening’ section of the Guidelines for system hardening.
Further information on event logging for artificial intelligence applications can be found in the ‘Software development fundamentals’ section of the Guidelines for software development.
Further information on event logging for Cross Domain Solutions can be found in the ‘Cross Domain Solutions’ section of the Guidelines for gateways.
Further information on event logging for databases can be found in the ‘Databases’ section of the Guidelines for database systems.
Further information on event logging for gateways can be found in the ‘Gateways’ section of the Guidelines for gateways.
Further information on event logging for mobile applications can be found in the ‘Software development fundamentals’ section of the Guidelines for software development.
Further information on event logging for multifunction devices can be found in the ‘Multifunction devices’ section of the Guidelines for communications systems.
Further information on event logging for network-based security products can be found in the ‘Network design and configuration’ section of the Guidelines for networking.
Further information on event logging for operating systems can be found in the ‘Operating system hardening’ and ‘Authentication hardening’ sections of the Guidelines for system hardening.
Further information on event logging for server applications can be found in the ‘Server application hardening’ section of the Guidelines for system hardening.
Further information on event logging for system access can be found in the ‘Access to systems and their resources’ section of the Guidelines for personnel security.
Further information on event logging for user applications can be found in the ‘User application hardening’ section of the Guidelines for system hardening.
Further information on event logging for web applications can be found in the ‘Software development’ section of the Guidelines for software development.
Further information on event logging for web proxies can be found in the ‘Web proxies’ section of the Guidelines for gateways.
Further information on event logging can be found in the following Australian Signals Directorate publications:
Further information on SIEM and SOAR platforms can be found in the Australian Signals Directorate’s Implementing SIEM and SOAR platforms: Executive guidance and Implementing SIEM and SOAR platforms: Practitioner guidance publications.
Further information on prioritising the collection and storage of event logs can be found in the United States’ Cybersecurity & Infrastructure Security Agency’s Guidance for Implementing M-21-31: Improving the Federal Government's Investigative and Remediation Capabilities publication.
Further information on the National Archives of Australia’s requirements for event log retention can be found in their AFDA Express Version 2 – Technology & Information Management publication.
A centralised event logging facility can be used to capture, protect and manage event logs from multiple sources in a coordinated manner. This may be achieved by using a Security Information and Event Management (SIEM) platform, a Security Orchestration, Automation and Response (SOAR) platform, or both. Furthermore, in support of a centralised event logging facility, it is important that an accurate and consistent time source is used to assist with identifying connections between events.
Event logs are protected from unauthorised modification and deletion.
Event log monitoring is critical to maintaining the security posture of systems. Notably, such activities involve analysing event logs in a timely manner to detect cyber security events, thereby, leading to the identification of cyber security incidents.
Event logs from internet-facing servers are analysed in a timely manner to detect cyber security events.
Cyber security events are analysed in a timely manner to identify cyber security incidents.