It is important to understand while reading this, I am not an ASM SME...

The goal was to create a simple conversion of the Nessus Vulnerability Scan reports to import into ASM. The first step was figuring out what the scan results needed to look like.

So I exported the generic schema from ASM (13.0), which translates to:

<?xml version="1.0" ?>
<scanner_vulnerabilities>
 <vulnerability>
  <attack_type></attack_type>
  <name></name>
  <url></url>
  <parameter></parameter>
  <cookie></cookie>
  <threat></threat>
  <score></score>
  <severity></severity>
  <status></status>
  <opened></opened>
 </vulnerability>
</scanner_vulnerabilities>

That seems pretty simple, but thats a lot of attack types to map to some logic, so for now I will leave it generic.

The next step is to get a vulnerability scan of a vulnerable web application. I wont go into how to use Nessus here, but one of the export options is a ".nessus" which is just an XML file. There is actually too much data in this file, but you can leave it as is. If you want to read it you can remove the <Policy> sections because all we want are the Reports.  For this test, I ran a scan against google-gruyere.appspot.com, which is an unsecured app available to the internet.  Dont do this from AWS or someone will come looking for you, ask me how I know...

Example of results:

 <?xml version="1.0" ?>
<NessusClientData_v2>
  <Report name="ASMv2" xmlns:cm="http://www.nessus.org/cm">
    <ReportHost name="google-gruyere.appspot.com">
      <HostProperties>
        <tag name="HOST_END">Tue Aug 29 14:08:04 2017</tag>
        <tag name="LastUnauthenticatedResults">1504015684</tag>
        <tag name="Credentialed_Scan">false</tag>
        <tag name="policy-used">Advanced Scan</tag>
        <tag name="patch-summary-total-cves">16</tag>
        <tag name="cpe">cpe:/o:linux:linux_kernel</tag>
        <tag name="os">linux</tag>
        <tag name="cpe-2">cpe:/o:linux:linux_kernel:2.6</tag>
        <tag name="cpe-1">cpe:/o:linux:linux_kernel:2.4</tag>
        <tag name="cpe-0">cpe:/o:linux:linux_kernel:2.2</tag>
        <tag name="system-type">general-purpose</tag>
        <tag name="operating-system">Linux Kernel 2.2
Linux Kernel 2.4
Linux Kernel 2.6</tag>
        <tag name="traceroute-hop-0">?</tag>
        <tag name="host-ip">172.217.3.212</tag>
        <tag name="host-fqdn">google-gruyere.appspot.com</tag>
        <tag name="HOST_START">Tue Aug 29 13:21:20 2017</tag>
      </HostProperties>
      <ReportItem pluginFamily="CGI abuses" pluginID="39470" pluginName="CGI Generic Tests Timeout" port="443" protocol="tcp" severity="0" svc_name="www">
        <description>Some generic CGI tests ran out of time during the scan. The results may be incomplete.</description>
        <fname>torture_cgi_timeout.nasl</fname>
        <plugin_modification_date>2016/09/21</plugin_modification_date>
        <plugin_name>CGI Generic Tests Timeout</plugin_name>
        <plugin_publication_date>2009/06/19</plugin_publication_date>
        <plugin_type>summary</plugin_type>
        <risk_factor>None</risk_factor>
        <script_version>$Revision: 1.13 $</script_version>
        <solution>Consider increasing the 'maximum run time (minutes)' preference for the 'Web Applications Settings' in order to prevent the CGI scanning from timing out. Less ambitious 
  options could also be used, such as :
  - Test more that one parameter at a time per form :
    'Test all combinations of parameters' is much slower     than 'Test random pairs of parameters' or 'Test all     pairs of parameters (slow)'.
  - 'Stop after one flaw is found per web server (fastest)'     under 'Do not stop after the first flaw is found per web     page' is quicker than 'Look for all flaws (slowest)'.
  - In the Settings/Advanced menu, try reducing the value     for 'Max number of concurrent TCP sessions per host' or     'Max simultaneous checks per host'.</solution>
        <synopsis>Some generic CGI attacks ran out of time.</synopsis>
        <plugin_output>The following tests timed out without finding any flaw :
- XSS (on HTTP headers)
- blind SQL injection
- local file inclusion
- blind SQL injection (time based)
- unseen parameters
- directory traversal (extended test)
- directory traversal
- arbitrary command execution
- SQL injection (on HTTP headers)
- SQL injection

</plugin_output>
      </ReportItem> 

 

So far so good... Some of this will be a mess, but we can take a stab at it...

So lets mash it all together!

So how to tie it all together? There are some tools to help, online, I used to have on for Windows but I dont remember what its called, but I have a MAC now, so...

xsltproc ASM_Nessus.xsl Nessus_Scan.xml > ASM_Import.xml

 

FYI, for Windows users... https://www.microsoft.com/en-us/download/details.aspx?id=21714

Which gives me a pretty file to import to ASM. Its too big to post as text, but it looks like this:

 

Alright, so the final test, lets import to ASM...

Nice!

It could use some work around Attack Type mapping and Parameter mapping, but it looks like it works.

Well, thats as far as I got, I hope it helps someone. Now take it and run!

XSLT can be found on github:  https://github.com/Mikej81/NessusGenericASMSchema