Grey bar Blue bar
Share this:

Tue, 30 Mar 2010

BroadView - coming of age

Ever since Ron Gula's RiskyBusiness talk #142 about their Nessus philosophy, I decided to come out of the closet and share with our readers the work we do in the vulnerability management field. [Ed: If you don't listen to Risky Business then, as we say in South Africa, eish.] Ron explained that with Nessus they aim to give users a tool that can be used for monitoring and auditing - not enforcing. The "sed quis custodiet ipsos custodes" mantra comes to mind. For 9 years now we have been building two vulnerability management solutions named HackRack (for hosted, external scanning) and BroadView (for internal scanning) and it was especially HackRack that has claimed the limelight. The runt of the litter has always been BroadView, but alas (luckily?), no more.

We decided a while ago to invest our new ideas and technology in BroadView, and when that matured and stabilized, use the new BroadView as a base for new HackRack and HackRack PCI services.

And that process is nicely on track.

I mean, just look at this interface. The Blizzards page will allow BV users to get up to date stats about their environment but also allow them to quickly grasp the actual state of affairs on their network. Blizzards are visual sql queries that display averaged or calculated results of vulnerability scans as well as collected attributes. In the example below, one can quickly appreciate the impact of adding a batch of new machines to a scan, and the resulting impact on the New Issue count blizzard.

We don't see BV as just another vulnerability scanner. Its a data collector of note. It does not just scan,it also collects. From every networked device that is probed, attributes are collected that range from regular basic info such as IP addresses and operating system values, to machines without SMS agents and WebDAV directories on HTTP services.

In the weeks and months to come we will share with you the trial and tribulations to eventually bring to light BroadView v4, Final Release. We will share with you our frustration and jubilations in successfully executing intensity scans on virtualised hardware, how to mine for installed software on OS X and appreciating the amazing reduction in bandwidth utilisation by switching from SOAP to Thrift.

Well, I am off to go watch one our guys participate in a televised panel discussion - and at the same time figuring out if there are any advantages in being able to interface BroadView with our Saeco coffee machine ...

Mon, 13 Apr 2009

The power of data

We recently introduced some neat blizzards onto a PoC Broadview client.

On tha back of Conficker, our Broadview Dashboard sports a couple of instantly available blizzards that show:

1. How many machines, on all scans for the last 10 days, have patch MS08-067 missing

2. How many machines do not have SMS Agents, EPO Agents or Any AV installed

3. And without too much hassle one can quickly see where machines with MS08-067 missing also do not have EPO Agents, SMS agents or any AV installed. (enlarge image to see why)

4. All the results can immediately be downloaded into csv format for sorting and filtering. Easy to pick up the trends.

[caption id="attachment_3347" align="alignnone" width="300" caption="BVv4 Blizzard"]

BVv4 Blizzard


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.