As of July 12, 2021, the new Essential Eight maturity model became available and inspired me to write a new series of articles regarding these valuable controls. Anyone familiar with the original Essential Eight controls will quickly realise that the new maturity model is a beast but fills a lot of gaps and provides a great roadmap to strive for in enhancing your security maturity.
Please take some time to read all of my articles on the updated Essential Eight Maturity Model; the links are at the bottom of this article.
We kicked off this series with an introductory blog you can find here, so now let’s dive in to the first control, which is Application Control.
Long referred to as “Application Whitelisting”, Application Control addresses a more thorough way to control access to and execution of applications. What is an application? In the old days, we just called them programs but at the core of everything you do on a computer is a set of programs that perform required and desired actions.
Think people, process, environment, technology.
Controlling who can access, install, and modify these programs (people), how controls are implemented, maintained, and modified (process), where programs can execute and when (environment), and the controls themselves and how they are implemented (technology) is the core of Application Control.
Where should you start? An inventory of what applications you have and their dependencies, who uses these applications, and the process for onboarding and offboarding people and applications is a crucial starting point. Then you should move towards determining the who, what, when, where, why, and how of each to ensure people can do what they should, and not what they shouldn’t. Believe me, it’s more complex than that. WAY more complex, but here’s the take-away: Control.
Let’s just skip Level 0 altogether as that assumes you have not implemented any controls towards Application Control. I find this is rarely the case; often we are using other means, even just Active Directory Group Policy Objects (GPOs) to control some level of access to and execution of applications. Do you let your regular users access administrator controls and tools? I didn’t think so.
“The execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets is prevented on workstations from within standard user profiles and temporary folders used by the operating system, web browsers and email clients.”
Where previously the focus was on two controls with one each for servers and workstations, the emphasis is now on workstations, since end users are often the cause of application-driven incidents. The range of elements increased to include web-driven applications and Operating System (OS) dependencies. This also makes Maturity Level One achievable as I find many organisations control their workstations but struggle to apply the same level of control over servers out of fear of “breaking” functionality.
You can quickly see how the higher levels of maturity build in the current Essential Eight Maturity Model by building on established controls and adding complementary controls to build a cohesive defence posture. This is likely why the ACSC recommends achieving a specific level (like starting with one) across all eight strategies before advancing to the next levels and controls.
“The execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets is prevented on workstations from within standard user profiles and temporary folders used by the operating system, web browsers and email clients.”
(As above, ML1) Where previously the focus was on two controls with one each for servers and workstations, the emphasis is now on workstations, since end users are often the cause of application-driven incidents. The range of elements increased to include web-driven applications and Operating System (OS) dependencies. This also makes Maturity Level One achievable as I find many organisations control their workstations but struggle to apply the same level of control over servers out of fear of “breaking” functionality.
“Application control is implemented on workstations and internet-facing servers to restrict the execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organisation-approved set.”
Building on Maturity Level one, we now introduce internet-facing servers which are also part of the attack surface of an organisation. Lessons learned by defining approved sets of applications will translate well as you should understand the process by this point.
“Allowed and blocked executions on workstations and internet-facing servers are logged.”
I cannot emphasise enough how critical system monitoring is. I also realise that managing this wealth of information obtained from logging is a challenge in itself. You can explore implementing a Security Information and Events Management (SIEM) solution or better still, why not seriously consider a managed security service.
“The execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets is prevented on workstations from within standard user profiles and temporary folders used by the operating system, web browsers and email clients.”
(As above, ML1) Where previously the focus was on two controls with one each for servers and workstations, the emphasis is now on workstations, since end users are often the cause of application-driven incidents. The range of elements increased to include web-driven applications and Operating System (OS) dependencies. This also makes Maturity Level One achievable as I find many organisations control their workstations but struggle to apply the same level of control over servers out of fear of “breaking” functionality.
“Application control is implemented on workstations and internet-facing servers to restrict the execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organisation-approved set.”
(As above, ML2) Building on Maturity Level one, we now introduce internet-facing servers which are also part of the attack surface of an organisation. Lessons learned by defining approved sets of applications will translate well as you should understand the process by this point.
“Allowed and blocked executions on workstations and internet-facing servers are logged.”
(As above, ML2) I cannot emphasise enough how critical system monitoring is. I also realise that managing this wealth of information obtained from logging is a challenge in itself. You can explore implementing a Security Information and Events Management (SIEM) solution or better still, why not seriously consider a managed security service.
“Application control is implemented on workstations and servers to restrict the execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications, control panel applets and drivers to an organisation-approved set.”
At this point, you should have a grip on workstations and internet-facing servers, so now we apply the same application control approach to the rest of your servers. Of course, this is not a one-size-fits-all and never should be, so you’d have profiles for each server type. One for Domain Controllers, one for Database Servers, one for Print Servers, one for File Servers, and so on. Just bear in mind for each that you must control who and what above all: “who” can access, install, modify, and execute (plus the process for moves, adds, and changes of personnel) and “what” can be installed, modified, executed as well as onboarded and offboarded (like decommissioning and upgrading applications) into and out of your infrastructure.
“Microsoft’s ‘recommended block rules’ are implemented.”
At one point, the next control was buried within this one, but by breaking them into two separate controls, implementation is more achievable. The main objection I hear is that the block rules, when implemented in their entirety, break applications. For this, I say use your judgement because the block rules are not all-or-nothing; implement the ones that will work, and don’t implement the ones that don’t work or risk breaking applications.
That said, make sure that if you carry risk associated with block rules you cannot implement, you have mitigating or isolation strategies as an alternative. Cybercriminals don’t follow rules, so I can imagine their reaction when you say, “please don’t attack this application because I can’t use the Microsoft Block Rules”. Right-o, sunshine!
“Microsoft’s ‘recommended driver block rules’ are implemented.”
Complementary to the above control, drivers for applications and hardware (physical and virtual) should be controlled. Attack vectors still include exploiting the core connectivity of programs with the systems upon which they run, and remote access controllers are just one thing smack-bang in the middle of this. Why attack an application on a server when I could just attack a vulnerable driver on the server itself to gain control of the whole thing? Cybercriminals can share characteristics of incredibly skilled criminal defence lawyers — if there is a loophole, we’ll find it and we will exploit it for gain.
“Application control rulesets are validated on an annual or more frequent basis.”
The world is constantly changing and attacks and exploits currently underway often didn’t exist a year ago, so constant review of the rules and controls should be mandatory. Many businesses may review their policies on an annual basis, so Application Control (and other in-scope security elements) should be formally reviewed as well. If you’re not sure where to start or why, just ask your friendly neighbourhood cybersecurity consultant. I can help set you up with a few!
“Allowed and blocked executions on workstations and servers are centrally logged and protected from unauthorised modification and deletion, monitored for signs of compromise, and actioned when cybersecurity events are detected.”
I will repeat that system monitoring is crucial, and the more specific and cybersecurity-centric data you can log, the better. I understand that cyber activity is an intimidating task, but help is available.
Application Control can be frightening, and I hear it referred to as “Black Magic”, “Dark Arts”, and “Voodoo”, but at its core is controlling the applications that execute, and who can execute them. Review the people, processes, environments, and technology in place and always ask yourself about:
Who? – the people that may or may not access and execute applications.
What? – the applications themselves and their purpose.
Why? – the reason for access to and execution of applications.
When? – are there specific times and dates to use this application.
Where? – is the application accessible internally only, remotely, from specific geolocations, etc.
And finally,
How? – control the means to onboard and offboard people and applications, the controls needed, and the pathways to link the two.
That’s all for Application Control for now, in the next blog we’ll explore Application Patching.
If you have any questions, or would like support enacting an Essential Eight strategy, reach out to my colleagues and I anytime or see our Essential Eight Solutions to learn more. Stay safe out there.
Using the ACSC recommendations as a framework, Data#3 has built an Essential Eight Assessment to help organisations understand and improve their security posture.
The Essential Eight Assessment is a 5-day engagement, conducted by a Data#3 Information Assurance Specialist, including up to 2 days spent onsite with the customer.
This is blog 2 of a 9-part series. See earlier posts on:
1. Your guide to the ACSC’s Essential Eight Maturity Model
2. You are here.
3. Essential Eight Maturity Model: Patch Applications
4. Essential Eight Maturity Model: Configure Microsoft Office Macro Settings
5. Essential Eight Maturity Model: User Application Hardening
6. Essential Eight Maturity Model: Restrict Administrative Privileges
7. Essential Eight Maturity Model: Patch Operating Systems
8. Essential Eight Maturity Model: Multi-Factor Authentication
9. Essential Eight Maturity Model: Regular Backups
