One of the most significant challenges today within endpoint security via application control is the sometimes tedious task of application categorization to create allowlists, denylists, and restrict lists.
What is application control?
Application control allows you to proactively manage and monitor all the applications running on your endpoints with policy-driven controls. Application control can be executed by allowing, denying, and restricting the applications your employees download and use. When looking to remove admin rights as part of your least privileged policy, these lists are critical prerequisites to ensure user productivity. They’re also necessary so only approved processes and applications execute on your endpoints, especially when running with elevated rights.
Application control: allow, deny and restrict the apps your employees download and use
As you implement application control, it’s critical that user rights are never elevated to execute applications because it opens a window for cyber criminals to exploit. Instead, allowed applications should be elevated directly.
What is allowing vs denying vs. restricting?
Allowing ensures that known, trusted applications are fully supported. Allowlists can allow applications to run based on the application name, signature, digital certificate, or other file metadata criteria.
To prevent malware from infecting your IT systems, you can add known malicious applications to a denylist. Denying denies applications based on attributes, file hash, location, or certificate.
Application allowing and denying are top-down strategies, often set by your IT leadership team. They work for a known set of applications. But what about the applications that don’t show up on any list?
After you define allowing and denying policies, you will still have a small subset of unknown applications to manage. Restricting prevents those unknown applications from running. Restricting provides a system for discovering the unknowns and adding an action that hinges on a reputation check.
Account for the unknown with a restrict list
This subset is constantly changing as new applications come to your attention from the bottom up. Sophisticated hackers are adapting code to evade detection by threat intelligence systems. Also, your users are frequently downloading new software and accessing new SaaS tools.
As you implement application control, you need to have a plan for how you will handle these scenarios. In addition to defining allowing and denying policies, you should have a “catch-all” policy for applications you don’t know about yet.
Define a restrict list policy that works for you
Restrict management will be different for every company depending on how strict you want to be. This strategy is highly customizable to match your cyber risk and your workplace culture.
- The least intrusive restrict policy would be to simply allow new applications without prompting a user to provide details or reasoning for needing the application at all.
- A bit more controlled application policy would require a justification first from the user and then allow the app to execute immediately. An administrator could retroactively review all new applications and their justifications on a regular basis – perhaps every Friday – and add them to existing allowing or denying policies.
- The strictest approach would be to sandbox any unknown applications and deny access until you feel confident that they’re safe to run. Sandboxing allows you to investigate applications and requires approval steps.
Get granular with application control
Rather than make blanket application control decisions at the application level, you could choose to be more lenient for some functionality and more strict for others.
For example, you could decide to elevate an application in a limited way so that users can do their jobs, but not allow them to touch any system folders or underlying OS configurations, isolating the system from malicious behavior. You could block commands or executable processes, or perhaps restrict access to an endpoint’s desktop, display settings, registry, clipboard, and handles/hooks.
For web-based applications, you could decide to block components of a page (buttons, forms, etc.) rather than an entire URL. Or, use Role-Based Access Control policies to set different rules for different types of users. For example, you may choose to block most users from accessing Facebook at work but allow your social media team access to the corporate Facebook account to do their jobs.
You may want to allow applications to run processes only on certain types of endpoints, by certain organizational groups, in certain geographic regions, or during certain times of the day. If you find applications attempting to run outside of the accepted conditions, you’ll be able to flag those applications and potential malware attempts.
