Grey bar Blue bar
Share this:

Mon, 2 Jul 2007

On vulnerability, root cause, white-listing and compliance

Many years ago, when we first released 'Setiri' one of the controls that we preached was website white-listing. As talk-back trojans would connect back to arbitrary web servers on the Internet, we argued that companies should create shortlists of the sites employees are allowed to visit. This, we argued, was much more feasible than trying to identify and block known 'bad' sites. Of course, there are a number of other compelling reasons for implementing this kind of white-listing, and of course nobody does it (even though I've seen fairly good technical implementations of this concept).

On a recent Tenable podcast interview of Marcus Ranum he makes the same point with regard to anti-virus: Instead of trying to list and identify the many thousands of bad programs that could run on your computer, wouldn't it be simpler and wiser to list the very small number of applications that are allowed to run on your computer, and treat everything else as malicious? Ranum acknowledges in the interview that some of his views might be a bit idealistic, but its clear that the principle holds true across many different spheres of security. Its not a new idea, really.

A relatively new (I think) application of this concept is in vulnerability scanning. We've always understood the point of vulnerability scanning to determine (either locally or remotely) what weaknesses or vulnerabilities a given system might have. That is, we're scanning for 'bad' things. Scanning hundreds of thousands of systems, as we do with our BroadView service, we've come to focus increasingly on what we call 'root cause analysis'. Our reasoning here is that an entire class of vulnerabilities often share a single, root, cause. If we can identify the root cause then its much more efficient to scan for and remediate that, than all the different symptoms it causes. Patching is a case in point. Come on! This problem is not a science rocket and yet, in a vulnerability scan of a sufficiently large network, we will find a high proportion of machines that have vulnerabilities because they are not fully patched. We need to understand the root cause of this, and its typically that something is going wrong with the patch management software - the agent is failing somewhere, the machine is firewalled, the machine is not in the correct windows domain, the machine has not rebooted, etc. It makes much more sense to scan for this small number root causes, than for the very large number of possible symptoms.

The approach described above is more efficient than traditional vulnerability scanning, and is actually a form of white-listing: Instead of trying to search for an infinite number of bad things on a system, we rather check that a small number of good things are running right. Once you go this way, it quickly makes sense to take the concept much further, and Tenable were quick to spot this with Nessus' compliance scanning checks. Its relatively easy to create a 'model' system; one that is known to be fully patched, securely configured and properly maintained, then compare every other system with this one and consider anything that deviates from this to be insecure. With this approach you can simultaneously increase accuracy and scope - checking for an infinite number of vulnerabilities will (theoretically) no false positives. This kind of trade-off is generally hard to achieve in security.

Once we make the paradigm shift from black-list to white-list vulnerability scanning a whole new world of possibility opens up to us. There are challenges with this approach to be sure, but I wouldn't be surprised if many of them aren't rooted in black-list thinking about white-list scanning. For example, there are entire segments of our industry that focus on building black lists. Tenable themselves do this with their commercial 'live' feeds, which perpetually add more checks for the Nessus scanner. With white-list scanning it would make more sense to maintain and sell 'white-lists' or baselines. For example, why not have a service whereby you continuously update a secure base installation of a typical OS. A vulnerability scanner could then fingerprint that base before scanning and identifying systems that deviate from that base. The big problem will lie with systems or subsystems where there is no base to scan against. Web servers and web applications immediately spring to mind, for example.