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.