Implementing application control

Application control is a method of strictly managing what programs can be run in your environment.

Summary

Application control is a security control that only permits specific software packages to run. This control has evolved over time, and used to be reliant on manually configuring policies and rules. Application control can include a previous control: application allowlisting, previously called whitelisting, which is a security control that only permits specific programs to run. Application control is a feature found in most modern endpoint security software which should include regular updates from the vendor to detect and block the latest malware behaviours.

Drive-by downloads, or unintentional downloading of files from a website, and malicious email attachments are the most common causes of malware incidents. Endpoint protection with application control protection can prevent these incidents.

Purpose

Devices used in the organisation are protected with software that can prevent malicious software from running, and only allow programs that are commonly run or expected to run.

Measuring success

Successful application control has straightforward and measurable criteria. Differences in this control between organisations will be in the configurations set and the operational processes followed.

Use the following criteria to measure your success in this control:

  • Your organisation has software installed on all devices that enforces application control policies.
  • These policies are automatically managed using learned behaviour and other algorithms. Manual policies and rules can also be created and enforced by administrators.
  • Your organisation enforces access controls which allow the correct policies to be applied to the correct end users.
  • Your organisation enforces the principle of least privilege which limits an end user’s ability to bypass the policies.
  • You monitor known policy bypass techniques, and include this in your vulnerability management process.
  • Your standard build-hardening process includes deploying the endpoint software to any new devices. You will need to consider your workstations, servers, laptops, mobile devices, and any other device that accesses organisational data. This could include organisation-owned and bring-your-own-devices (BYOD).
  • Policy logs are recorded and stored in a central location to capture attempted and blocked file executions. These logs are configured to trigger alerts that feed into operational processes, such as incident or change management. An emergency change management process is followed when critical programs are blocked.

Application allowlisting: key takeaways

  • Application control has come a long way since the day of manually configuring policies and rules. The feature now comes included in common endpoint protection software, and you can save resources by relying on the system to tell you what programs or actions should or should not be executed.
  • Use application control features that come with the operating system if you can. These policies and configurations can usually be managed centrally. It can help reduce the cost of the control, instead of purchasing another piece of software.
  • Application control is one security control that should be paired with others in the CERT NZ critical control list for a “defense in depth” approach. An attacker can bypass even very strict rule conditions by hiding their malicious code in other trusted, allowlisted applications or software packages. Application control is also not effective if the applications are vulnerable and unpatched.
  • Enforcing a policy with file or folder-based rules will be difficult if there are users that have access to write and execute on a folder (for example, multiple local administrators). With this access the users could either modify a file or write a new file to the folder to execute an untrusted file. It’s important to be alerted when something is blocked so you can investigate, either through a tool or centralised logging
  • Ransomware attackers have previously disabled tools to disguise their activity so alerts are necessary to raise the alarm if the tool is ever disabled on an end point.

Advice for implementation

Enable application control software or policies.

Enable application control

Application control is a multi-purpose control that is proven to help with security and prevent the execution of unauthorised files.

In order 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 is a control that can be implemented in many different ways to reach the same end goal. It largely depends on what resources your organisation has available and how ready the organisation is for change. Below are steps that you can follow to get started with implementing this control.

In many organisations, you can achieve the intent of this control by using modern endpoint protection software such as endpoint protection and response (EDR) tools, which can detect and block malicious activity on systems. When deployed and well-maintained/ 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 allowlisting, it can achieve significant protection with much lower effort.

1. Set a scope and understand your environment

Assess the resources you have and the devices in your network, to help set a scope of devices for your implementation. Think about the:

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

When assessing the devices in your network, determine which devices to cover first. These should be higher risk devices that access internet services, such as end-user laptops and desktops, or anything else exposed to the internet such as VPN, email servers or webservers.

Analyse which software, programs, and files are used in your environment. While you might rely on automated policies to control which programs can’t and can run, it is still important for you to understand what is normal. This includes analysing client devices like laptops, desktops, and servers.

2. Enable policies for different user groups and devices

Enable application control in an audit or learning mode to start. Application control technology usually has two policy modes: audit and enforce. In audit mode, file execution attempts are recorded and a baseline of normal behaviour is set. These attempts might also be compared against default policies based on how those files are expected to interact in most environments. The file will continue to execute, and it will give the system time to learn different behavior. Enforce mode means that the file execution attempts will be checked and actioned if there is a match against an existing policy.

TIP: If your technology comes with a default policy, start with that policy and run it in audit mode across a group of devices.

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. When creating or modifying rules, you can use several rule conditions:

  • 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.

If your organisation does not have strong access controls and/or there are a large number of 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.

TIP: 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.

3. Test the policies before implementing

Once your system has created a baseline of normal behavior, application control can be enabled and use policies that are automatically updated and enforced. This means the system will rely on internal learned algorithms (based on behavior it has seen on your network) and external expected algorithms (based on attacks seen in the wild or in other environments) to enforce this control.

Once these policies are created and run in an audit mode, you need to test and roll them out across the organisation. Do several rounds of testing and refining before you switch the policy to enforce mode. Remember to ensure that the default rule is to deny file execution otherwise the control is not effective. Thoroughly test the policies with positive and negative tests. Positive tests mean allowed applications and software are permitted to run and all other software that is not allowed is denied. Negative tests mean software or applications that are not allowed are permitted.

TIP: 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.

4. Stay informed of bypass strategies

Application control policies can be bypassed using trusted and allowlisted software. 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.

5. Review your policies regularly

Review the application control 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:

  • Automated policies are being updated and maintained by the endpoint or host-based protection software provider.
  • Manually added rules are still applicable.
  • There are no manual temporary exceptions that should be changed into new rules or removed.
  • Rule conditions are appropriate and don’t need to be changed to be more strict and specific. For example, moving from a file path rule condition to a file path, file name, and file type rule condition.

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.