One of the challenges usually faced by information security teams during their day to day operations is trying to make sense of the diverse output produced by the different tools they need to use. Mapping external tool output into a format that is going to be useful for you is no small challenge. This is one of the reasons that we sometimes hear that well rounded security professionals should have a bit of sysadmin and also coding experience so they can quickly knock together a parser script or a concatenate a few greps and awks to parse tool output and produce information that is relevant to the task at hand.
The number of security tools is growing every year, and this is great. However, each tool provides its output in a slightly different format using slightly different labels (not so great). Even tools that are in the same space like Nessus, Nexpose or Qualys can’t agree on the best nomenclature to provide their findings on (e.g. Title vs. Name vs. Plugin Name). It makes sense as part of their commercial strategy to maintain a degree of differentiation by structuring the information in different ways. But that doesn’t help you.
There are several sides to this tool diversity problem: on the one hand you need to be able to make sense of all these heterogeneous output. On the other hand you need to collate, remove duplicates and adjust the information to produce a report that is valuable and accurate. You can do this by hand and repeat it for every project and tool combination or you can automate it.
As you can see, this type of mapping can be useful in a number of different scenarios.
The full fledged pentest or webapp assessment
In a full pentest or webapp assessment, you will be running a bunch of automated scans to complement your manual testing efforts.
Being able to upload tool output and getting it converted to the right format for the final report is going to save you a lot of time. On day one you’d kick a bunch of scans and forget about them. You’d then start manually testing the target system and following your own testing methodology. Ideally you’ll be adding your notes for the different issues and preparing the final report as you test along.
Once the scans have completed you can quickly process the output produced by the tool and map it to the nomenclature that you need in your report. Discard false positives and add a note to make sure you investigate in detail any real positives.
The vulnerability assessment (VA)
Not every client needs a full pentest every time. Take PCI compliance, there is a requirement to run quarterly VA scans. Most likely the client won’t be able to afford a pentest every quarter, but by reducing the scope of the testing to an automated vulnerability assessment, it is possible to achieve a degree of assurance without blowing up the budget.
In this less sophisticated vulnerability assessment jobs, you often need to run some scanners, triage false positives and produce a branded report. The goal is to reduce the time and effort it takes you to implement the full assessment (i.e. scanning + reporting) so you can offer the service at a competitive rate to your clients.
If you had an automated tool that lets you map between the output produced by the different scanners you use and the format your final report is going to be into, you could be saving yourself a lot of time. In this case there is no need for any manual testing (apart from the one required to discard false positives):
- Get scanner output
- Map to your own format / nomenclature
- Produce a branded deliverable
The Plugin Manager
It looks like either of the scenarios described above could benefit from some automation. This is why we introduced the Plugin Manager in Dradis Pro, a module that you can use to map external tool output into the format you need.
As usual there are many different ways to tackle the problem. We could define our own “schema” for the information and hard-code mappings between the different tools and our own nomenclature. Unfortunately, as perfectly captured by xkcd 927, nothing guarantees that our schema is going to be useful to everybody.
What we really needed was a way to let our users define their own schemas and map from external tool output to the schema they had defined. Company A needs to use Title, Risk, Description and Recommendation? That’s fine you can do it. Company B uses Issue, Impact, Probability, Description and Mitigation? Yes, we support that. Once you have agreed on your own representation for the information you can use the Plugin Manager to map between Nessus output and your own or between Qualys or Nexpose and your own. That is a lot of power right there. This is how it works:
First, for each of the tools we provide you with a sample of the output produced by the tool. Then you are able to define a template to map between the different fields provided by the tool and those that you need for your deliverables. In the example we are creating a template for Nessus issues. We want to extract the Plugin name, Description and Solution fields from Nessus and map them to Title, Description and Mitigation respectively. The template builder also has a live preview panel that lets you see the end result of your mapping to make sure everything is working as expected.
As you can see, this approach requires a bit of upfront investment (i.e. you have to create the mappings for the different tools you are going to use) but in return it gives you a lot of flexibility and saves you a significant amount of time. Mapping external tool output to fit your reporting needs has never been easier.
Conclusion
With the growing number of tools that made their way into the security tester’s arsenal, making sense of the different output formats in an effective way is becoming crucial skill. If adding a new tool to your methodology is going to mean that you have to spend more time manually mapping the output or collating information, you’re limiting yourself. Finding out a way to map between the different tool outputs and the format you need for your deliverables is a worthwhile investment.
