The latest security/compliance tool for desktop PCs is the application whitelist. This is an administration utility that monitors every application that runs (or attempts to run) and allows only those applications that are on the approved list.
Companies like Bit9 sell application whitelist tools. They have slick advertising and web pages. Here's a quote from Bit9's web page: "Imagine issuing a computer to a new employee and getting it back two years later - with nothing else installed on it but the applications and patches you had centrally rolled out." Appealling, no?
Whitelists will certainly prevent the use of unapproved programs. CIOs will have no worries about their team using pirated software. CIOs will know that their team is not using software that has been downloaded from the internet or smuggled in from home. They will have no worries about their workers bringing in virus programs on USB drives.
Of course, application whitelist techniques are incomplete. They claim to govern the use of programs. But what is a program?
Certainly .EXE files are programs. And it's easy to convince people that .DLL files are executables. (Microsoft considers them as such.)
Java .class files are programs. They must be "run" by the JVM and not directly by the processor, but they are programs. So are .NET executables (which usually sport the extension .EXE); they are "executed" by Microsoft's CLR, the counterpart to the Java JVM. Application whitelists will probably govern individual .NET programs (since they are launched with the .EXE extension) but not individual Java applications. They will probably stop at the JVM.
Perl, Python, and Ruby programs are text and run by their interpreters. They are compiled into bytecode like Java and .NET programs, but as they are read, not in advance. They can be considered programs. I'm fairly sure that application whitelists won't govern individual Perl scripts; they will allow or disallow the Perl interpreter. If you can run Perl, then you can run any Perl script.
And what about spreadsheets? Spreadsheets are not too far from Perl scripts, in terms of their program-ness. Spreadsheets are loaded and "executed" by an "interpreter" just like a Perl script is loaded and executed. I doubt that application whitelists will govern individual spreadsheets.
From what I can see, programs like Bit9's "Parity" application whitelist monitor .EXE files and nothing more.
OK, enough with the philosophical discussion of applications.
Here's the real danger of application whitelists: If they govern the use of programs (whatever we agree as programs) and the lists are created by governance committees (or software standards committees, or what have you) then they limit the creativity of the entire organization. The entire organization will be constrained to the approved list of software. No one in the organization will be able to think outside the approved-software box.
The entire organization will be as creative as the governance committee lets them be.
And not one bit more.
1 comment:
You’ve raised some valid points regarding the challenges of whitelisting, both technically and culturally. At Bit9, we have years of experience with whitelisting and have thought through these issues. Let me try and address your points:
First, what is a program? You are correct that it can take many forms. Let’s consider that a program is any content (file) that can be loaded and executed. It doesn’t have to be an executable (.exe) file. Bit9’s application whitelisting supports executable files, libraries, drivers, Java files, and even script files (e.g. Javascript, VBScript, batch files). When you think about it, protecting Java programs is not that different from normal executable files – you’re simply dealing with files with extensions like .jar and .class instead of .exe. The same applies to interpreted languages like VBScript. Whitelisting also works very well to prevent such interpreted programs from running at all – simply by not approving the interpreter engines that would execute such programs. (You don’t even need an exhaustive list of all such engines. That’s the point of whitelisting; just approve the interpreters and/or programs you do want to allow.) Office documents, such as Excel files, can be a challenge – Microsoft has allowed for simple documents to contain executable code (macros). It’s fair to say that everyone should have their Office protection set to prevent macros from executing without express consent.
Second, you raise concerns over the creative restrictions of whitelisting. While whitelisting as a concept is now generally well recognized, it is largely misunderstood. People hear “whitelisting” and they understandably think it’s a “list of white programs” (i.e. a bunch of hashes). That is only part of what a robust whitelisting solution can do – and might be all that some first generation tools can do. Complete whitelisting is not just about approved “programs” but also approved “policies”.
Policies can be general or restrictive, depending on your organization’s requirements and need to balance flexibility with security. For example, you might have a policy that says “Anything John creates on his computer using Visual Studio should be automatically approved”. Or you might be more general and say “Anything signed by Apple is approved to install other software”. You might want to transfer approval authority to your IT department with a policy like “Anything distributed through SCCM should be approved”. Advanced whitelisting products have the ability to specify these types of policies and more. Content is not static and we get it. It’s not easy for an organization to form some master “whitelist” of approved software that works for all of their employees all of the time. You need a rich and flexible policy lexicon that can describe not just approved software but also approved methods of software acquisition and creation.
Having access to one of the largest databases of known applications available is a benefit to companies using whitelisting as a layer of security defense. So when you do find a new program, you can assess its trust or threat and make an informed decision about whether it should be allowed.
While whitelisting may not be the one-stop security for all things digital, it is a powerful weapon in the arsenal, and the technology has come a long way. It can be used standalone or alongside blacklisting solutions and other security programs to form an effective protection for your systems. It can be set to be highly restrictive or even highly forgiving depending on your needs. In the end, the underlying premise of whitelisting is still as true as ever: the list of things you _want_ on your system (including the list of policies for how you want that software to arrive) is much smaller than the list of things you don’t want.
Thanks for letting me add to your discussion,
Harry Sverdlove, CTO
Bit9 Inc.
Post a Comment