2007-09-01
Abstract
Chief Security Officer for Bit9, Ian Poynter continues the conversation started last month by Dr Vesselin Bontchev about whitelisting as an endpoint security technology, and explores some of the questions he raised.
Copyright © 2007 Virus Bulletin
In the August 2007 issue of Virus Bulletin, Dr Vesselin Bontchev wrote a thought-provoking opinion piece about whitelisting as an endpoint security technology (see VB, August 2007, p.4). As Chief Security Officer for Bit9, a company highlighted by Dr Bontchev in his article, I feel compelled to continue this conversation and explore some of the questions he has raised.
Dr Bontchev’s piece is well reasoned, and I agree with most of his insights. However, these points apply to the whitelisting technology of five to 10 years ago – not the quite different whitelisting technology of today. In the scenarios he describes, Dr Bontchev accurately assesses many of the challenges of a whitelisting security model – ranging from managing the whitelist, to scalability concerns, to user and political issues.
But, just as anti-malware technology has evolved dramatically over the last decade, so too has whitelisting. In 2003, Bit9 obtained a two-million-dollar grant from the National Institute of Standards and Technology’s Advanced Technology Program (NIST ATP) to research and solve exactly the sorts of difficulties Dr Bontchev identifies. That project, and subsequent research, led to many surprising changes in the capabilities of whitelisting technologies that have already simplified whitelisting and endpoint security in general.
Let’s start with a fundamental reality that Dr Bontchev describes – anti-virus scanners are clearly the ‘weakest line of defence’, yet users are not implementing more advanced techniques because they are too complex to keep up to date.
I have found this to be true first-hand throughout my career in the security industry. But it is not the fault of the user. I believe it is our responsibility – our obligation as security researchers – to do better. After all, if we can’t make our technology accessible to users, who can?
I joined Bit9 because I wanted to find a better way – a more effective security model for the future of secure computing. In the paragraphs below, I describe two of the most significant advances that together have had a transformational effect on implementing a scalable, effective whitelisting approach.
Ask an enterprise to manage a local whitelist of executable files, and they will fail almost immediately. Software environments are too dynamic, the applications are too cross-dependent, the files themselves are too cryptic, and it is practically impossible to make sense of what’s what. Individual file-based management of whitelists is impractical, but fortunately there are new alternatives.
Let me illustrate with an example of trust. Suppose you run a large company with tens of thousands of employees, contractors, consultants and temporary workers. You are trying to ensure that no one bad gains access to your building. You could:
Run a background check on every person, every time they enter the building.
Allow the badges to be issued to authorized individuals, which are validated upon entry.
Clearly option 1 is too time-consuming and resource-intensive. Option 2 is the obvious choice. But in order to be successful, you must create a trusted process for the issuance and validation of those badges.
You trust your Human Resources department. You may trust your contractor to issue badges on your behalf. You may apply a more rigorous screening to the temporary workers, but ultimately once they get a badge, they are sanctioned. With an efficient badge verification system at the door, you can effectively screen individuals entering and leaving the building without hindering the free flow of authorized personnel.
The IT department of an organization does essentially the same thing when deploying software. They purchase products from manufacturers, download patches from Windows Server Update Services, and create software in internal development groups. They put processes in place to make sure everything is tested before it is deployed. As a result of this process, software is inherently trusted at the moment it is pushed out to a computer.
An organization’s whitelist can be built – and maintained – in an automated fashion by identifying and leveraging these existing business processes. For example, by tying your whitelist to a deployment server such as Microsoft Systems Management Server (SMS), the very act of pushing out software automatically adds it to the local whitelist. Cryptographic verification can then be done centrally and automatically. This structure means whitelisting itself becomes a transparent business process.
In this whitelisting model, trust is local, not global. No third party decides which software or processes are appropriate. No third-party policy updates are required. And no untrusted software, particularly zero-day, can install or run. Businesses find this extremely attractive because they have control over their systems and processes – a highly valued attribute in today’s culture of compliance.
This leads us to the second significant innovation in whitelisting technology.
We all recognize that users – and sometimes even IT professionals – don’t have a clue what to do with a message such as:
‘The program blah.exe is communicating over port 1900’
What is blah.exe? Is it part of an application I own? Is it malware masquerading under a common filename? When and how did it get onto this machine?
These questions demonstrate why determining the identity and authenticity of software is so important when whitelisting.
To that end, Bit9 has built an online ‘Global Knowledgebase’ for software identification and analysis, to ensure the integrity of a local whitelist.
People may be confused about the purpose of this knowledgebase – which has sometimes mistakenly been called a ‘Global Whitelist’ – so I want to be perfectly clear: the Bit9 Knowledgebase does not dictate policies for ‘good’ and ‘bad’ software to any consumers of the service. Bit9 has no interest in telling companies what should or shouldn’t run on their computers or anyone else’s.
In fact, the Bit9 Knowledgebase operates more like a search engine for trusted information about software. It collects and reports on files, products, publishers, security assessment results, vulnerability reports, and more. These attributes are becoming richer and more descriptive over time as Bit9 builds out the back-end of the service.
The entire knowledgebase is indexed by cryptographic hash values for each file – so a user of the service can look up a specific file, link to the application(s) of which it is a part, and access all the relevant information that has been collected.
So how is the Knowledgebase used? A customer building their whitelist would first identify their sources of trust as described above. This takes care of the overwhelming majority of applications that users install or update – and our customers verify this. But of course, additional applications will trickle in. In those cases, the Bit9 Knowledgebase is used to assess the risks associated with allowing that software to run.
Once again, this technique puts the user in control and they can choose when and if any particular software, vendor, or process should be added to the whitelist.
By taking advantage of the context provided by the Bit9 Knowledgebase, I believe that over time, confusing messages such as the one about program ‘blah.exe’ can be all but eliminated.
I’d like to offer just one final thought to those who think that whitelisting will never replace anti-virus scanning. Never is a long time. And as long as we have zero-day attacks and false positives, we will need to keep progressing forward.
Judging by the milestones we have achieved and the real-world, practical feedback from our customers who are deploying whitelist-based security, it seems one cannot ignore the fact that users are finding whitelists both more effective and easier to manage than the anti-malware software they had before.
Like most security professionals, I recommend a layered, defence-in-depth approach for the best results. But when it comes to the endpoint and the significant progress we’ve made, I wouldn’t be surprised if whitelists ultimately became the de facto standard for preventing malicious software on computers.
