Australian businesses often meet the Essential Eight the way they meet most of security, one product at a time. A tool for application control, another for patching, something else again for administrative privileges, each with its own console, its own licence, and its own renewal date. The list gets covered, and the stack gets a little heavier each year.
So how many tools does the endpoint side of the Essential Eight need?
The Essential Eight is the Australian Signals Directorate's (ASD's) set of eight baseline mitigation strategies, graded from Maturity Level One to Three. Much of the time pressure sits in patching. From Maturity Level One, patches for online services are expected within 48 hours of release when a vulnerability is critical or a working exploit exists, and patches for browsers, office suites, email clients, and PDF software within two weeks (ASD Essential Eight Maturity Model, November 2023).
Two weeks sounds reasonable until you count. A business with a few hundred staff runs those applications on every laptop, each on its own release schedule, and from Maturity Level Two the long tail of other third-party applications goes on a one-month clock as well.
Three different jobs on one endpoint
It helps to separate the jobs before choosing any tools, because they often get treated as one problem. Prevention decides what is allowed to run. Detection and response watches what did run and acts on it. Hygiene closes the doors before anyone tries them, which is patching and vulnerability management. Device management, the tooling that deploys and manages software, is a separate job again, outside those three. When a client describes all of this as a single need, what they need is often three different things.
Four of the eight controls sit in two of those layers. Application control and restricting administrative privileges belong to prevention: deciding what may run at all, and removing standing admin rights so elevation is approved when it is needed. Patching applications and patching operating systems belong to hygiene. So for those four controls, the answer is usually two layers, each run well, in place of four separate products.
I tend to think of vulnerability management and application control as working hand in hand. Patching shrinks what can be exploited, and application control limits what can run if something is missed or cannot be patched yet. Detection and response is not one of the eight, and it carries its own case, which I've written up in who's watching your endpoints at 2am.
Where the maturity levels land
Maturity Level One is achievable for most businesses and worth doing. Level Three, with its demands on driver control and hardening, is hard work and rarely reached in Australia outside organisations that are required to get there. Fewer tools leave those Level Three demands as they are. They do lower the effort each level takes, because the four controls are run as one routine in place of four.
When we first ran patching and application control side by side in our own environment, one of our first questions was whether a new patch would be blocked and the two systems would end up fighting each other. Most of the time that does not happen, because the application control catalogue recognises new releases of known software.
Automation helps a great deal here, though you can't automate it all the way. A good setup heavily streamlines the work, tells an administrator clearly why a patch failed, and keeps running when the person who built it moves on.
See it in your own environment
You can see where you stand before anything changes. Application control can run in learning mode on a small group of machines and show what is executing today, and a vulnerability scan can map your current exposure against the two patching controls. Read together, those two views show which of the four controls is weakest, which is usually the right place to start.
For the prevention side in more depth, see why default-allow leaves you open.