In information assurance, it is critical to have the best reporting about your vulnerabilities. Vulnerabilities, as you may recall from an earlier blog, are software flaws that may leave a system open to exploitation. There are tools that help identify and assess vulnerabilities. They are called vulnerability scanners, or VA tools. These are tools designed to scan a network or host, discern the flaws and produce a report. Now, we will discuss a standard called OVAL that lowers costs and enhances your results, but vexes vendors.
A VA scanner will usually interact with its target. That is, it will gather data, analyze it and form a conclusion. To identify vulnerabilities, scanners may use at least three different methods. These methods are:
The first method is reading the configuration. With this method, the tool must log in to a host and identify the settings and files present. It will then compare what it sees to a tables of conditions that indicate the presence of flawed software. If there is a match, voila, the scanner reports a vulnerability. To do this, the scanner must have administrative or root credentials to its target. This is needed to see all files and settings. This method is safe, as it never destabilizes a host. It just reads stuff.
The real way to know if your steel-toed boots work is to drop an anvil on them
The second methods is to send attacks. The real way to know if your steel-toed boots work is to drop an anvil on them. If you are still able to run the Boston Marathon, then your boots worked. But, if you are writhing in pain, your footware was vulnerable. In much the same way, a scanner can send an attack that would be effective against an un-patched or vulnerable host. If an exploit is successful, then it is clear that there is vulnerability. The attack does not have to be a horrible malware installation; it is typically benign. This method of discerning vulnerability does not always require credentials to log in. Many tests can be done anonymously – no credentials. However, these security tests are often destabilizing. The target may reboot, become erratic or have to be reset. After all, it was attacked.
The last method is somewhat rare. It is looking for evidence of past exploitation. Here is how it goes. Vulnerabilities might be exploited. Some exploits leave distinctive artifacts, such unique files or Registry values. Ergo: if you can find one of these unique artifacts, then at some point before the system was vulnerable. It’s not a direct link, but it is an indicator. It is also possible to have a false positive. What if a host was vulnerable and exploited and then later patched. If the artifact was not removed, then a scanner could still generate an alert.
Most scanners today implement their own proprietary ways of using the three methods. That is, they develop their own languages and APIs to invoke each vulnerability test. Often, it is the person who writes the test who decides which method to use. So, one person might like doing attacks, another could prefer reading configuration. It is often an arbitrary choice.
Also, the actual vulnerability procedures are not portable between scanners. A security test written by the folks at GFI could not be directly copied to Nessus. This means using the P-word: proprietary. The vendors love this. Each one can say, “Our methods and vulnerability tests are better. Buy from us!” There is no metric available to compare the efficacy between vendors. No one can be refuted. May the best sales force win.
It stands for Open Vulnerability Assessment Language. OVAL is run by MITRE and other interested groups as a collaborative effort. This is a language that standardizes how to assess and report the state of systems and their vulnerabilities. OVAL uses the Read Configuration method of identifying vulnerability. The language standardizes three steps in vulnerability assessment:
Think of it as being like TCP/IP. Before TCP/IP, every major computer company had its own proprietary means of network communication. Novell (remember them?) had IPX. IBM had SNA. DEC had DECnet. If you had computers from any of these vendors, you had to also have their networking equipment. The vendors loved it – guaranteed sales. But, along came TCP/IP and then everything could inter-operate. The playing field became level. The communications rules (TCP/IP) became a constant. Competition and innovation drove prices down and choices up. OVAL does that for vulnerability assessment. The supported platforms that can be assessed include the biggest vendors:
So, what exactly is OVAL? To be sure, it has many aspects, but at its core, it is a large set of definitions that define vulnerabilities. These OVAL Definitions, as they are called, are snippets of XML code that define a vulnerable configuration and link it to a CVE. You can see an example here. These definitions are freely available at MITRE or other repositories. Anyone can download them. To use them, all you need is a scanning tool that can parse and interpret an OVAL definition. The steps for OVAL adoption are well-known and openly published. A huge number of OVAL definitions are created for the publicly known vulnerabilities identified in CVE.
OVAL Definitions are typically spot-on accurate. They precisely identify vulnerabilities and rarely have errors. Quite often, the creator of OVAL definitions is the vendor with the vulnerability, like Cisco, or Microsoft. Who would be better to do this than the party that created the product and flaw? Third parties can also write OVAL definitions. So, in summary, OVAL is:
So, why don’t all the vendors buy in to OVAL and make it their core vulnerability detection architecture? After all, OVAL is great. It’s highly accurate. Much of the source for identifying vulnerability is free and openly published. It’s transportable between products. The answer is money. If one big scanning vendor endorses and uses OVAL as its foundation, the others will follow. If vendors become OVAL-ized, then results is a constant between products. Price would then become the great differentiator. No vendor wants a price war. So, it is like the nuclear deterrent: Mutual Assured Destruction. If you nuke us, we nuke you.
Support for OVAL is creeping in slowly. Nessus supports importing OVAL definitions. Eeye Security (Retina scanner) plans support for OVAL. GFI has a number of OVAL tests built it, but nothing overwhelming. None have said OVAL is their foundation.
They’d rather have you running in circles, wondering which tool is best.
If vulnerability assessment and OVAL are of interest to you, the Learning Tree course Hands-On Vulnerability Assessment: Protecting Your Organization covers this topic.