IVIL : An XML schema to exchange vulnerability information

Last Friday I had the pleasure of discussing security software with Zate, the author of the Nessus Bridge for the Metasploit framework. During the conversions we both agreed that it would be very practical if there was a way to make various security tools interchange vulnerability information more easily and openly. During this discussion IVIL was born, the Intermediary Vulnerability Information Language.

IVIL is an XML schema to feed vulnerability information that is the output of a tool like e.g. Nessus, Nikto or OpenVAS into a tool to further use this information like e.g. Seccubus.

We felt that there is a need for an open, non-proprietary language that is lean and mean even though a lot of tools offer a native XML output because such a solution has a number of advantages.
  • Not need to modify the receiving tool. Having an intermediary language means that a new tool can be integrated into an existing tool without the need to make modification to the tool receiving the information.
  • Support for home brew tools. The open format makes it possible to integrate home brew tools with other tools without the need for the original author to put effort into supporting a tool “nobody uses”.
  • Programming language independent. There is no need for anybody that want to integrate two tools be master the programming languages these tools where written in.
We felt we needed to share this work on IVIL to get the widest possible basis for adoption.

During our initial call we came up with this initial version of the XML schema: 
 
<IVIL version=0.2>
    <addressee>
        <program>Seccubus|…
        <programSpecificData>
            <ScanID>
            <ScanID>
        </programSpecificData>
    </addressee>
    <sender>
        <scanner_type>Nessus|Nessus|Nikto|MSF|OpenVAS
        <version>
        <timestamp>YYYYMMDDHHMMSS</
    <sender/>
    <findings>
        <finding>
            <ip>
            <port>
            <id>
            <severity>
            <finding_txt>
            <references>
                <cve>
                <bid>
                <osvdb>
                <url>
                <msf>
            </references>
        </finding>
    </findings>
</ivil>

During our initial call we came up with this initial version of the XML schema:
 
<IVIL version=0.2>
    <addressee>
        <program>Seccubus|…
        <programSpecificData>
            <ScanID>
            <ScanID>
        </programSpecificData>
    </addressee>
    <sender>
        <scanner_type>Nessus|Nikto|MSF|OpenVAS|Qualis|...
        <version>
        <timestamp>YYYYMMDDHHMMSS</
    <sender/>
    <hosts>
        <host>
            <ip>
	    <findings>
	        <finding>
                    <port>
                    <id>
                    <severity>
                    <finding_txt>
                    <references>
                        <cve>
                        <bid>
                        <osvdb>
                        <url>
                        <msf>
                    </references>
                </finding>
            </findings>
        </host>
    </hosts>
</ivil>

So, lets go through the meaning of each block.
 
<IVIL version=0.2>
    <addressee>
        <program>Seccubus|…
        <programSpecificData>
            <Scan>
            <WorkSpace>
        </programSpecificData>
    </addressee>

The addressee block of the file is optional. It can contains information specific to the receiving program. E.g. for Seccubus you could use this block to specify which workspace and scan to load the data into.
 
    <sender>
        <scanner_type>Nessus|Nikto|MSF|OpenVAS
        <version>
        <timestamp>YYYYMMDDHHMMSS</
    <sender/>

The sender block contains generic information about the scan. Which scanner was used, which version and when did the scan take place. There three attributes of the sender are mandatory, but other attributes can be added if so desired.
 
    <findings>
        <findings>
            <ip>
            <port>
            <id>
            <severity>
            <finding_txt>

The header of the findings block defines on which host ip and port the finding was found, this information can also be stored in the host block of the per host version of the schema. It then contains the id of the finding (e.g. the Nessus plugin number), the severity (0=undetermined,1=low, 2=medium, 3=high) and a human readable description of the finding. For Nessus this description would be the combination of the finding description and plugin output
 
            <references>
                <cve>
                <bid>
                <osvdb>
                <msf>
                <url>
            </references>

The references block contains one or more references. CVE tages refer to CVE findings in the format (CVE|CAN)-YYYY-####, BID to security focus vulnerability database findings in the format BID:####, OSVDB tags to Open Vulnerability DataBase references in OSVDB:##### format, msf tags refer to Metasploit Framework references in the format xxxxx/xxxxx/xxxxx and url tags can be used to refer to generic URLs.
 
        </finding>
    </findings>
</ivil>

This block closes the IVIL file. So let's say that Zate wants to write a module that starts a Nessus scan and uploads the result to Seccubus. All he needs to do is write a command line program that starts the scan, outputs the results into IVIL format and load the IVIL into seccubus. the command line would look something like this.
 
> /opt/zatescan/perform-nessus-scan > /tmp/scan.ivil
> /opt/seccubus/bin/load-ivil /tmp/scan.ivil

10 Comments

thanasisk
It is always nice to see Autonessus(yeap, I am old enough to remember that one!) Seccubus gaining more and more traction. Having said that, given that this is to be used as an IL, why not go for a more binary format such as Google's Protocol Buffers (just an example, there are quite a few seemingly equivalent solutions out there but this is the one we are using here, solving a similar problem to yours).
In any case, keep up the good work Frank :)
Frank Breedijk
<a href="#comment-7346" rel="nofollow">@thanasisk </a>
<blockquote cite="#commentbody-7346">
<strong><a href="#comment-7346" rel="nofollow">thanasisk</a> :</strong>
<p>Why not go for a more binary format such as Google’s Protocol Buffers (just an example, there are quite a few seemingly equivalent solutions out there but this is the one we are using here, solving a similar problem to yours).<br />
</p></blockquote>
We have decided for XML because most tools have some sort of XML output in the first place, so transcribing one XML format to the other feels more natural then using a binary format. Besides that the Google Protocol Buffers page describes some advantages that seem to be right on the money for this use case:
<blockquote>However, protocol buffers are not always a better solution than XML – for instance, protocol buffers would not be a good way to model a text-based document with markup (e.g. HTML), since you cannot easily interleave structure with text. In addition, XML is human-readable and human-editable; protocol buffers, at least in their native format, are not. XML is also – to some extent – self-describing. A protocol buffer is only meaningful if you have the message definition (the .proto file). </blockquote>
<blockquote cite="#commentbody-7346">
<strong><a href="#comment-7346" rel="nofollow">thanasisk</a> :</strong>
<p>It is always nice to see Autonessus(yeap, I am old enough to remember that one!) Seccubus gaining more and more traction. ..In any case, keep up the good work Frank <img src="http://www.cupfighter.net/wp-includes/images/smilies/icon_smile.gif"; alt=":)" class="wp-smiley"/> </p>
</blockquote>
Thanks for your kind words
Frank Breedijk
I updated the post today:
<ul>
<li>Corrected some mistakes pointed out by <a href=http://twitter.com/ChrisJohnRiley rel="nofollow">Chris John Riley</a> and Elianne van der Kamp (Thanks!)</li>
<li>Added the missing &lt;severity&gt; property</li>
</ul>

vdbaan
I've created a Dradis upload plugin which supports IVIL.
The plugin can be found at http://dradisframework.org/community/index.php?topic=364.0

I believe that the sooner products adopt a schema, the sooner it can become a standard.
Robin
I like it. Not sure which of my tools it would integrate with at the moment but will consider it in the future for either importing or exporting data from things I write.

You need to remove the duplicate "During our initial call we came up with this initial version of the XML schema:" block in the write up above.
etd
We are trying to bring IVIL to Dradis, please contribute your thoughts:

http://dradisframework.org/community/index.php?topic=364.0
Stephen Haywood
I have written a python module for ivil files. I would welcome any feed back. You can find the code at http://averagesecurityguy.info/2011/02/21/ivil/
David Lodge
An interesting idea - I was thinking about doing something similar for non-proprietary tools that are normally hacked up in a couple of minutes.

I'd offer a couple of suggestions though:
* under , have a tag for
* the date and time should have a timezone attached to it

I may do a quick exporter for Nikto to IVIL.
Vasant Rao
I completely agree with the concept, but how different is IVIL from SCAP (specifically OVAL). OVAL language (schema) defines the representation of configuration information of systems for testing; the checks to conduct the analysis of the system for the presence of vulnerabilities, configuration issues, patch states ... and reporting the results of the assessment.

While the representation of configuration information and checks (inc vulnerability related plug-ins) may be propreitary to each configuration / vendor, the aim is to standardise the reporting or output of each tool.

Sorry I might have missed something about IVIL, so would be really interested in knowing why IVIL not SCAP ?
Jerome Athias
As mentioned in the U.S. "INTERNATIONAL STRATEGY FOR CYBERSPACE"[1] document,
we need "interoperable and secure technical standards, determined by technical experts".

I would like to introduce my vision of "Software Vulnerability Mitigation Automation"
via IVIL v1.0 via a (incomplete) Conceptual Map.

https://corevidence.com/research/vulnerability_interoperability_ivil_v1.jpg

(I extracted some links, please see below)



i = x2ivil + ivil2x
where "i" is interoperability and "x" a software (vulnerability scanner,... + waf, virtual patching system, ...)

What do you think?

Thank you.
Best regards,

Jerome Athias - NETpeas
VP, Director of Software Engineer
Palo Alto - Paris - Casablanca
http://www.netpeas.com

"The computer security is an art form. It's the ultimate martial art."



[1] http://www.whitehouse.gov/blog/2011/05/16/launching-us-international-strategy-cyberspace
ThreadFix http://code.google.com/p/threadfix/

Not Published

0/1000 characters
Go Top