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

The new Seccubus logo

Last month our coworker Frank Breedijk rechristened his vulnerability management tool Seccubus. Today he has launched his new website Seccubus.com

With the new website author Frank also unveiled the new logo for Seccubus drawn bij Schuberg Philis collegue Robert Heuvel.

Slide deck “Seccubus Confidence 2009.02 v0.1″