Essential Eight Assessment Process Guide

Introduction

The Australian Signals Directorate (ASD) has developed prioritised mitigation strategies, in the form of the Strategies to Mitigate Cyber Security Incidents, to help organisations protect themselves against various cyber threats. The most effective of these mitigation strategies are the Essential Eight.

This publication details a process for undertaking assessments of the Essential Eight. In doing so, it includes guidance on assessment methods that can be used for assessing both the implementation and effectiveness of controls that underpin the Essential Eight – as articulated within the Essential Eight Maturity Model (November 2023 release).

This publication should be read and used in conjunction with other ASD guidance and tools. This includes the:

• Essential Eight Maturity Model
• Essential Eight Maturity Model FAQ
• Essential Eight Assessment Report Template
• Essential Eight assessment toolkit.

Note, all vendor products mentioned within this publication are for illustrative purposes only and should not be interpreted as an explicit endorsement by ASD.

Overview

Assessments against the Essential Eight are conducted using the Essential Eight Maturity Model. This maturity model describes three target maturity levels (Maturity Level One through to Maturity Level Three) which are based on mitigating increasing levels of tradecraft (i.e. tools, tactics, techniques and procedures) and targeting. The maturity model also includes Maturity Level Zero which exists for capturing instances in which the requirements of Maturity Level One are not met.

Although the approach to conducting an assessment depends on the size and complexity of a system, there are foundational principles that are common to each assessment. As such, the guidance in this publication should be incorporated by assessors, noting that assessors should still use their own judgement and expertise.

Finally, in determining compensating control effectiveness, assessors should ensure that any compensating controls that have been implemented provide an equivalent level of protection to those recommended under the Essential Eight. This will assist in ensuring that an equivalent level of overall protection against a specific level of tradecraft and targeting can be achieved and maintained.

Evidence quality

In conducting an assessment, assessors need to gather and review credible evidence to support conclusions they draw on the effectiveness of controls. In general terms, the evidence used to determine the effectiveness of controls will vary in quality depending on the approach taken. As such, when conducting an assessment, assessors should seek to gather and use the highest quality evidence where reasonably practicable. This guide defines four levels of evidence quality:

• Excellent evidence: Testing a control with a simulated activity designed to confirm it is in place and effective (e.g. attempting to run a test application to check application control rulesets).
• Good evidence: Reviewing the configuration of a system through the system’s interface to determine whether it should enforce an expected policy.
• Fair evidence: Reviewing a copy of a system’s configuration (e.g. using reports or screenshots) to determine whether it should enforce an expected policy.
• Poor evidence: A policy or verbal statement of intent (e.g. sighting mention of controls within documentation or controls being discussing during interviews with personnel administering or managing system security).

Determining effective implementation of mitigation strategies

Upon concluding assessment activities, assessors will need to determine whether mitigation strategies were implemented effectively or not. This determination requires a combination of judgement and consideration of the following factors:

• adoption of a risk-based approach to the implementation of mitigation strategies
• ability to test the mitigation strategies across an accurate representative sample of workstations (including laptops), servers and network devices
• level of assurance gained from assessment activities and any evidence provided (noting the quality of evidence)
• any exceptions, including associated compensating controls, and whether they have been accepted by an appropriate authority as part of a formal exception process.

Assessors should use ASD’s standardised assessment outcomes which are:

• Not assessed: The control has not yet been assessed.
• Effective: The organisation is effectively meeting the control’s objective.
• Alternate control: The organisation is effectively meeting the control’s objective through an alternate control.
• Ineffective: The organisation is not adequately meeting the control’s objective.
• No visibility: The assessor was unable to obtain adequate visibility of a control’s implementation.
• Not implemented: The organisation has decided not to implement the control.
• Not applicable: The control does not apply to the system or environment.

It is important that assessors do not allow risk acceptance as a justification for not implementing an entire mitigation strategy (e.g. a system owner has risk accepted not implementing application control or multi-factor authentication). In these cases, without adequate compensating controls, the mitigation strategy is considered to be not implemented.

For a system owner to claim they have implemented a mitigation strategy, all controls specified within the mitigation strategy must be assessed as ‘effective’ or ‘alternate control’. If one of the controls specified for a mitigation strategy is assessed as ‘ineffective’, the system owner cannot claim to have met the requirements for that maturity level. In turn, this applies to the determination of whether a system owner has met the target maturity level for their system (i.e. if one or more mitigation strategies are deemed to have not been implemented then the target maturity level for the system cannot be claimed to have been met).

Where exceptions to a mitigation strategy’s controls have been identified, the assessor should review and evaluate any compensating controls that are in place to determine whether they address the intent of the original controls and are implemented effectively. Two examples have been provided below.

Example: During an internal review, an organisation identified a low-risk Microsoft Windows server that could not be patched. As a result, the organisation implemented a plan to decommission the server within two months.

In this situation, it was still important for the organisation to apply compensating controls to reduce the identified risk to an acceptable level, and to align with the requirements of the Essential Eight’s exception process. As a result, a risk owner was assigned and strong compensating controls were put in place.

In this instance, as the exception was being effectively managed and strong compensating controls had been put in place, an assessor determined that the exception should not preclude the organisation from reaching their target maturity level. Conversely, if the organisation had not applied strong compensating controls, it would not have aligned with the requirements of the Essential Eight’s exception process and should have been precluded from reaching their target maturity level.

Example: During an internal review, an organisation identified a cloud service that did not have multi-factor authentication functionality enabled. In assessing the situation, the organisation decided it was not worth the time and effort to enable such functionality, not to mention the complaints they expected they would receive from users. As such, the organisation chose to simply accept the risk of not implementing a control rather than implementing strong compensating controls.

In this instance, as the exception was not being effectively managed, nor were strong compensating controls in place, an assessor determined that the organisation should be precluded from reaching their target maturity level.

It is important that the use of exceptions for a system are documented and approved by an appropriate authority through a formal process. Documentation for exceptions should include the following:

• detail, scope and justification for exceptions
• detail of compensating controls associated with exceptions, including:
  • detail, scope and justification for compensating controls
  • expected lifetime of compensating controls
  • when compensating controls will next be reviewed
• system risk rating before and after the implementation of compensating controls
• any caveats placed on the use of the system as a result of exceptions
• acceptance by an appropriate authority of the residual risk for the system
• when the necessity of exceptions will next be considered by an appropriate authority (noting exceptions should not be approved beyond one year).

The appropriate use of a formal exception process, along with compensating controls, should not preclude an organisation from being assessed as meeting the requirements for their target maturity level.

Stages of an assessment

At a high-level, assessments are comprised of four stages:

• Stage 1: The assessor plans and prepares for the assessment.
• Stage 2: The assessor determines the scope (i.e. assessment boundary) and approach for the assessment.
• Stage 3: The assessor assesses the controls associated with each of the mitigation strategies.
• Stage 4: The assessor develops the security assessment report.

The activities and considerations for each stage of an assessment are discussed in further detail below.

Stage 1: Assessment planning and preparation

Assessment planning

Prior to commencing an assessment, the assessor should conduct assessment planning activities. These activities require the assessor to discuss with the system owner:

• assessment scope (i.e. assessment boundary) and assessment approach (see further detail below)
• access to unprivileged and privileged user accounts, devices, documentation, personnel, and facilities
• any approvals required to run scripts and tools on the system (see further detail below)
• evidence collection and protection, including any requirements following the conclusion of the assessment
• where the security assessment report will be developed (e.g. on an assessor’s device or on an alternative device)
• approach to stakeholder engagement and consultation (including key points of contact)
• whether any service providers manage aspects of the system (including appropriate points of contact)
• access to any relevant prior security assessment reports for the system
• appropriate use, retention and marketing of the security assessment report by both parties.

Assessors may also develop an assessment test plan and share it with the system owner.

Stage 2: Determination of assessment scope and approach

Determine assessment scope

In determining the assessment scope (i.e. assessment boundary), assessors should first clarify the target maturity level with the system owner, noting that the Essential Eight is required to be implemented and assessed as a package. For example, if a system owner has not previously had an assessment demonstrating that they have implemented Maturity Level One, they should not begin an assessment against Maturity Level Two until they have done so, and likewise for Maturity Level Two before being assessed against Maturity Level Three.

Having identified a suitable target maturity level, the assessor should familiarise themselves with the requirements for that maturity level as it will impact the components or aspects of the system within scope of the assessment.

Once the scope of the assessment has been identified, and agreed upon with the system owner, a more accurate determination of the assessment’s duration and any milestones will likely be possible.

The scope of the assessment should be documented within the security assessment report. Any components or aspects of a system deemed out of scope should also be documented and accompanied by a justification for their exclusion.

Determine assessment approach

In determining a suitable assessment approach, both qualitative and quantitative testing techniques should be considered. For example, qualitative testing techniques include documentation reviews and interviews with personnel administering or managing system security, while quantitative testing techniques include system configuration reviews and the use of scripts and tools. Sample sizes for testing should also be determined in consultation with the system owner, with the aim of assessing a reasonable representative sample of workstations (including laptops), servers and network devices.

Conducting assessments using interviews, reports and screenshots will always be inferior to conducting assessments using scripts and tools. Particularly as scripts and tools often assess many workstations and servers on a network, rather than a single sample workstation or server, and often identify issues that may be missed in interviews or overlooked by human analysis of reports and configuration settings. If adequate assessment scripts and tools are not already present on a system, assessors may seek to use their own scripts and tools following approval by the system owner.

Any assessment limitations, including sample sizes and constraints on technical testing, should be documented within the security assessment report.

Stage 3: Assessment of controls

The assessment of each mitigation strategy is performed by reviewing and testing the effectiveness of controls. This section provides guidance on the approach to assessing each mitigation strategy at a given maturity level, along with relevant assessment considerations. Guidance on determining the effectiveness of controls within each mitigation strategy is also provided within this section.

Assessment guidance for maturity levels in this section is cumulative. For example, the guidance provided in the Maturity Level Two section is focused on unique requirements above those of Maturity Level One. Likewise, the guidance provided in the Maturity Level Three section is focused on unique requirements above those of Maturity Level Two. This aligns with the manner in which assessments should be conducted against target maturity levels.

Maturity Level One

The focus of this maturity level is malicious actors who are content to simply leverage commodity tradecraft that is widely available in order to gain access to, and likely control of, a system. For example, malicious actors opportunistically using a publicly-available exploit for a vulnerability in an online service which has not been patched, or authenticating to an online service using credentials that were stolen, reused, brute forced or guessed.

Generally, malicious actors are looking for any victim rather than a specific victim and will opportunistically seek common weaknesses in many targets rather than investing heavily in gaining access to a specific target. Malicious actors will employ common social engineering techniques to trick users into weakening the security of a system and launch malicious applications. If user accounts that malicious actors compromise have special privileges they will exploit it. Depending on their intent, malicious actors may also destroy data (including backups).

Patch applications

Context

Most vendors of online services and applications regularly release updated versions to fix vulnerabilities. As such, online services and applications can be compared to the latest versions available from vendors to determine whether existing versions are the latest, and if not, how long ago updates were made available based on release dates and patch notes. Services such as the SANS Internet Storm Centre, Microsoft Security Response Centre or the Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities Catalog can be used to determine the criticality of vulnerabilities and whether working exploits exist or not.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

Patch operating systems

Context

Operating system vendors regularly publish updates to mitigate vulnerabilities. In addition, unsupported operating systems of internet-facing servers and internet-facing network devices are often common targets for malicious actors.

While operating systems of workstations, non-internet-facing servers and non-internet-facing network devices are at a lower risk of exploitation, as malicious actors need to compromise another system to then obtain network-based access to the unpatched operating system, it is still important that such operating systems are patched in a reasonable timeframe given the level of tradecraft and targeting the system owner is attempting to protect their system against.

Services such as the SANS Internet Storm Centre, Microsoft Security Response Centre or the Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities Catalog can be used to determine the criticality of vulnerabilities and whether working exploits exist or not.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

Multi-factor authentication

Context

Multi-factor authentication is one of the most effective controls an organisation can implement to prevent malicious actors from gaining access to a system, online service or application. When implemented correctly, multi-factor authentication can make it significantly more difficult for malicious actors to steal and abuse legitimate credentials as it is not as susceptible to brute force attacks that target traditional single-factor authentication methods based on memorised secrets (e.g. personal identification numbers [PINs], passwords and passphrases).

At this maturity level, the implementation of multi-factor authentication should focus on online services. In addition, the authentication factors that can be used, and in what combination, are restricted to avoid weaker multi-factor authentication implementations. Specifically, acceptable multi-factor authentication implementations include:

• something users have (i.e. look-up secret, out-of-band device, single-factor one-time PIN [OTP] devices, single-factor cryptographic software or single factor cryptographic device) in addition to something users know (i.e. a memorised secret)
• something users have that is unlocked by something users know or are (i.e. multi-factor OTP device, multi-factor cryptographic software or multi-factor cryptographic device).

Biometrics are not acceptable at this maturity level. This is due to biometric characteristics not being secrets, biometric matching being probabilistic rather than deterministic and there being a reliance on the security of biometric capture software installed on devices. However, biometrics can be used to unlock another authentication factor (e.g. a certificate stored in a Trusted Platform Module or an OTP generator app on a smartphone). Trusted Signals are also not acceptable at this maturity level. This is due to issues associated with placing trust in the signal itself, which can be targeted and spoofed by malicious actors.

While not excluded at this maturity level, organisations may want to avoiding authentication methods increasingly being subject to MFA fatigue or social engineering attempts by malicious actors, such as push notifications and SMS codes.

Finally, at this maturity level, organisations may choose to implement multi-factor authentication solutions that are phishing-resistant, such as security keys, smart cards or passkeys, if they intend to eventually implement requirements for higher maturity levels.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

Restrict administrative privileges

Context

Policies, processes and procedures for managing privileged access to systems, applications and data repositories should be documented and enforced within organisational workflows. In doing so, privileged access to systems, applications and data repositories should be requested via a form, service desk ticket or email from users, and require approval from a supervisor or either an application owner or data repository owner, to maintain a record of all such requests. System owners should also maintain a list of all applications and data repositories on their system that require privileged access.

Privileged user accounts are often targeted by malicious actors for their greater control over, and access to, organisational resources. For this reason, privileged user accounts should not have access to the internet, email and web services except in specific circumstances in which such access is explicitly authorised and strictly limited to only what is required for such user accounts to undertake their duties.

Note, while no constraints are placed on how privileged and unprivileged operating environments are separated for privileged users at Maturity Level One, organisations may choose to implement an approach that avoids virtualising a privileged operating environment within an unprivileged operating environment if they intend to eventually implement requirements for higher maturity levels.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

Application control

Context

At this maturity level, the use of an application control solution is required. This may be one of the in-built solutions from Microsoft (e.g. AppLocker or Windows Defender Application Control) or it may be a third-party solution (e.g. AirLock Digital’s AirLock, Ivanti’s Device and Application Control, Trend Micro Endpoint Application Control or VMWare Carbon Black App Control).

Application control assessments can be done without tools but efforts will be severely limited in their effectiveness and are likely to miss edge cases that malicious actors would look to exploit. For example, malicious actors may use custom tools to scan for weak or vulnerable paths on a system. This could be achieved with a Microsoft Office macro.

It is important to note that depending on the application control solution implemented, it may not support compiled Hypertext Markup Language (HTML) (.chm files), HTML applications (.hta files) and control panel applets (.cpl files).

When conducting application control assessments, paths for standard user profiles and temporary folders used by operating systems, web browsers and email clients can include those listed below. Note, depending on the system configuration, there may be overlap (e.g. %temp% and %tmp% generally reside within %userprofile%\*).

• %userprofile%\*
• %temp%\*
• %tmp%\*
• %windir%\Temp\*.

To check if application control is implemented within the user profile directory, attempt to run benign executable files inside the directory. The executables tested should cover .exe, .com, .dll, .ocx, .ps1, .bat, .vbs, .js, .msi, .mst, .msp, .chm, .hta, and .cpl. If any of the executables run within the user profile directory, or operating system temporary folders, application control is ineffective.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

Restrict Microsoft Office macros

Context

All users should be denied the ability to execute Microsoft Office macros by default unless they have a demonstrated business requirement for their use. In such cases, users should still be restricted to using macros in only the specific applications required for their duties. In addition, a record of their business requirement, and associated approvals, should be kept. This record should align with the list of users within the Active Directory group that have permission to run Microsoft Office macros. Note, once a business requirement can no longer be demonstrated by a user, permission to run Microsoft Office macros should be revoked.

Microsoft Defender is commonly used to perform Microsoft Office macro antivirus scanning. This product uses the Antimalware Scan Interface to integrate applications and services with any antimalware software installed on a machine. Other antivirus solutions may use this interface or other processes to scan Microsoft Office macros.

Microsoft Office applications that can execute Microsoft Office macros include Microsoft Access, Microsoft Excel, Microsoft Outlook, Microsoft PowerPoint, Microsoft Project, Microsoft Publisher, Microsoft Visio and Microsoft Word.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

User application hardening

Context

Internet Explorer 11 lacks many of the security features of modern web browsers and ceased to be supported by Microsoft on 15 June 2022. As such, it is more regularly targeted by malicious actors. Therefore, Internet Explorer 11 should be disabled or removed from systems and Microsoft Edge, or another modern web browser, should be used instead.

Malicious actors are known to indiscriminately use ‘malvertising’ in their attempts to compromise systems. Blocking web advertisements using web browser add-ins or extensions, or via web content filtering, can prevent the compromise of a system.

Web browser security settings should be configured via group policy settings. In addition, default web browser security settings should not be relied upon as users may tinker with these settings to enable content or change settings when guided to do so by malicious actors. Web browser security settings that are configured via group policy settings typically appear greyed out to users, have a hover over message explaining the setting is configured by their organisation or have an icon such as a padlock.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

Regular backups

Context

Backups of data, applications and settings should be performed and retained in accordance with business criticality and business continuity requirements for an organisation. In doing so, it is important that restoration of data, applications and settings from backups be tested as part of regular (at least annually) disaster recovery exercises and not left until after the first major security incident is experienced.

At this maturity level, it is important that unprivileged users cannot access the backups of any other users – although it is not necessarily a problem if they are able to access their own backups. It is also worth noting, at this maturity level, that privileged user accounts may still be able to access the backups of any user.

While unprivileged user accounts can access (i.e. read) their own backups, it is important that they do not have the ability to modify or delete those backups. This requirement exists as ransomware running with the privileges of an unprivileged user should be blocked from overwriting or deleting backups. Note, malicious actors escalating privileges to privileged user accounts, or backup administrator accounts, to overwrite backups is addressed at higher maturity levels.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

Maturity Level Two

The focus of this maturity level is malicious actors operating with a modest step-up in capability from the previous maturity level. These malicious actors are willing to invest more time in a target and, perhaps more importantly, in the effectiveness of their tools. For example, these malicious actors will likely employ well-known tradecraft in order to better attempt to bypass controls implemented by a target and evade detection. This includes actively targeting credentials using phishing and employing technical and social engineering techniques to circumvent weaker methods of multi-factor authentication.

Generally, malicious actors are likely to be more selective in their targeting but still somewhat conservative in the time, money and effort they may invest in a target. Malicious actors will likely invest time to ensure their phishing is effective and employ common social engineering techniques to trick users into weakening the security of a system and launch malicious applications. If user accounts that malicious actors compromise have special privileges they will exploit it, otherwise they will seek user accounts with special privileges. Depending on their intent, malicious actors may also destroy all data (including backups) accessible to a user account with special privileges.

The guidance below outlines the requirements to be assessed in addition to the requirements of the previous maturity level. In doing so, assessments against Maturity Level Two should focus on the delta between Maturity Level One and Maturity Level Two.

Patch applications

Context

At this maturity level, vulnerability scanning and patching requirements for additional applications is introduced.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

Patch operating systems

Context

At this maturity level, no assessment is required as the controls are the same as those for Maturity Level One.

Multi-factor authentication

Context

At this maturity level, a requirement for users logging onto systems (e.g. their workstations) to use multi-factor authentication is introduced. Furthermore, all multi-factor authentication, with the exception of customers authenticating to online customer services, should be phishing-resistant.

At this maturity level, event logs for multi-factor authentication events should be centrally collected and analysed as often the lack of sufficient logging can impact the ability of an organisation to identify or determine the extent of a cyber security incident, how it occurred and what vulnerabilities need to be mitigated.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

Restrict administrative privileges

Context

To avoid users collecting privileges and access as they change roles throughout an organisation, and to enforce the principle of least-privileged role-based access control, privileged users should be required to regularly revalidate their requirement for privileged access. As such, privileged user accounts that have not been used within 45 days can indicate that they are no longer required. Rather than user accounts remaining active, and a possible target for malicious actors to exploit, inactive user accounts should be disabled.

For this maturity level, privileged operating environments should not be virtualised within unprivileged operating environments. This constraint allows for three implementation scenarios:

• physically separate operating environments
• an unprivileged operating environment virtualised within a privileged operating environment
• both a privileged and unprivileged operating environment virtualised within a physical host’s hardened operating environment.

Jump servers play an important role as a centralised logging and tool enforcement point for administrative activities, even when privileged operating environments are used.

The use of a common local administrator password for every workstation and server is a common approach in poorly-secured networks due to its ease of use. A marginally more secure approach is using passwords that are a combination of a static component and a dynamic component (e.g. incorporating a unique asset identifier). While the latter may appear to be secure, if malicious actors are able to compromise one or more local administrator passwords they may be able to discern a pattern (e.g. if machine names are the same as their asset identifier). Ideally, an approach that ensures break glass accounts, local administrator accounts and service accounts are unique, unpredictable and managed should be used. For example, Microsoft’s Local Administrator Password Solution.

At this maturity level, event logs relating to the use of, and changes to, privileged user accounts should be centrally collected and analysed as often the lack of sufficient logging can impact the ability of an organisation to identify or determine the extent of a cyber security incident, how it occurred and what vulnerabilities need to be mitigated.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

Application control

Context

At this maturity level, a requirement is introduced relating to the use of application control for internet-facing servers. In addition, any path-based implementations should provide coverage for all locations on disk and Microsoft’s recommended application blocklist should be implemented to mitigate malicious actors using living off the land techniques.

Furthermore, when implementing an application control solution, the application control ruleset may, over time, become unfit for purpose if it is not regular reviewed and validated for its correctness and ongoing suitability. The failure to regularly review application control results can lead to several scenarios, such as exploitable applications or drivers remaining approved for a system, vendor code-signing certificates that have compromised remaining authorised, or system administrators introducing exceptions to ‘get things working’ or troubleshoot but failing to remove the workarounds afterwards. Each of these scenarios are real, have been observed during assessments and introduce additional vulnerabilities for a system that may be exploited by malicious actors.

The majority of application control solutions will have a form of logging. As such, event logs for application control solutions should be centrally collected and analysed as often the lack of sufficient logging can impact the ability of an organisation to identify or determine the extent of a cyber security incident, how it occurred and what vulnerabilities need to be mitigated.

Assessment Guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

Restrict Microsoft Office macros

Context

At this maturity level, a requirement is introduced relating to the use of the attack surface reduction (ASR) rule ‘Block Win32 API calls from Office macros’. This ASR rule prevents Microsoft Office macros from calling Win32 APIs, which malicious actors can exploit to run malicious code that is more powerful than the actions they can perform using the Microsoft Office VBA macro language itself.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

User application hardening

Context

This maturity level requires the implementation of several ASR rules to prevent malicious actors from using Microsoft Office applications to create child processes that can be used to download and run malicious code, write malicious code to disk or inject malicious code into other processes. In addition, the ASR rule ‘Block Adobe Reader from creating child processes’ should be implemented to prevent malicious actors from using Adobe Reader to create child processes which can be used to download and run malicious code.

Malicious actors often attempt to exploit vulnerabilities in Microsoft Office through its support for Object Linking and Embedding packages. This maturity level requires Microsoft Office to be configured to prevent activation of these packages.

The implementation of ASD and vendor hardening guidance can assist in reducing the attack surface of applications. This is particularly important for applications that are commonly targeted by malicious actors such as web browsers, office productivity suites and PDF software. In cases where ASD hardening guidance and vendor hardening guidance conflict, the most restrictive guidance should take precedence.

At this maturity level, event logs for PowerShell should be centrally collected and analysed as often the lack of sufficient logging can impact the ability of an organisation to identify or determine the extent of a cyber security incident, how it occurred and what vulnerabilities need to be mitigated.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

Regular backups

Context

At this maturity level, privileged user accounts (with the exception of backup administrator accounts) are limited to only accessing their own backups, and should not be able to modify and delete backups.

It is important that backup administrator accounts (as well as user accounts in general) are provisioned following the principles of least privilege and separation of duties. As such, backup administrator accounts should only be given to a small group of trusted administrators and a separate group should be setup for the purpose of restoring backups. Excessive permissions for user accounts increases the chance that they will be compromised. Should this occur for these user accounts, malicious actors performing ransomware attacks can easily encrypt or delete all backups.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

Maturity Level Three

The focus of this maturity level is malicious actors who are more adaptive and much less reliant on public tools and techniques. These malicious actors are able to exploit the opportunities provided by weaknesses in their target’s cyber security posture, such as the existence of older software or inadequate logging and monitoring. Malicious actors do this to not only extend their access once initial access has been gained to a target, but to evade detection and solidify their presence. Malicious actors make swift use of exploits when they become publicly available as well as other tradecraft that can improve their chance of success.

Generally, malicious actors may be more focused on particular targets and, more importantly, are willing and able to invest some effort into circumventing the idiosyncrasies and particular policy and technical controls implemented by their targets. For example, this includes socially engineering a user to not only open a malicious document but also to unknowingly assist in bypassing controls. This can also include circumventing stronger multi-factor authentication by stealing authentication token values to impersonate a user. Once a foothold is gained on a system, malicious actors will seek to gain privileged credentials or password hashes, pivot to other parts of a network, and cover their tracks. Depending on their intent, malicious actors may also destroy all data (including backups).

The guidance below outlines the requirements to be assessed in addition to the requirements of the previous maturity level. In doing so, assessments against Maturity Level Three should focus on the delta between Maturity Level Two and Maturity Level Three.

Patch applications

Context

At this maturity level, patches, updates or other vendor mitigations should be applied within 48 hours for office productivity suites, web browsers and their extensions, email clients, PDF software, and security products when vulnerabilities are assessed as critical by vendors or when working exploits exist. In addition, all applications that are no longer supported by vendors should be removed from systems.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting an assessment method, the quality of the evidence provided by each method should be strongly considered.

Patch operating systems

Context

At this maturity level, patches, updates or other vendor mitigations should be applied within 48 hours for operating systems of workstations, servers and network devices when vulnerabilities are assessed as critical by vendors or when working exploits exist. In addition, vulnerabilities in drivers and firmware should be mitigated at this maturity level.

Modern operating systems for workstations, servers and network devices often contain security functionality that is not available in earlier releases, even if those earlier releases remain supported by vendors. It is important that an organisation takes advantage of new security functionality in later releases of operating systems to further mitigate malicious actors’ activities.

The latest release of Microsoft Windows and Microsoft Server will depend on the servicing branch being used. Further release information is available from Microsoft. Similar information is often available from vendors of other operating systems and network devices.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

Multi-factor authentication

Context

At this maturity level, users of data repositories should be using phishing-resistant multi-factor authentication. In addition, customers of online customer services should be using phishing-resistant multi-factor authentication, rather than just being offered it as an option.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

Restrict administrative privileges

Context

Personnel seeking access to systems, applications and data repositories, especially with privileged access, should have a genuine business requirement to do so. Once a requirement to access a system, application or data repository is established, users should be provided with only the privileges they require to undertake their duties. This can be achieved using role-based access controls.

While lower maturity levels required the use of privileged operating environments for administrative activities, they did not require Secure Admin Workstations (SAWs) to be implemented for such environments. However, at this maturity level, a concerted effort should be made to apply the principles associated with SAWs to such environments to ensure that their attack surface is reduced as much as possible. This includes hardening operating systems, including removing all unnecessary functionality. Note, this does not necessarily require separate physical machines to be used for privileged operating environments.

Just-in-time (JIT) privileged access management (PAM) is an extension of role-based access control in which privileged users are only granted the access required to perform their duties immediately before that access is required and for only as long as it is required.

Within an active user session, credentials are cached within the Local Security Authority System Service process to allow for access to network resources without users having to repeatedly enter their credentials. Local Security Authority protection functionality and Credential Guard are designed to assist in protecting this process. Remote Credential Guard provides a similar functionality for remote access. In addition, memory integrity helps protect the overall integrity of systems.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

Application control

Context

At this maturity level, a requirement is introduced relating to the use of application control for non-internet-facing servers. In addition, the scope of application control implementations is expanded to include drivers. Note, while Microsoft AppLocker does not currently support the control of drivers, Windows Defender Application Control does. However, Microsoft AppLocker can be used if Microsoft’s vulnerable driver blocklist is also enforced via Microsoft Window’s memory integrity functionality, assuming an organisation is willing to accept the risk of all other drivers being able to execute.

Microsoft maintains a list of vulnerable drivers that have been discovered by security researchers. Implementing Microsoft’s vulnerable driver blocklist can help to provide protection from malicious actors that would have sought to use these against an otherwise robust application control implementation in order to gain access to a system.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

Restrict Microsoft Office macros

Context

Disabling the use of Microsoft Office macros represents an optimal security outcome, however, some users will have a demonstrated business requirement for their use. In such situations, additional controls should be implemented to make the use of Microsoft Office macros as secure as possible. This may include either running Microsoft Office macros from within a sandboxed environment, from an appropriately controlled Trusted Location or ensuring they are digitally signed by a trusted publisher using V3 signatures.

As Microsoft Office allows any files that are opened from a Trusted Location to bypass security checks, it is critical that only trusted users can write to or modify content in these locations. Under no circumstances should Trusted Locations be specified within a user’s profile, such as their desktop or documents folders.

If the ‘Disable all macros except digitally signed macros’ setting is used, this will allow any Microsoft Office macro signed by a trusted publisher to execute without prompting the user for permission. However, any Microsoft Office macro that is digitally signed by an untrusted publisher will ask users to decide whether they would like to allow the Microsoft Office macro to execute via the Message Bar or Backstage View. While this prompt can be disabled using a group policy setting, the removal of the option to enable Microsoft Office macros via the Backstage View requires the implementation of an undocumented graphical user interface setting.

When implementing a digitally signed Microsoft Office macro approach, an organisation may identify a list of trusted publishers but fail to review and validate the list on a regular basis for its correctness and ongoing suitability. This can create issues when a vendor’s code-signing certificate is compromised. Ideally, an organisation should acquire their own code-signing certificate and re-sign any Microsoft Office macros they trust using V3 signatures, even if already signed by a third party. While introducing additional overhead, this mitigates the risk of potentially trusting compromised third-party code-signing certificates.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

User application hardening

Context

.NET Framework 3.5 (including .NET 2.0 and 3.0) is often targeted by malicious actors due to its lack of security functionality when compared to newer versions of the .NET Framework. Within Microsoft Windows, there are two separate features relating to the .NET Framework, ‘.NET Framework 3.5 (includes .NET 2.0 and .NET 3.0)’ and ‘.NET Framework 4.8 Advanced Services’.

Microsoft ended support for Windows PowerShell 2.0 in late 2017. At that time, Microsoft noted that Windows PowerShell 2.0 lacked the security functionality of Windows PowerShell 5.0 and higher.

Constrained Language Mode for PowerShell is designed to prevent PowerShell users (which may include malicious actors) from running tools that exploit PowerShell or load Component Object Model objects, libraries and classes into a PowerShell session.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

Regular backups

Context

At this maturity level, only a subset of privileged user accounts (i.e. backup administrator accounts) should be able to access backups. The increasing level of control over which user accounts can access backups, and to what extent, progressively limits the damage that may be caused by a ransomware attack.

In addition, at this maturity level, all user accounts (except for break glass accounts) should not be able to modify and delete backups.

Assessment guidance

The section below provides guidance tailored to the assessment method. When selecting a method, the quality of the evidence provided by each method should be strongly considered.

Stage 4: Development of the security assessment report

In developing the security assessment report, assessors should use the Essential Eight Assessment Report Template. However, assessors can use their own report templates for branding purposes if all sections from the template are included.

Further information

The Information Security Manual is a cyber security framework that organisations can apply to protect their systems and data from cyber threats. The advice in the Strategies to Mitigate Cyber Security Incidents, along with its Essential Eight, complements this framework.

A mapping between the requirements of the Essential Eight Maturity Model and the Information Security Manual can be found in the Essential Eight Maturity Model and ISM Mapping publication.

Contact details

If you have any questions regarding this guidance you can write to us or call us on 1300 CYBER1 (1300 292 371).