News Own Your Online External Link Report it
News Own Your Online External Link
  1. Welcome to the National Cyber Security Centre
  2. Protect your organisation
  3. Critical Controls
  4. Application control

Application control

Application control is a set of security practices and controls designed to manage and restrict programs that run in your environment. Allowlisting is a part of that but focuses just on allowing specific, approved applications. It works by blocking everything by default and only letting through what’s been approved.

Application control is one of the most effective ways to protect your organisation from cyber threats like malware and ransomware.

What is application control and allowlisting?

Application control

Application control allows organisations to restrict specific software packages from running on their systems, including limiting the types of files that can be downloaded, open, or run.

Application control has evolved over time and is now a feature found in most modern operating systems and endpoint security software that can help to avoid having to manually configure policies and rules. Endpoint security software also includes regular updates from the vendor to detect and block the latest malware behaviours so it can be a good option to achieve protection.

Additionally, organisations can use application configurations and policies to restrict the downloading of certain file types or extension types that are commonly used in cyber attacks.

Application allowlisting

In simple terms, application allowlisting is about creating a “safe list” of programs that are allowed to run on your computers. If something’s not on the list, it won’t run. This makes it much harder for malicious actors or malicious software to sneak in and do damage.

It’s designed to:

  • block unwanted or harmful applications from being installed or run,
  • stop malware from spreading through your systems, and
  • help spot attempts by attackers to run malicious code.

To be effective, application control and allowlisting should be implemented with other security controls. It should not replace antivirus or other security software already on the system.

How to set up application control

For application control to be effective, it must be implemented in tandem with other controls. For example, if an application has a vulnerability and it’s allowlisted then it’s an easy path for an attacker.

Application control can be implemented in several ways. It largely depends on what resources your organisation has available and how ready the organisation is for change. 

Modern endpoint protection software 

For a lower effort option your organisation could use endpoint protection and response (EDR) tools, which can detect and block malicious activity on systems. If well-maintained and kept up to date, these tools can be effective at preventing malware infections and limiting the activities that an attacker would be able to carry out. While this may not offer quite the same level of protection as full application control and allowlisting, it can still achieve significant protection.

Full application control

If you're after a robust solution, there are six steps to follow.

Step 1: Decide what’s allowed to run on your chosen systems

Start by deciding which apps and files your organisation needs. Focus on high-risk devices first like laptops and desktops that access the internet, or servers that run your email and web services.

Think about the:

  • people responsible for implementing and managing the solution,
  • software that can be used to manage and distribute policies, and
  • time and money needed to conduct a thorough implementation plan.

Get a clear picture of what’s normal in your environment before creating your allowlist.

Step 2: Set up rules and policies for different user groups and devices

Most application control tools have two modes.

  • Audit mode: This watches what’s running and builds a list of trusted apps without blocking anything.
  • Enforce mode: This blocks anything that’s not on the list.

To start off with, it’s a good idea to start in an audit (or learning) mode, then move to enforce mode once you're confident.

Manual policies can also be created if there are specific rules you want to set based on how your environment is used or based on indicators of compromise in an incident. 

You can create rules based on:

  • hash: this is the cryptographic hash value of the file. This is the strongest rule condition you can use because it uses the file attributes (ex: file content, name, and size) to generate a unique one-way hash value. If any of these attributes were changed the hash value would change. A current hashing algorithm family should be used, such as SHA-2, as these algorithms do not have any known or possible collision techniques.
  • file attributes: a combination of file attributes can be used to create a rule and is reliant on strong file permissions. This includes combining file path, file name, file size, and file type.
  • signature or publisher: the creator can sign their file digitally using their private key. You can verify the identity of the file publisher by checking their public key. A rule condition could be created to trust any file that is signed by a specific publisher. Publishers may sign multiple files for different applications using one key, or they may have a separate key for each application. If these files are modified, they would no longer be digitally signed and would trigger a deny action by a publisher-based rule.

When selecting a rule condition, it’s best to start with the strongest rule condition (hash) and decide if it’s manageable. If your organisation does monthly patching for a specific suite of applications, using hashes for your rule conditions would be difficult to manage because these hashes would change monthly. In this case using file path and file names may be easier to manage.

Step 3: Prevent users from being able to bypass the solution or change any of the associated rules

If your organisation does not have strong access controls and/or there are many local administrators, it can be challenging to create rules. For example, if your policies are based on file attributes, local administrators can bypass these. 

Put access controls in place to minimise these types of bypasses. Train your staff, especially those with administrator privileges, to know what application control and allowlisting is and what it is protecting against.

There may be cases where a policy requires an exception for a specific user or group. Before creating that exception and a hole in the policy, the reason behind it should be assessed. Other controls may be better suited to manage that need, such as a sandbox or an isolated device.

Step 4: Test before implementing

To make sure your allowlisting system works correctly, you should regularly test it to catch any mistakes in file permissions or ways someone might get around the rules and run programs they shouldn’t.

Once your system understands what normal behaviour looks like, you can turn on application control. This uses smart rules that update automatically, based on both what your system has learned and known threats from the outside world.

Before fully enforcing these rules, start by running them in audit mode. This lets you test how they work without blocking anything yet. Do several rounds of testing and fine-tuning across your organisation. Only after that should you switch the system to enforce mode.

Make sure the default rule is to block all programs unless they’re specifically allowed. Test thoroughly using:

  • positive tests: to make sure approved applications and software runs as expected and all other software that is not allowed is denied
  • negative tests: Try running unapproved software to make sure it gets blocked.

This way, you know your policies are working as intended.

When policies are set to enforce mode, ensure your change and incident management processes know how to handle any issues. Changes to the policy should go through a change management process, but if the issue is blocking business operations, then you may need to use an incident management process.

Step 5: Stay informed of bypass strategies

Some attackers use allowed software (like certain Windows system files) to bypass allowlisting and run malicious code. For example, msbuild.exe is a Windows binary file that comes with the .NET framework and is used for compiling and executing code.  AppLocker, the Windows application allowlisting software, will allowlist files in the Windows folder by default, which includes this binary file. An attacker could use this file to execute malicious code without getting stopped by AppLocker.

Stay up to date with bypass strategies for the technology you use. You may be able to mitigate a bypass technique to your application allowlisting policy by refining the allowlist rule or adding a blacklist rule.

Step 6: Review your policies regularly

Review the application allowlisting policies you set at least once a year. Your organisation can change a lot over a year, and this includes the applications that you use. Review your policies regularly and check that:

  • your allowlisting tools are updating automatically and are maintained by the endpoint or host-based protection software provider,
  • manually added rules are still needed,
  • there are no manual temporary exceptions that should be changed into new rules or removed, and
  • your rules are appropriate and don’t need to be made stricter or more specific. 

You may need to create temporary exceptions or new rules over time. The reason for these new rules or exceptions should be reviewed because alternative controls could be used, such as network segmentation or access controls.

How to measure success

Successful application control is easy to measure. While each organisation may use different settings and processes, the key indicators of success are clear.

Use the following points to check if your organisation is doing it right.

  • Access controls are in place to ensure the right application policies are applied to the right users.
  • All devices have software installed that enforces these application control policies.
  • Policies are mostly managed automatically using learned behaviour and other algorithms. but admins can also set manual rules when needed.
  • Users only have the access they need. This limits their ability to bypass the rules.
  • Known ways to bypass policies are monitored and included in your vulnerability management process.
  • New devices (like laptops, mobiles, or BYOD) get endpoint security software as part of your standard setup, with the right policies and rules applied.
  • Your settings block unknown or untrusted files from running. High-risk file types from the internet are also blocked from being downloaded or executed.
  • If someone tries to run a blocked file, the attempt is logged and stored centrally. These logs trigger alerts and are used in processes like incident or change management. If a critical program is blocked, an emergency change process is followed.