The MSS: settings used to be here...

I recently got involved in a project where I defined the Baseline Security settings for windows and Linux. I used the settings provided by the Center for Internet Security (CIS).

We decided on the following approach:

• Based on the CIS templates we created a baseline document specific to our company
• I, in my security role, created a Nessus .audit file, so we could audit compliance to our own baseline with Seccubus
• The windows administrator created GPOs to apply the settings.

When creating in the GPOs we did a strange discovery. In a windows the settings that are normally marked as MSS: in the category Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options do not appear in a domain if its functional level is Windows 2008.

This made us wonder, have these setting become irrelevant ? If this is not the case, how can we still set them, preferably via group policy?

The settings are not irrelevant, as e.g. Peter van Eeckhoutte’s blog points out. Windows 2008 does not forward IPv4 packets that have source routing on them,  but it does accept them if the machine is the final destination. However for IPv6 Windows 2008 will forward these packets by default.

So if the settings are not irrelevant, how can we apply them if they are not in the Group Policy Editor? For this purpose we created an .adm file, which can be loaded into the Group Policy editor as a Classic Administrative template.

All the MSS settings can be controlled with this Administrative template. When we applied these settings we reached our desired compliancy with our own baselines.

Mission Accomplished!

So what are these MSS setting and what do they do?

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″

On the 19th of November Frank Breedijk announced that Jason Mansfield, who runs the website http:/clinicallyawasome.com, has won the contest by sending in the name Seccubus. A bottle of Vueve Clinquot champaing will be sent to him shortly.

The author has provided the following explanation of the name Seccubus:

Seccubus is a mythical creature that helps security professionals analyze and report the results of, repeated, vulnerability scans. Like its distant cousins the Succubus and Incubus the Seccubus is also a creature of the night. At night, or any other scheduled time, the Seccubus draws its energy from repeatedly performing vulnerability scans  of infrastructures until the vulnerabilities become exhausted or die.
The Inseccubus is the male counterpart of the Seccubus. While the Inseccubus draws his life energy from the assessor by repeatedly requiring him to (re-)analyse the same findings, the Seccubus get her energy from pleasing the assessor by reducing the number of findings by means of delta reporting.

The name Seccubus was chosen from a list of over 50 ideas sent after the contest was announced via the AutoNessus.com website, Hacker Public Radio, Paul dot com and various other social media outlets like Twitter, Facebook and LinkedIn.

“I wanted a name that was completely different from AutoNessus” said Frank Breedijk, explaining why suggestions like AutoVAS and AutoVAMP where turned down. Other suggestions where turned down because their name was already taken on media like twitter (e.g. VAsak, Vulnerability Assessment Swiss Army Knife) or “simply because I didn’t like them” (e.g. Mick Douglass is awesome).

Now that the new name has been announced the “rebranding” will be complete before the end of the year. The website www.seccubus.com is already live but still points to the AutoNessus.com site. Also Frank’s twitter account, @autonessus, will be renamed to @seccubus soon.

The response to the renaming contest was overwhelming and we would like to thank everybody who participated.