Default Deny All Applications (Part 2)

If you missed the first part in this article series please go to Default Deny All Applications (Part 1).

Introduction

Since Windows XP, administrators around the world have had the option to define Software Restriction Policies (SRP) for their client computers to control what software is allowed, or not allowed, to run. So far too few organizations have implemented this functionality despite the fact that it could actually bring a very high level of security, depending on how it is enforced. In this second article about SRP we will look at how to implement what we could also refer to as “software filter policies”.

Danger zone

Before we get too far it is important to point out that, prior to introducing SRP on production computers, you should plan and test them thoroughly. This can be done in Active Directory (AD) by isolating a single test machine or user object in an Organizational Unit (OU) or by setting “Apply Group Policy” permission on the Group Policy Object (GPO) to only that single test-machine or -user account. SRP can even be used on Stand-alone computers if you don’t want to touch the production environment at all. I would recommend you use virtual machines for basic testing and ‘production-like’ machines for the final tests. After heavy testing, the SRP should be implemented on pilot users in groups – it’s better to take small steps than hurrying into disaster!

The overall process

Mistakes in the design or implementation of this can cause considerable user frustration, and even loss of money or productivity, so watch out as you go along. This takes a lot of planning work, testing and probably some maintenance from the day it is introduced in the production environment. From that point on you will be able to sleep tight at night…

The following list gives a quick view of what to have in mind when introducing SRP in a Windows environment.

When designing the SRP setup, different decisions must be made, for example:

Decide between user and computer GPOs: what AD objects should the SRP policies apply to?
Decide between a Blacklisting (BL) and a Whitelisting (WL) approach (WL is recommended if possible)
If using the BL approach, a list of everything that should not run must be made
If using the WL approach, a list of everything that should run must be made
Decide what SRP options to use (enforcement, designated file types, administrator exceptions etc.)
Decide what type of rules to use (path, HASH, certificate or Internet zone)

When testing the SRP setup, different steps must be taken, for example:

Test the basic functionality in a virtual lab (using Virtual PC/Server, VMware or similar)
Test the functionality in your environment by using ‘production-like’ machines (and user accounts)
Test with small groups of pilot users in steps of 5-10 users over a few weeks, then scale up
Continue to the next pilot group only after successful implementation for the previous pilot users
Be sure to test all the different user types and machine types you need to secure with SRP
Be sure to test upgrade scenarios, like patching of the operating system, upgrading third party applications, migrations etc.
Also focus on performance on the different hardware in your organization. Implementing SRP will in most cases affect system performance a bit, depending on how it is implemented (see the part about Trusted Publishers)
Sometimes applications launch other applications, make sure this is under full control
By default Desktop and Start Menu shortcuts (.LNK) are blocked, make sure to modify this as needed
Be sure that any admin scripts (e.g. login scripts in SYSVOL/NETLOGON shares etc.) are able to run

Before introducing SRP in production, some procedures should be in place:

Introduce a written workflow on how applications, updates etc. should be tested, approved and introduced on the network, so everybody is aware of the procedures required
Be sure that management knows SRP pros and cons and that they agree on the decision to introduce it
Have a fallback plan on how to get rid of the SRP GPOs fast, for certain users, groups, computers, sites etc.
User education: inform users why SRP is important and what the procedure is to acquire new software
A small tip: Put descriptions on SRP rules, over time a good naming convention will save you some time

Different paths to SRP

Configuring a Software Restriction Policy is basically only a few steps:

Creating a User or a Computer GPO and placing it on a Site, Domain or OU (or as a local policy) and enabling SRP within the Group Policy. The SRP settings are located here (see Figure 1):
Computer Configuration| Windows Settings | Security Settings | Software Restriction Policies
User Configuration | Windows Settings | Security Settings | Software Restriction Policies

The first time SRP is introduced in a GPO, the option “New Software Restriction Policies” will be available.

Figure 1

Setting the Default Security Level. Figure 2 shows how the level is set by right-clicking the wanted level and choosing “Set as default“.
- The default level is ‘Unrestricted‘ which means that all software can run and that additional rules for disallowed software should be made – this is also known as Blacklisting.
- The most secure level is ‘Disallowed‘ which means that no software can run and that additional rules for allowed software should be made – this is also known as Whitelisting.
- By default the system creates a few rules that allow the operating system to run without any inconvenient blocking
  NB! If those rules are removed or changed without any thought, the affected system(s) could become unusable.

Figure 2

With Windows Vista and Longhorn we have a new level called ‘Basic User‘ which allows programs to execute as a user that does not have Administrator access rights, so the user can access resources accessible by normal users only. This level is not addressed any further in this article.
File types can be removed and added to fit any environment, but the default file type list includes the most common executables: BAT, CMD, COM, EXE, HTA, LNK, MSI, OCX, PIF, REG & SCR and in addition these extensions: ADE, ADP, BAS, CHM, CPL, CRT, HLP, INF, INS, ISP, MDB, MDE, MSC, MSP, MST, PCD, SHS, URL, VB & WSC.

Note: As the Designated Files Type Properties dialog states, the list is “in addition to the standard program file types, such as EXE, DLL and VBS” – I haven’t been able to get a complete list of those, but I have confirmed that VBS, VBE, JS and JSE are blocked even though they are not in the list. I would have preferred a single list administrators around the world could change as needed, but that’s how it is.

Figure 3

Setting up exceptions to the Default Security Level. These are known as ‘Additional Rules‘. Please see the subject “Additional Rules” in this article for further information.
Configuring ‘Enforcement Properties‘. See Figure 4, this includes:
- “All software files“: We have the option to check DLL‘s (Dynamic Link Libraries) when they are executed too. This is not a default setting and will have some impact on both performance and planning/implementation/maintenance tasks.
- “All users except local administrators“: Here we can choose whether or not SRP should apply for Local administrators. By default all users are hit by SRP. This policy option is only relevant for computer policies.
- “Enforce certificate rules“: Option to choose whether or not to use certificate rules should be applied. Note: As stated in the dialog in Figure 4 “Certificate rules will negatively impact the performance of your machine”.

Figure 4

Configuring ‘Trusted Publishers Properties‘, also known as Authenticode policy options (see Figure 5). In this dialog we can choose who should be able to select Trusted Publishers for certificate rules. We also have an option to verify whether a certificate is revoked or not, and/or to check if the timestamp is valid when it is added.

Figure 5

Additional Rules

When configuring Additional Rules, a method – or a couple of methods – on how to indentify software should be decided. We have 4 different software identification methods available:

HASH rules
HASH’es are cryptographic fingerprints that remain regardless of the file name and location. These are especially good when using WL, but not that effective when BL (the reason for this is partly described by the ProduKey example in my first SRP article): An MD5 or SHA-1 HASH gives strong software identification of the ‘ProduKey.exe’ binary file, so allowing a specific HASH value to run makes sure that only that version of the executable can run. However, disallowing a specific HASH only affects one version (or compilation) of the application and a smart user can change the file pretty easily so it is identified as another (unknown) piece of software. The word ‘unknown’ is very important in this matter – it’s really the key to decide between BL or WL – do we want users to be able to execute software we don’t know, yes or no?
If users should not be able to run an old version of a specific application, let’s say it’s ‘buggy’ and causing system crashes, using a ‘deny this HASH value’-rule would be a good decision. Please keep in mind that a new version of a given application will always result in a new HASH value that must be allowed – or disallowed.
Certificate rules
Certificate rules uses signed hashes and provides very strong software identification, but as we trust a given certificate we actually trust all software signed with that specific certificate. This could be a good thing or a bad thing. It’s a good thing if we, for instance, get an application from a third party vendor who signed all the significant files in the application (maybe including DLLs), so instead of making a given number of HASH rules we can just create a single rule that trusts the certificate and we are up and running. But, let’s say I trust a digital certificate used to sign some tool from Microsoft (or any other software vendor) – now my users are able to run all applications signed by that specific certificate… Hmm, so the problem is to know exactly what applications were signed by that certificate? Without that knowledge we don’t know what we have allowed. Instead of allowing just the single application we needed for our users, we might have allowed hundreds of applications from the vendor to run on our systems.
Testing of Certificate rules can be done by using these tools: File Signing Tool (Signcode.exe) & Certificate Creation Tool (Makecert.exe).
Path rules
Path rules are the most common and “easy-to-use” rules we have. Path rules can deny or allow a file on a specified location (e.g. “C:\Scripts\Script.VBS“), a filename (e.g. “Script.VBS“), a folder (e.g. “C:\Scripts“), a UNC path (e.g.”\\SERVER\SHARE\File.VBS“) or a registry path (e.g. “%[Registry Hive]\[Registry Key Name]\[Value Name]%“). Path rules can use environment variables (e.g. “%WINDIR%“) and the wildcards ‘?‘ = one char (e.g. “\\SERVER??\Share\Script.VBS“) and ‘*‘ = any number of chars (e.g. “*.VBS“).
If you are using path rules a few things need to be addressed:
- If a given folder path is set, this also effects all executables in all subfolders
- If a user has write access to a folder that is set to Unrestricted, the user can copy any file to that directory and execute it from there. The design should take care of this issue, perhaps by introducing ACL (Access Control List) settings by the use of Group Policies
- If the user has write access to an executable that is specified as Unrestricted, the user could overwrite that executable with another one to circumvent the SRP
- If a folder path includes environment variables, like %TEMP%, even a limited user could change the user environment variables by using the SET command to another path (SET TEMP=C:\MyFolder) – and suddenly the user can control what software can be run by copying executables or scripts to that path.
As stated above, users may try to rename or move disallowed files – or overwrite unrestricted files to circumvent the SRP – this is why HASH or Certificate rules are normally considered ‘best choice’.
Internet Zone
Internet Explorer security zones can be used to control software installation and applies to only Windows Installer packages (.MSI) that are run from one of the default Internet zones. These rules are not that common to use.
When multiple rules are used they are evaluated in the order mentioned above, the default rule will be evaluated as the last rule – the most specific match will take precedence.

SRP Limitations

Some limitations of SRP must be taken into consideration. The scope of Software Restriction Policies is not the entire operating system as you might expect. SRP do not apply to the following code:

Drivers or other kernel mode software installed
Any program executed by the local SYSTEM account
Macros inside of Microsoft Office documents (we have other ways to block those by using group policies)
Programs written for the common language runtime (these programs use the Code Access Security Policy)

Conclusion

Software Restriction Policies demands a special, and time consuming, workflow when introducing new software and updates in the environment, but besides from that it brings a level of security so much higher than with the “default allow all” setup. Some environments might not be suited for SRP, but my guess is that most networks have computers and/or users for which the SRP technology is ‘spot on‘.

It takes dedication, understanding and hard work to implement a “Default Deny” policy – which might be why it is seldom done… One thing is certain, implementing such policies in the correct way will make sure the network administrators can sleep much better at night.

Over the next couple of years it will be interesting to see if Microsoft will continue to develop this part of the Group Policy environment – or if something even better arrives, who knows…

External links

KB 324036 How To Use Software Restriction Policies in Windows Server 2003

Technet: Using Software Restriction Policies to Protect Against Unauthorized Software (Vista/Longhorn)

Technet: Software Restriction Policy for Windows XP Clients

If you missed the first part in this article series please go to Default Deny All Applications (Part 1).