Powered by MOMENTUM MEDIA
cyber daily logo
Breaking news and updates daily. Subscribe to our Newsletter

What you need to know about the new ‘Essential 8’ mitigation strategies

Arun Raghu and Eder Plansky, principal security advisors at Trustwave, unpack the new strategy and explain how it will shape cyber security practice into the future.

user iconArun Raghu and Eder Plansky
Thu, 14 Oct 2021
What you need to know about the new ‘Essential 8’ mitigation strategies
expand image

In July 2021, the Australian Cyber Security Centre (ACSC) released an update to its Essential 8 (the E8). Originally published in 2017 as an evolution of the Australian Signals Directorate’s Strategies to Mitigate Cyber Security Incidents, the E8 has been put forward as a baseline set of strategies that are most effective in making it harder for cyber adversaries to compromise an organisation’s systems.

This article looks at some of the factors driving the emergence of the E8 as a bellwether in setting baseline expectations for cyber security practice in Australia and discusses some of the changes introduced by the new version that make the bar it sets for businesses noticeably higher.

The Rise of the Essential 8

============
============

The E8 originally appeared to have been developed to provide guidance on protecting Microsoft Windows-based internet-connected networks. However, many of the E8 controls are able to be applied to non-Microsoft environments, including Unix / Unix-like systems and cloud environments.

Since being introduced a few years ago, the E8 has grown from being primarily adopted as a baseline approach for cyber security across Australian federal government agencies to also being utilised by state governments as well.

The New South Wales government, for example, now requires constituent agencies to submit a maturity assessment each year against the E8, and the Australian Capital Territory’s Auditor General, in producing a 2020 report discussing its review of agencies’ data security controls and procedures, indicated it based its testing criteria in part on the E8.

Trustwave has also observed government agencies listing E8 compliance as a criterion in tender documents, and we expect this will reflect an increase in the use of the E8 as a baseline for cyber security best practices across both the private and public sectors.

This is likely to work hand in hand with the proposed changes foreshadowed in the government’s recent paper covering cyber security-focused regulation to establish a minimum cyber security baseline across the economy, consistent with the 2020 Australian Cyber Security Strategy.

Further, as part of Australia’s International Cyber Engagement Strategy, it is translating the E8 into the official languages of member nations of the Association of Southeast Asian Nations (ASEAN) to promote its adoption in those jurisdictions.

What are the key changes?

The E8 strategies themselves, at a high level, are fundamentally the same. The ACSC indicates that the changes include redefining the E8 maturity levels, moving to a stronger risk-based approach to implementation and applying the mitigation strategies as a package.

Changes to the maturity levels

As with previous iterations, the updated E8 includes maturity levels (MLs), each with its own set of requirements that provide detail around the implementation of the strategies. The ACSC indicates that in selecting an ML, organisations should consider what level of cyber adversary tradecraft and targeting they are looking to mitigate (rather than the type of adversary).

The update includes the re-introduction of a new ML 0, with ML 3 being the highest (adversaries using highly sophisticated and customised tradecraft). ML 1 is indicated to be suitable for most small to medium enterprises, ML 2 for larger enterprises, and ML 3 for critical infrastructure organisations or those who operate in a high threat environment.

This is a significant change – in the past, achieving compliance with the E8 was often connoted with achieving ML 3 compliance. The updates, however, make achieving that a considerably more onerous proposition for many organisations, with ML 3 having moved from 29 to 69 requirements under the new E8.

Our observation is that the requirements for each strategy are considerably more fine-grained than in the past. While this does add some complexity, it also helps to mitigate more sophisticated threats and, in some cases, offers more flexibility to organisations.

Based on our experience in working with clients in regard to the changes in the new E8, we’ve listed what we perceive as some of the most significant (and challenging) changes in the table below:

Topic

Description of change

Separation of privileged and unprivileged operating environments

Separating privileged and unprivileged operating environments, including preventing unprivileged accounts from logging into privileged operating environments and vice versa (for example, using an administrative virtual machine on a standard workstation would not be permissible).

Just-in-time administration

Mandating the use of just-in-time administration for administering systems and applications (although there isn’t much in the way of detail as to how this is to be done) for ML 3. In other words, administrators will not have their privileged account always enabled and will need to check in to obtain privileged access to systems.

Operating systems

Only allowing the use of the latest release, or the immediate previous release, of operating systems for workstations, servers and network devices for ML 3, irrespective of whether an operating system in use is still supported by the manufacturer.

Multi-factor authentication

The need to implement ‘verifier impersonation resistant’ multi-factor authentication for ML 3 (this is likely to exclude the ability to use one-time passwords alone). Introducing this requirement helps mitigate the risk associated with more sophisticated phishing scams involving the interception of OTP codes.

Additionally, users should use multi-factor authentication when accessing their organisation’s internet-facing services (e.g., for remote access) or when accessing third-party internet-facing services (e.g., cloud services) that handle organisation data.

Backups

Requirements for backups are less prescriptive and more business-oriented and have been renamed from ‘daily’ to ‘regular’ backups.

Patching

The focus on patching has shifted from risk severity to whether an exploit exists. For example, all patches for vulnerabilities in internet-facing infrastructure need to be applied within 48 hours (regardless of severity) where an exploit for the relevant vulnerability exists.

This will necessitate more refined threat intelligence capabilities to determine which vulnerabilities have an exploit ‘in the wild’ in order to prioritise remediation. It is likely that the introduction of this requirement was at least partly in response to a sophisticated campaign targeting Australian networks the ACSC identified in June 2020.

The 48-hour timeframe also applies to other applications (e.g., office productivity suites, browsers or email clients) where an exploit exists. The timeframes are more lenient if there is no current exploit.

Vulnerability scanning

The introduction of a requirement to use a vulnerability scanner regularly to identify missing patches in applications and operating systems, including on a daily basis for internet-facing services. Previous versions of the E8 did not cover vulnerability scanning specifically. Frequency of scanning depends on the maturity level being considered.

Further, five of the eight strategies now require the use of centralised logging to record various events to satisfy maturity level 3 (e.g., use of privileged access and blocked application executions). The move to centralised logging, particularly for recording failure-related events, is likely to be a challenging requirement for many organisations to comply with.

Overall, there is no doubt the new requirements are considerably more stringent and will be challenging for organisations to satisfy – particularly for those targeting maturity levels 2 and 3.

Moving to a risk-based approach and implementing the strategies as a package

The ACSC has placed an emphasis on organisations to move towards a risk-based approach to implementing the E8, to account for situations where there may be difficulties in fully implementing specific strategies (for example, where there may be legacy systems in an organisation’s environment which necessitate the use of compensating controls).

Naturally, organisations are encouraged to minimise any exceptions and review them on a regular basis.

In contrast to previous versions of the E8, the ACSC has indicated that organisations should achieve a consistent maturity level across all eight strategies before moving onto a higher maturity level, rather than focus on achieving different maturity levels for different strategies.

The ACSC suggests this approach is warranted due to the Essential 8 strategies being designed to complement each other and to provide broad coverage of various cyber threats. While achieving a common level of maturity makes sense at a theoretical level, it seems to some extent to belie the very notion of a ‘risk-based approach’ that the ACSC has advocated.

We expect that for many organisations it would be more practical and make more sense to prioritise uplifting their maturity in respect of specific E8 strategies in response to their specific threat and risk profile.

Setting a much higher baseline for cyber security in Australia

The new E8 is undoubtedly a significant step up compared to previous iterations and sets a much higher baseline for cyber security practices within the government and business sector in Australia.

This is not only because of the additional detail in the maturity levels but the focus on implementing the strategies as a package. It will be interesting to see how it is received by organisations in the coming months.

We expect that many organisations will consider achieving maturity level 3 impractical and be more likely to aim for either ML 1 or ML 2. E8 compliance has, in the past, been connoted largely with achieving ML 3, so in this respect, there may be some softening of the concept of ‘compliance’ to account for the higher bar that has been established.

In this vein, it will also be interesting to see whether directives from the government onto providers for E8 compliance will be set at the ML3 level or something lower.

newsletter
cyber daily subscribe
Be the first to hear the latest developments in the cyber industry.