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).

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.

Original source