ACSC Essential Eight, an Introduction to Application Control

Posted:

07/20/2022

| By: Leon Friend,Principal Sales Engineer, APAC

Within Australia, the Australian Cyber Security Centre (ACSC) Essential Eight is a common discussion that IT solutions providers have with their customers. While it seems straightforward to talk about threat mitigation strategies and how to best protect customer cyber assets, a knowledge gap often can make it a challenging and confusing discussion.

IT solution providers worldwide need to become comfortable with the subject from a cybersecurity perspective and be prepared to communicate its importance to their customers.

Today we will dig into the first component of the ACSC Essential Eight: application control.

Application control, or “application whitelisting,” is a topic most partners and their customers have not even considered, let alone understand. Your challenge here is to help them understand why it is essential and how implementation can help them better protect their cyber assets.

With this in mind, let's walk through what application control is and some of the challenges you might need to overcome whether you’re starting to talk it over with your customers or planning an implementation.

Recap: What is the ACSC Essential Eight?

We covered the broader context of the Essential Eight last time around, but let’s briefly revisit and define the Essential Eight:

The ACSC Essential Eight is a prioritised set of eight “essential” mitigation strategies or controls for building cyber resilience and protecting Australian businesses from cyberattacks.

Whilst the Essential Eight outlines a minimum, or fundamental, set of mitigation measures an organisation needs to implement to defend their environment, additional mitigation strategies and security controls also need to be considered. More information can be found in the ACSC Strategies to Mitigate Cyber Security Incidents framework and the ACSC Information Security Manual (ISM)

The Essential Eight Mitigation Strategies are:

Application Control Explained

Initially introduced as “application whitelisting” and later updated to “application control,” the intent is to provide an approach where only an explicit set of trusted applications are allowed to be installed and executed on a system.

While the reverse process of application blocking (i.e., specifically blocking known undesired applications) can have some early benefits, eventually it can become a game of Whack-a-Mole as there is always something new that the user will desire.

The approach of only allowing approved applications also supports other controls such as “patching applications” and “user application hardening.” Knowing which applications will be installed lets you determine what the application patching policy needs to cover. You can also look at implementing appropriate controls to ensure minimum rights are used to run the applications and that they can only perform necessary actions.

The Customer (or End-User) Challenge

One of the main challenges you will experience with application control is agreeing on the list of applications to be installed and maintained in the end user computing space.

Many customers simply do not have a software asset register. They often allow users to manage their own destinies, including being able to install and use whatever application or browser they desire.

This is often less of a challenge in the server space as servers typically exist to provide specific services and are tightly controlled.

Much of your upfront process here will be educating the decision-makers to help build the necessary intent and desire to standardise the applications in use. You’ll need to help them understand what is required when selecting applications and vendors and offer support as they build a selection/validation process. Additionally, applications should be legitimate, licensed appropriately, and supported by the vendor. Your customers will need help setting up this protocol.

Organisational Impact

When considering application control and your discussion around implementation, consider the risk profiles associated with the maturity level and the organizational impact.

Generally, the upfront costs can be high from a time and effort, staffing, and software perspective. Much of this is due to the initial education, selection process, and the acquisition of appropriate tools where required. Once implemented, ongoing maintenance and user costs are generally rated as medium.

The application landscape is always changing, and users will always request new software. Application control is not a set-and-forget strategy.

Keep in mind, when discussing and implementing application control, initial resistance can be high as business owners and staff like to be able to do whatever they want. And, we are not saying your customer’s colleagues can’t have the applications, just that we want to control the risk by managing them within the organisation.

The Three Maturity Levels

Before implementing the Essential Eight, organisations must determine which level of maturity will work for their environment. As you design your implementation strategy, keep in mind that you’ll need to ramp up each of the “Eight” before progressing to subsequent maturity levels. The strategies below are taken directly from Essential Eight Maturity Model.

Please ensure you are referring to the complete original documentation from the ACSC when you are building out your application control strategy – they are extremely helpful in providing a framework for implementation.

Level 1 Maturity

Strategy:

The executing 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.

Risk Profile:

Adversaries are generally content to leverage commodity-driven tradecraft and are typically looking for any victim in an opportunistic manner rather than investing resources to target a specific victim.

Level 2 Maturity

Strategy:

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. Allowed and blocked executions on workstations and internet-facing servers are logged.

Risk Profile:

Adversaries are operating with a modest step up in capabilities by investing effort in profiling victims and investing in more effective tools.

ISM Mappings:

ISM-0843: Application control is implemented on workstations.

ISM-1490: Application control is implemented on internet-facing servers.

ISM-1657: Application control restricts the execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications, and control panel applets to an organisation-approved set.

ISM-1660: Allowed and blocked executions on workstations are logged.

ISM-1661: Allowed and blocked executions on internet-facing servers are logged.

Level 3 Maturity

Strategy:

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. Microsoft’s ‘recommended block rules’ are implemented.

Microsoft’s ‘recommended driver block rules’ are implemented.

Application control rulesets are validated on an annual or more frequent basis. 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.

Risk Profile:

Adversaries are more adaptive and much less reliant on public tools. They will be more focused on specific targets, learning about their policies and technical tools to gain access to the environment.

ISM Mappings:

ISM-0843: Application control is implemented on workstations

ISM-1490: Application control is implemented on internet-facing servers

ISM-1656: Application control is implemented on non-internet-facing servers.

ISM-1658: Application control restricts the execution of drivers to an organisation-approved set.

ISM-1544: Microsoft’s “recommended block rules” are implemented.

ISM-1659: Microsoft’s “recommended driver block rules” are implemented.

ISM-1582: Application control rulesets are validated on an annual or more frequent basis.

ISM-1660: Allowed and blocked executions on workstations are logged.

ISM-1661: Allowed and blocked executions on internet-facing servers are logged

ISM-1662: Allowed and blocked executions on non-internet facing servers are logged

ISM-1663: Application control event logs are centrally stored and protected from unauthorised modification and deletion, monitored for signs of compromise, and actioned when cybersecurity events are detected.

Conclusion

When it comes to hardening the endpoint and reducing the attack surface, implementing a solid application control policy is a practical first step of the ACSC eight-part mitigation strategy. Its importance is featured in the ACSC Strategies to Mitigate Cyber Security Incidents Framework, where it falls under “Mitigation Strategies to Prevent Malware Delivery and Execution,” has an “essential” effectiveness rating (hence it is included in the Essential Eight), and is included in all four implementation strategies.

By understanding the benefits of application whitelisting, or application control, you will be empowered to meet your customer’s specific concerns and unique challenges. Application control is not just a technical tool; it is also about people and processes. Educate your customer and take them on the cybersecurity journey, and we can all be better protected.