Application whitelisting has become the next great hope in the war on malware. It is not a new concept: whitelisting solutions have been around in some form for years, in both operating systems and anti-malware solutions. But the concept has gained momentum recently because of the perceived failure of more common anti-malware techniques — such as signature-based blacklisting — to stem the flood of malicious code.
Why whitelisting?
Our computers normally run in a ‘default allow’ mode where any piece of code is allowed to run unless specifically prevented. Whitelisting turns this logic on its head, preventing code from running unless it’s on a list of approved programs.
The logic looks sound. Fighting malware with blacklists has become a form of firefighting. Anti-malware packages are reactive, and at the speed things move today — especially with auto-mutating polymorphic viruses — some people believe their reflexes just aren’t fast enough.
Whitelisting is a failsafe approach. It doesn’t depend on timely updates. Any new code that tries to run on the system is defeated by default. But does it raise issues of its own?
Whitelist mechanisms
To work, a whitelisting system has to identify each piece of code. There are several ways of achieving this and most whitelisting systems deploy more than one.
The simplest method is to create a database of filenames (usually linked to specific path locations) for approved software. This is the easiest system to defeat: malware simply needs to replace good code with identically named executables.
For downloaded software, the system can base its rules on Internet zones. But this is limited to software that uses a Microsoft Installer Package (.MSI file).
A more common method is to create a fingerprint (typicially an MD5 hash) of the application code and add this to a trusted software database. As a hash is unique, any change to the code creates a different hash so it’s easy to spot if a program has been modified.
That’s also the problem. Updates and patches invalidate the existing hash and the process of authorising the code has to happen all over again. Any database of authorised software — whether online or held locally — must be updated frequently to allow for updates.
Software certificates
Software certificates and digital signing offer a more rigorous and structured method. For example, AppLocker, which is built into Windows 7, leans heavily on this approach.
Typically, systems that use software certificates make use of Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) technology, which is supported by most operating systems, to check whether a certificate is valid.
We have a high-profile example of this technique with the iPhone. Applications don’t get to run on this platform unless they are approved and signed by Apple. This certainly makes for a more secure and robust experience, but there are plenty of application vendors who are unhappy with what they see as a high-handed attitude. And this approach is good for as long as digital signatures remain uncracked. If the signing process becomes vulnerable, it’s game over.
The problem for PCs is that only a small proportion of software is signed and there are issues about who gets to do the signing. Not every software vendor wants the complication and expense of obtaining software certificates from a Certificate Authority. And a solution that depends heavily on certificates could lock out potentially useful open source or shareware software.
User selection
Most whitelisting solutions allow for some user interaction. If a program isn’t on the whitelist, the system pops up a dialogue box to ask the user if it’s okay to continue.
The degree of user interaction varies. For example, Kaspersky is using a version of Bit9’s Global Software Registry (GSR) — a database of hashes for known ’good’ software — in its Anti-Virus 2009 and Internet Security 2009 offerings. In implementing the whitelist, Kaspersky itself made some decisions as to how it is used. There are options for advanced users to make their own settings, but based on generalised ‘comfort levels’ rather than specific applications.
Different approach
The Bit9 GSR concept might sound familiar, being similar to the blacklists of malware signatures used by most AV packages. Comodo also uses a databases of hashes — running to around four million software titles currently. But updating these databases is less critical with whitelisting than it is with blacklisting. And that’s because with a whitelisting system, the environment defaults to a safe state.
What’s more, the loading and running of new software happens comparatively rarely, all of which suggests a reduced workload for the IT department. So what are the IT management implications?
IT landscape
For whitelisting to work, you have to know what software is running on your systems.
“Organisations have made great efforts in creating standardised environments, to cut support costs, and this has made whitelisting more viable,” says Greg Day, security analyst with McAfee.
There may be some work involved up-front — in software auditing and ensuring that all PCs conform to corporate standards. On the plus side, you’re going to end up with a much clearer understanding of your IT environment — and may even be in for a few surprises.
If you implement a standardised platform, you can also address that nightmare of the IT department — unauthorised software. Aside from the support headaches this causes, and the potential loss of productivity, such software might contain security vulnerabilities that the IT department knows nothing about, opening unpredictable vectors for attack.
The most recent Microsoft Security Intelligence Report, carried out by Secunia, has placed the blame for the majority of recent security vulnerabilities squarely on third-party applications.1 Implementing whitelisting requires that you have a very firm grasp on which applications should be installed and the whitelisting system enforces those choices (especially if you don’t provide mechanisms where users can permit unknown programs to run).
There’s a downside, though. “It takes away from business flexibility,” says Day. “For example, you may have mobile laptop users who need some level of admin rights, to be self-sufficient to some degree, because they are not easily supported by the IT staff.” And there are always people who regard themselves as ‘power users’ and want more control over their machines, regardless of whether they have the talent to actually manage them.
If you do provide the option for users to decide whether a program can run, you’re usually asking the person least qualified to judge whether software is trustworthy to make a decision with potentially disastrous consequences.
Fine-grained control
Many whitelisting applications allow for quite fine-grained control over permissions as one way of addressing the need to give users some control. For example, CoreTrace’s Bouncer deploys a ‘Trusted Change’ concept that allows you set the system to trust any software installed by a particular user, group or applications signed by a specific vendor.
AppLocker is even more flexible. It builds on the somewhat limited — and too easily circumvented — ‘software restriction policies’ found in Vista. The package offers version control — for example, you can stipulate that, say, Adobe Reader must be at least version 9 to run. It also incorporates a combination of whitelisting and blacklisting — you can define rules to either allow or deny software, and then add exceptions. For example, you could create a rule that says “allow all applications from this vendor (using digital signatures to identify them) except these ones”.
There are many other options, too, not just in AppLocker but in many of these whitelisting packages. They are getting more flexible as they mature. But flexibility can mean the same as complexity, and when you have that, you have the potential for error. In trying not to lock down the system too tightly, you might leave room for malware to run — perhaps because it’s installed by a trusted user, or from a trusted device or location on the network.
What’s more, not every user has the same software needs. Within any reasonably sized organisation, the IT department is going to find itself having to produce multiple whitelist configurations — and having having to monitor and update them — for different departments and user types. That not only adds to the complexity but also to the workload.
Standards
Current whitelisting solutions are proprietary, each using a different combination of approaches. Some check the application once (against, for example, a database of known good software) then never again unless it’s changed. Others, such as Comodo’s system, check it every time the application is run — nothing gets to go near the processor unless the whitelist approves it.
There is no common repository of software hashes — the closest thing we have is the National Software Reference Library (NSRL) run under the aegis of the National Institute of Standards and Technology (NIST) in the US.2 This produces the Reference Data Set (RDS) of software signatures — currently running at around 45 million items. These are used predominantly for computer forensics and law enforcement applications to identify software — but the software included in the RDS is not ‘known good’ but simply ‘known’, making it unsuitable for whitelisting applications.
Work to be done
Even with the relatively mature technology of software certificates, there is work to be done. “There are currently no standards for code signing,” says Melih Abdulhayoglu, CEO of Comodo. “However, we in the industry are is working on a standard for how code producers are validated.”
The Consensus Audit Guidelines (CAG) produced by a group of security vendors and organisations recently released a document called ‘Twenty Most Important Controls and Metrics for Effective Cyber Defense and Continuous FISMA Compliance’ in which whitelisting featured prominantly.3
Some believe the answer lies in the cloud, with checkable databases online, while others, like Microsoft, would like to see solutions that go down to the hardware level, in the way that BitLocker is being used for disk encryption. Of course, the idea that has been mooted by Microsoft, that every application should be ‘approved’ by the OS vendor, raises ugly issues of vendor lock-in and monopoly control.
Complex implementations, varying user needs and the desire to offer some control and flexibility for users mean that the concept of a fully locked-down system, thanks to the whitelist, isn’t going to be a reality for most organisations. And so whitelisting is most likely to find a place alongside current anti-malware technologies. Its promise of reduced workload and cost for the IT department may turn out to be mythical. However, it has a real part of play in increasing security.
References
1. Microsoft Security Intelligence Report, http://www.microsoft.com/security/portal/sir.aspx
2. National Software Reference Library, NIST, http://www.nsrl.nist.gov/
3. 'Twenty Most Important Controls and Metrics for Effective Cyber Defense and Continuous FISMA Compliance ', CAG, http://www.sans.org/cag/
