Monthly Archives: March 2013

Dradis Framework workshop in BSides London 2013

Security Roots founder Daniel Martin will be delivering a workshop on Custom Dradis Framework plugins in this year’s BSides London 2013 event.

Attendees will learn how to create their own custom plugins to integrate Dradis with their existing tools and systems. If you have a suggestion for a plugin that we should create during the workshop please give us a shout: @dradisfw or @securityroots.

For those planing to attend, be advised:

Workshops will be booked on the day in a first come first basis. The format is small so to give the opportunity to get close and personal with a guru in the subject.

See the official workshop announcement:

There is a great lineup of workshops and talks (track 1 and track 2) this year, so don’t miss the opportunity to attend.

Dradis Professional is sponsoring the event so checkout our Dradis Pro & BSides London 2013 page for a chance to win a Dradis Pro license and future workshop updates.

Mapping external tool output to fit your reporting needs

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):

  1. Get scanner output
  2. Map to your own format / nomenclature
  3. 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:

Mapping external tool output with the Plugin Manager: from sample to template to result

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.


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.

Dradis Pro report templates and testing methodologies for download

Ever wanted to create your own Dradis Pro report templates but didn’t know where to start? Wait no more! A few days ago we introduced the Extras page. From there you can download report templates and testing methodologies. The idea is to showcase all the possibilities supported by our reporting engine and lay the ground work so our users can build on top of these templates.

The latest addition has been the OWASP Top 10 – 2013rc checklist. This covers the recently released OWASP Top 10 – 2013 release and contains 60 checks that you can use to test for all the issues in the new Top 10:

  • A1-Injection
  • A2–Broken Authentication and Session Management
  • A3–Cross-Site Scripting (XSS)
  • A4–Insecure Direct Object References
  • A5–Security Misconfiguration
  • A6–Sensitive Data Exposure
  • A7–Missing Function Level Access Control
  • A8-Cross-Site Request Forgery (CSRF)
  • A9-Using Components with Known Vulnerabilities
  • A10–Unvalidated Redirects and Forwards

Below is a list with a few examples of the Dradis Pro report templates (both Word and HTML) that you can find there:

Advanced Word example

Mix everything together: use Dradis notes for your conclusions, sort your findings by severity, filter, group, make use of document properties, etc.

Dradis Pro Advanced report template: a screenshot showing the advanced word report

A simple report to get you started

Never created a custom Dradis Pro report template before? No problem, start with this basic template to learn about the inner workings of the engine and in no time you’ll have your custom own report template up and running.

Dradis Pro Basic report template: a screenshot showing a detail of a table in the simple report template

A fancy HTML report

Dradis Pro supports a number of report formats including Word 2010 and HTML. In this case we show you how to create a fairly complex HTML report with the list of issues order by severity, a bit of JavaScript to auto-colour and auto-link external references and some awesome charts to nicely show the risk profile of the environment.

Dradis Pro HTML report template: a screenshot of the HTML report template showing a chart for all the issues

With the help of these samples, creating your own report template has never been easier. Are you ready to give Dradis Pro a try?