Essential Eight uplift to ML1, ML2 or ML3
There are eight mitigation strategies and three maturity levels, and a client’s level is set by its weakest strategy. We implement the controls that take the client to the level you’ve chosen, test them on a pilot group first, and leave evidence that each one works.
Seven strategies at ML2 or better, backups at ML1. Until backups catch up, the client hasn’t reached ML2.
Choosing the target level
Each maturity level is written for a different kind of attacker, and each one includes everything in the level below. ASD’s guidance is to reach a level across all eight strategies before reaching for the next, so the target is a business decision about who the client needs to stop. Choose a level to see what it asks of each strategy.
ML1 is aimed at attackers using commodity tools and public exploits, looking for any victim with a weakness rather than this one in particular.
ML2 is aimed at attackers willing to spend more time on a target and on tools that work: targeted phishing, stolen credentials, and ways around weak MFA.
ML3 is aimed at adaptive attackers who rely less on public tools, move quickly on a new weakness and look for gaps like old software or thin logging.
Stop malicious code arriving and running
-
Application control
ML1On workstations, only an approved set of executables, scripts, installers and libraries can run from user profiles and temporary folders, the places users can write to.
ML2Extends to internet-facing servers and to every other location on the disk. Microsoft’s recommended application blocklist goes in, the rules are revalidated at least yearly, and allowed and blocked executions are logged centrally.
ML3Extends to the remaining servers, and drivers are restricted to an approved set with Microsoft’s vulnerable driver blocklist in place.
-
Patch applications
ML1Online services, browsers, Office, email clients, PDF software and security products are patched within ASD’s timeframes, faster for online services when an exploit exists. Automated asset discovery and a vulnerability scanner find what’s missing, and versions the vendor no longer supports are removed.
ML2The same scanning and patching discipline reaches every other application on the fleet.
ML3Critical fixes for Office, browsers, email clients, PDF software and security products move to the faster timeframe, and any application its vendor no longer supports is removed, not just the common ones.
-
Microsoft Office macro settings
ML1Macros are off for anyone without a demonstrated business need, macros in files from the internet are blocked, macros are scanned by antivirus, and users can’t change the settings.
ML2Macros are blocked from making Win32 API calls, and allowed and blocked macro runs are logged.
ML3Only macros that run in a sandbox, from a Trusted Location, or signed by a trusted publisher can run, and they’re checked for malicious code before they’re signed or placed there.
-
User application hardening
ML1Browsers don’t run Java or web ads from the internet, Internet Explorer 11 is disabled or removed, and users can’t change browser security settings.
ML2Office and PDF software can’t launch child processes, Office can’t create executable content or inject code, vendor hardening guidance is applied, and PowerShell activity is logged.
ML3.NET Framework 3.5 and Windows PowerShell 2.0 are disabled or removed, and PowerShell runs in Constrained Language Mode.
Limit how far an incident spreads
-
Restrict administrative privileges
ML1Privileged access is approved when requested. Admins use separate privileged accounts and environments, and those accounts can’t browse the web or read email.
ML2Privileged access expires unless it’s revalidated or used, admin work goes through jump servers, local admin, break-glass and service account passwords are unique and managed, and privileged activity is logged.
ML3Admin rights are granted just in time and limited to each person’s duties, admin work happens from secure admin workstations, and Windows protections such as Credential Guard and LSA protection are switched on.
-
Patch operating systems
ML1Internet-facing servers and network devices are patched quickly, workstations and internal servers on a longer clock, missing patches are found by scanning, and unsupported operating systems are replaced.
ML2Little changes for operating systems. Critical fixes for internet-facing servers and network devices move to the fast timeframe whether or not an exploit has been seen, and the ML1 scanning and timeframes have to hold everywhere.
ML3Critical fixes for workstations and internal servers move to the same fast timeframe as internet-facing ones, drivers and firmware are scanned and patched too, and only the latest or previous operating system release is in use.
-
Multi-factor authentication
ML1MFA protects the client’s online services and third-party services that hold its sensitive data, and the services it offers customers.
ML2MFA covers everyone signing in to the client’s systems, privileged or not. For staff it has to be phishing-resistant, customers get a phishing-resistant option, and MFA events are logged.
ML3MFA reaches data repositories, and phishing resistance becomes mandatory for customers and repositories too.
Recover when something gets through
-
Regular backups
ML1Data, applications and settings are backed up to a common point in time, kept to suit how critical they are, and restores are tested. Ordinary user accounts can’t reach other people’s backups or change or delete any.
ML2Admin accounts, other than backup admins, lose the same access.
ML3Even backup admins can’t change or delete a backup during its retention period, and accounts can’t reach their own backups.
Each line above sits on top of everything in the levels below it.
Where uplifts stall
The settings are documented. Uplifts get stuck on the parts that change how people work, and on controls that look done but wouldn’t stand up to a test.
-
Application control
Audit mode that never ends
Policies go out in audit mode, the event log fills with noise, and nobody is confident enough to turn on enforcement. We work through the audit data, build rules on publishers and paths rather than one-off file hashes where we can, and enforce on the pilot group first.
-
Restrict administrative privileges
Your own tools are in scope
Separate admin accounts, no web or email on privileged accounts, and application control all apply to the people and tools managing the client: your technicians, your RMM and remote access agents, the scripts you deploy. We plan those changes with you so your team isn’t locked out on the day.
-
Patching
A patch dashboard isn’t a scan
A patch tool reports on what it was asked to patch. The maturity model expects automated asset discovery, a vulnerability scanner to find what is missing, and unsupported software removed, including applications the patch tool doesn’t manage.
-
Microsoft Office macro settings
One team’s exception applied to everyone
One team needs macros, so macros get turned back on for everyone. The model allows macros where there’s a demonstrated business need, so we narrow the exception to the people who need it and, at ML3, to signed macros, Trusted Locations or a sandbox.
-
Multi-factor authentication
MFA that a phishing page can relay
Codes and push approvals can be passed through by an adversary-in-the-middle page. From ML2 the methods have to resist phishing, which usually means security keys, smart cards, Windows Hello for Business or device-bound passkeys, and a plan for the people and accounts that can’t use them yet.
-
Regular backups
Backups the attacker can delete
The backup exists, but the account ransomware lands in can reach it. Even ML1 expects ordinary accounts not to change or delete backups, and the higher levels close the same door for admins. A restore test is the only proof the backup is usable.
Pilot first, then everyone
Application control and macro blocking fail without warning: a finance add-in stops loading, a line-of-business app won’t update. A pilot group finds those problems while they’re small.
- Start from an assessmentAn existing one, or our Essential Eight assessment, so the work starts from the gaps the client has.
- Plan each strategy to the targetThe changes needed for every strategy, including the ones that affect your own tools and team.
- PilotChanges go to a pilot group of real users and devices before anyone else.
- Roll outThe rest of the client follows once the pilot is clean.
- Evidence and a new maturity summaryEach control tested and recorded, and the client’s maturity summarised again.
- Requirement
- Macros in files originating from the internet are blocked.
- How it was shown
- A macro-enabled workbook downloaded from the internet was opened as a standard user on a pilot device. Office blocked the macro.
- What’s on file
- A screenshot of the block, the policy setting that enforces it, and the device’s policy status.
What the client ends up with
- Controls at the target levelAll eight strategies implemented to the level you chose, across the client’s devices and services.
- Evidence for each controlA record of each control tested and working, as well as its configuration.
- As-built documentationWhat was changed and where, so your team can run it from the first day.
- An updated maturity summaryWhere the client now sits, strategy by strategy.
Delivered remotely as a white-label project, under your brand or as your named partner. We work in the client’s Microsoft 365, Entra ID and Intune, or through your RMM if you’d rather. We quote and invoice you at a fixed price for the agreed scope, and you keep the client and the ongoing service.
More projects like this in Security & compliance.