If you would like to read the next part in this article series please got to Default Deny All Applications (Part 2).
Introduction
Software Restriction Policy (SRP) was introduced in October 2001 with the launch of Microsoft Windows XP Professional. Since then it has lived a pretty silent life – much too silent you could say. The purpose of this article series is to bring SRP ‘back to life’ out there in the real world, to encourage administrators around the world to re-think their software policies and maybe even implement SRP in its strongest setup: by the use of Whitelisting.
Why SRP?
Business users collaborate by using e-mail, instant-messaging, peer-to-peer applications etc. as never before. They use the Internet to search for and share information, and as this type of communication increases so does the threats from malicious code. Users also carry ‘uncontrolled’ data in memory sticks, MP3 players etc. back and forth from home to office – data which could be anything from Word documents or Excel spreadsheets to games, hacker tools and malware of any kind. Laptop computers are now more common than desktop computers and they connect to ‘uncontrolled’ networks, with both wired and all kinds of wireless technologies, putting them under heavy risk of being compromised by malicious code or attacks.
That is why I can think of lots of reasons why to implement SRP today:
|
Most corporations want to: |
To protect against these risks: |
|
Safeguard the computers against infection |
Malware, spyware, viruses, Trojan horses, Denial of Service (DoS) attacks, exposal of private or corporate data etc. |
|
Disallow unwanted “non-production” software to run on corporate computers |
Games and other non-production software decreases productivity and consume network & computer resources |
|
Disallow unlicensed software to run on corporate computers |
Running unauthorized software on the corporate network can result in legal matters – no organization wants to be known for piracy… |
|
Disallow unsupported software to run on corporate computers |
Prevent application conflicts which could lead to system crashes , incompatibility with production software, complicated troubleshooting etc. |
|
Disallow unknown software to run on corporate computers |
What you don’t know can (and probably will) hurt you… |
|
Reduce the Total Cost of Ownership (TCO) |
Virus outbreaks can cost a lot of money and so can the other above mentioned risks |
Table 1
Most IT administrators and managers want to eliminate the risk of computer viruses, and the other risks mentioned in Table 1. This can be done by introducing SRP to define which executables and which ActiveX controls can run, if only digitally signed and approved scripts should be able to run etc. We can actually enforce that only approved applications are able to run on the corporate computers by the use of built-in technology. We can lock down client computers and even servers so they are able to do only what we want them to – no more and no less. It’s free and right there in front of us…
Software Restriction Policies are enforced at run time, the user will receive a block message like the one in Figure 1 when trying to run unapproved code – Figure 2 shows the popup for disallowed scripts.
Figure 1
Figure 2
With SRP you can even limit local administrators from executing other code other than what you want them to. Lots of companies have given normal users administrative rights because of different issues with rights or applications, but with SRP on top of this setup, the ‘official’ network administrators can almost feel safe…
You might say that your users are not able to install unauthorized software, because they are not local administrators on their computers (which is very good), but the thing is that all kinds of executables can still run and perform unwanted tasks. As an example I can mention the small utility ProduKey, which is nice to have if you have forgotten your Microsoft product keys (for Exchange, Office, SQL or the Windows operating system itself). From an administrator’s point of view this just leaves us with one problem: even limited users are able to read the product keys on the local machine. This means that users can retrieve your corporate Volume License Keys (VLK) and install their home computers etc. by using your corporate VLK licenses!
One way to prevent this is to create a policy that blocks any file with the name ‘produkey.exe’, but the users will probably just rename the file and then it will be executable. Another way is to block the HASH value, a cryptographic fingerprint, of ProduKey.exe (the latest version is 1.6), but that value is different with older or future versions of the executable – and even worse: the HASH value can be changed with file merge utilities like SuperStorm and other tools. Let’s say you manage to block ProduKey, you still have a long way to go as many other applications ‘out there’ offer the exact same functionality.
So really, the only secure way to block software is to use what is referred to as Whitelisting… Let’s take a look at the difference between Blacklisting and Whitelisting.
Blacklisting vs. Whitelisting
The first port filtering on network routers in the early 1990’s was configured to block specific ports and allow everything else from the outside, the growing Internet. Network administrators were constantly one step behind hackers who changed the attacks to penetrate new services constantly. As soon as administrators blocked incoming TELNET then RLOGIN or FTP was attacked instead. This was an endless arms race with the hackers that could only lead to the “Default Deny” firewall rule to be implemented. Nothing is allowed by default unless we define some exceptions to the default rule.
Look at anti-virus applications that need constant updates of virus signatures to identify code that should not run on the network computers – instead of inverting the process and defining what we need to run and leave all other software behind. The same thing goes for software applications that run on computers around the world today. Why is it possible to run every piece of software by default when we, in most cases, know exactly what applications we need to be able to launch in the environment? Why not introduce the “Default deny all applications” rule to our client computers and make exceptions to the default rule for the applications that we want users to be able to run?
The “Default deny all applications” approach is known as Whitelisting (WL). When configuring the SRP in WL mode the Default Security Level is set to ‘Disallowed‘ – then additional rules, with exceptions to the default rule, are created. Think about it, no file can be executed on your computer unless you have specified this in a policy – don’t you just love the idea!
If we want to use WL, then we need a complete list of allowed software – and if we want to use HASH as identification method, we also need access to the executable files. If we want to use a certificate rule instead, we need either a certificate file (.CER or .CRT) or just access to the signed executable file.
Blacklisting (BL) is the default Security Level after enabling SRP, also known as ‘Unrestricted’ mode. BL could be referred to as a Sisyphean task – it never ends and besides that it doesn’t provide the same level of security that WL does. With the large numbers and forms that hostile code can take, it becomes a difficult task to block all of it by taking ‘code-fingerprints’ or using file names for that matter. Why maintain a list of 1.000.000+ types of malware – a list that is constantly growing rapidly – instead of maintaining a list of just the 50 or maybe 100 applications needed within the organization?
When looking at manageability, BL is by far easier to manage and implement, but it’s simply impossible to get the same level of security with BL as with WL. BL is OK to be used for loosely managed computers, but if we want to tightly lock down our computers to make them highly restricted and secure, WL is by far the best choice out there.
The ‘proof of concept’ tool Gpdisable, made by Mark Russinovich some years ago, is a good example on why WL beats BL. With Gpdisable, or a similar tool, even limited users are able to block group policies from running on a Windows client – including SRPs – except when SRP is enforced by the use of Whitelisting!
Only the “Default deny all applications” rule will pass the test of time. Unfortunately we still need anti-virus software to protect us from bad code download and execution. Let’s not forget that SRP “only” protects the local system from executing unwanted software – it can still ‘carry’ the executables on the hard drive, or as e-mail attachments, without conflicting with the policies at all.
The Future
I hope that Microsoft will continue to make the process of approving new applications easier in the coming years. It could be nice if it was possible to “import” an SRP or a given number of HASH values required by a given application. This would require that third party software vendors delivered an SRP “template” with their applications so that network administrators can easily import them – instead of creating the policies by hand themselves. Those “templates” should consist of HASH values of all included executables and preferably the required Dynamic Link Libraries (DLL).
Unfortunately too few software vendors use code-signing technology today. Hopefully software vendors will use digital certificates to sign their code more often in the future.
I want to share an idea I have about how to make WL administration easier. When thinking HASH rules, it requires the administrator to open a Group Policy Object (GPO) and browse to the files etc. If this process could be scripted and scheduled so all a network administrator would have to do would be to place an executable file in a central ‘approval’ directory (with proper NTFS permissions set), when the script runs it creates the HASH value automatically and adds the value to an “Unrestricted” policy in a specified GPO. This could also be done for certificates, just place the certificate in a central folder, wait for the script or process to occur and then the software is approved on the network. Well, this is just a dream – hopefully somebody will make it come true one day – maybe even Microsoft…
Conclusion
Software Restriction Policies have been around for approximately 6 years now and are still not a very popular thing – despite the fact that they could bring a very high level of security to both clients and servers. When correctly applied, Software Restriction Policies will improve the integrity of computers in your organization and most likely even lower the Total Cost of Ownership (TCO) in the long run.
In the next part of this article series we will look at how SRP’s are designed, implemented and configured.
External links
Brien M. Posey: Using Software Restriction Policies To Keep Games Off Of Your Network
Deb Shinder: How Windows Server 2003’s Software Restriction Policies Improve Security
Technet: What Are Software Restriction Policies?
If you would like to read the next part in this article series please got to Default Deny All Applications (Part 2).
