Thursday, 31 May 2012

Reporting automation... more details...

When I first talked about reporting automation, I forgot to mention a major point. And since I have been "talking on twitter" about it with Dradis authors (If you have report automation issues you should totally check Dradis, it's pretty cool).

I didn't talk about: Information storage, i.e.: the way your issues and report is going to be stored. And that's in my opinion one of the most important point.

When you're a pentester, you're working:
  • off site in the office
  • on site for a week at a client's office, 
  • then you do a wireless test and spend a day without being connected to the network
  • then you setup a crazy network to MITM an iphone application and don't really want to break it
And in all these situations, you will need to be able to read and write issues...


When you're a pentester, your report:
  • need to be reviewed by a tech person
  • need to be reviewed by a business person 
  • and mostly you want your co-worker to write a good part of it ;)
All these situations create a really big problem of data synchronisation, especially when you're in a rush...

I often see people get a tech review of their issues write-up while they write the exec summary, then they copy/paste the changes from the review.

THAT'S JUST WRONG !!!

If your reporting solution is based on a single Word document or a centralised database... You just lost the productivity game...

Dradis solves this problem by allowing you to import sqlite databases to your current project... That's a good way to do it but there is so many things that can go wrong... Databases are not meant to be used for this kind of problems.

But you know who had the same problem for ages... developers and they came out with great tools like cvs, svn,... and git.


I picked git because it has off-line commits which allow you to work in any situation and that's really important in my opinion, you don't want to connect back to your network just to commit an issue.

So now, the problem of versioning is solved since git is meant to do that and to perform easy merge (or at least tell you when a merge doesn't work properly).

Now, some other advantages of git (shared with some other versioning tools):
  • more than one master repositories... you can have one for storage, one for backup, one for reporting and one for review for example. You can then push your changes to the storage's one and you can push some changes you want to be reviewed to the review's one. Same for the reporting.
  • you can have hooks. Basically you can be notified when something happens on your repository... so for example, you can have notifications on your review repositories that send an IRC message for the tech review and a jabber message for the business review
  • you can have hooks (again.), imagine you have a tool that built the report from your issues, you can get this report built every time you push to the reporting repositories.
  • you can have hooks (again..), you can run `aspell` on every issue when they are committed
  • you can have hooks (again...), imagine you create in your commit a file named 2crack and push it to a specific repository... a hook takes the file, (create a branch), and run your password cracking tools on it
  • you can have branches, you can create automatic script that will put their results in a git branch so you can review them and merge them if needed in your working repository. For example, you can run skipfish (with a 2skipfish file for example) through a hook and get its result in a skipfish branches then merge it back.

However, this method needs a way to store all information as text, hopefully languages like Mardown can be used they're simple and easy (compare to Latex)...

I hope these details give you a better understanding on why I'm so unhappy to use Word to write Security reports.

Report should be seen as a process not just a result...   ;)





No comments: