You may have heard of application whitelisting or application blacklisting where specific applications were allowed / disallowed depending on their nature. The progression of malware and the skills of attackers has made simple whitelisting and blacklisting a thing of the past. End user computing is normally the first port of call for attackers, it is the easiest and most vulnerable part of most enterprises. Elevated user privileges and user susceptibility is a dangerous combination, the concept of least user privilege is where all companies should start securing end user computing.
Application control is a small part of the wider Privilege Access Management (PAM) suite of controls but is a very important consideration. This article will take us a bit deeper into what application control is and why it should be on the radar for all companies.
The Australian Cyber Security Centre (ACSC) leads the Australian Government’s efforts to improve cyber security. The ACSC has published the “Essential Eight” which is a set of strategies to mitigate cyber security incidents. These strategies include the prevention of malware delivery and execution which includes application control specifically, to prevent execution of unapproved / malicious programs including executables, scripts, driver libraries and installers. The strategies and maturity of the implementation are the key concepts of the Essential Eight.
So now we know what application control is at a high level, let us get into a bit more detail starting with a real-world example. Most modern operating systems have hundreds, if not thousands of executable files that can be modified, some we easily recognise such as notepad.exe and others we do not. For example, notepad.exe normally belongs in the C:Windows folder, however on the computer that John from Accounting uses, it is stored on his desktop. On Friday afternoon, John tried to run notepad.exe however the application control policy has settings only allowing notepad.exe to launch from the C:Windows folder and the executable signature on notepad.exe must match what is determined in the policy as an allowed application. Both of these conditions failed to match the policy and luckily for John and his IT Security team, the application control solution has prevented the launch of an executable that was loaded with malware and was set to wreak havoc on the network.
As we mentioned before, most application control solutions have a wider and deeper breadth of services that start with that principle of least user privilege. Application control solutions are generally policy driven using both the user and the computer identities to drive this control from a central management platform. These policies can dictate which applications are allowed to launch, which applications are blocked, and which applications prompt the user to respond. As in the example above, John from Accounting can be given Just-in-time (JIT) privileges to launch an application that may not be controlled by policy. The policy can also dictate that all actions, both user and software are written back to the central platform for auditing purposes.
The applications that are allowed to launch, those that have been ‘whitelisted’ have to be managed from that central platform. The policies that we mentioned above from the application control solution can enforce cryptographic hash rules, publisher certificate rules, path rules to ensure the executable(s) are in a specific folder, etc. It is no longer enough to just allow a file name, package name or another easily changed application attribute as these are susceptible to attackers.
We now have a better handle on what application control is and how we can use it to control application executables for our end user computing platforms and the server environments. However, making sure the application control solution is fit for purpose can only be done by matching the technology to the business requirements. Not all application control solutions are made equally so time and effort must go into the decision-making process well before the technology is implemented.
Some of the business requirements that we would normally start with are:
- Does the technology align to the operating systems currently supported in your environment?
- Do you need a solution that is based on-premises or is a cloud / SaaS option preferable?
- Do you understand the applications currently running that you wish to manage?
- What are the reporting requirements for both real-time and historical?
- What level of integration with other systems do you need such as SIEM or packaging platforms?
These business requirements should hopefully give you an indication of the preferred application control solution that is suitable for your enterprise and will allow you to go forward with implementation an application control solution. You may find as you work through the business requirements that whilst application control is a good starting point, you may need the full set of features offered by a Privilege Access Management system. This may include integration with DevOps and build pipelines, the ability to manage scripting environments and even integration with capabilities such as serverless architectures.
A very important final note, however, is that application control by itself does not replace antivirus and other security software already in place on systems. Application control should be considered a complementary product and using multiple security solutions is the best way to an effective defense-in-depth approach to securing endpoints.
If you are considering application control hopefully this article has helped you along the way. If you are looking to improve your security posture and would like assistance with application control, please contact the team at Diaxion and we’ll be happy to assist with any questions you may have.
