The older version (which shipped with Windows XP) is called Software Restriction Policies (SRPs), and its slightly newer, more updated cousin is called Application Control Policies (AppLocker). We will discuss later on about certain third-party tools that can extend the functionality of these core Microsoft offerings, but for now, we will concentrate specifically on these built-in tools. However, if you are using an enterprise version of Windows and/or Active Directory, there are two options that will always be available to you at no extra cost. There are many application whitelisting solutions out there available from third parties. There are also differences in deployment and management that you will want to consider. Each one of these options has pros and cons attached to them. You can block by path, by certificate/publisher, by network zone, or even by file hash. There are nuances within the whitelisting approach that we will discuss.
If a new tool is identified that you want to prevent users from running, there is no update required – a whitelist blocks unknown executables by default. Instead of listing out the “known bad” executables, whitelisting operates by blocking *everything* except applications you specifically know that users need to execute in their day-to-day jobs – a “known good” list instead. Whitelisting, on the other hand, removes a lot of the overhead from this by using the opposite approach.
You become tied into a game of whack-a-mole, an arms race of constantly updating the list of threats to be kept at bay. But the problem with blacklisting is pretty obvious – you are reliant on knowledge of every possible executable that a hacker might use, and need to then add it to your blacklist. For instance, you could blacklist executables such as PowerShell, the Registry Editor, known exploit tools like Metasploit or utilities that hackers might leverage such as the PSTools suite.
Simply put, blacklisting is where you stop users running “known bad” applications. So not only does effective application control protect you, it adds a further layer of alerting that can spot an attack in its early stages. But if you are strictly controlling what users can execute, not only do you block the attacker from escalation, but you can also identify possible indicators of compromise simply by the very action of attempting to run these items. In an “open” environment, an attacker within your network can introduce their own executables and scripts, opening up possibilities for further compromise and move closer towards the Holy Grail of accessing all of your data and infrastructure. All breaches involve some form of pivoting which generally involves running utilities which shouldn’t be allowed to run in hardened environments.Ĭontrolling what a user can execute is a pivotal part of this approach. Ensuring that an attacker cannot move laterally through a compromised network is crucial – if penetration occurs, we need to make sure that it is as difficult as possible for the attacker to broaden the scope of their attack and gain a deeper foothold into your environment. Whereas we have all for a very long time concentrated on maximizing performance – looking at how we create the best possible “user experience” – security is another big concern for consultants, architects and administrators. Securing your environment is a huge deal these days. Now you will see the rule in the following screenĪppLocker is a robust tool to manage corporate compliance and security on the desktop and server platform.This article is aims to be a comprehensive guide to creating a secure Software Restriction Policy and is quite a long read – we recommend you bookmark it now so you have it to hand when you need it. in this way you have selected Adobe Acrobat and any version will be allowed by this rule.
If you would like to select specific version, Click Next otherwise drag mouse product name shown product name. On the Permission page, Click Allow, Click NextĬlick Browse and go to the C:Program Files (x86)AdobeAcrobat 10.0Acrobat and select Acrobat.exe. Right Click on Executable Rules, Click Create New Rule
The following is an example to create a rule allowing Adobe Acrobat using AppLocker. Rules can be created to allow/deny any applications/scripts/installers to run per user or per group. You can configure the following rules in AppLocker via group policy objectĪppLocker can be found in Computer ConfigurationWindows SettingsSecurity SettingsApplication Control PoliciesAppLocker location shown in pictureĪn administrator creates or edits a Group Policy Object based on business needs. By using this feature, an administrators can ensure that security and licensing compliance needs are met, and to provide granular level security to align with corporate security compliance. AppLocker is a customizable rules that allow/disallow applications, scripts and installers on a per user or per group basis.