Tuesday, 5 June 2012

Weaponizing your pentest team... scaling :)

Unfortunately, I didn't get accepted at Auscert 2012. However, that is not a reason to keep all of my ramblings for myself...again :/

The idea of the talk was around improving/building up a pentest team... and to address some of today's pentest teams issues. It's one thing to complain, it's another thing to find solution... let's try to do both ;)

Disclaimer: since most of today's pentesting companies are doing a lot of web based test... this post is really web focused.

I don't want to do one huge post to avoid the "TL;DR" effect... so today I will be talking about scalability

One problem with how pentesting is currently done is that it doesn't scale, it can basically be resumed by:
  • one pentest - 2 testers
  • two pentests - 4 testers
  • three pentests - 6 testers
  • ... 
Hopefully some of the testing can be automated: 
  • network fingerprinting
  • web app fingerprinting
I think a good 70% of this can be automated. One of the first idea is to run automatically all the open source tools on the target(s) and put the results together. It's pretty easy to do and to script but I didn't see much people doing it.

I have been working on a POC based on eventmachine, rabbitMQ and sinatra. The problem is that it needs to be really tie to your reporting system (and I still don't know how to write the perfect reporting tools).

Another thing with reporting, is that so much time is wasted on copy/pasting thing... for example, a lot of pentesting companies have a word template and copy/paste issues from previous reports and after do all changes (even if old pentester will tell you to never do that to avoid "client A" name in "client B"'s report). This sucks big time as said before.

I think that most people writing (web) pentesting tools focus on the scanning (the fun) part of the job and don't address what a (web) pentest job is:
  • scoping 
  • fingerprinting
  • scanning
  • reporting
  • retesting
  • monitoring

This is how, in my opinion things should be done:

  1. during the scoping: someone visits the website in depth and provides a log of all the requests and pages. That way you can create real value and do your pricing based on real data (number of pages, privileges levels, forms, inputs, captcha, WAF,...). Too many people doing sales in this industry just have a quick look to a site and scope it using "magic".
  2. during the fingerprinting, an automatic tool used the scoping logs and scan the website to gather information. A tester reviews this information.
  3. during the testing, both tester and scanners use the data from the scoping and fingerprinting to scan the website and create a list of issues
  4. these issues are put together to build a report
  5. the testing should be done based on previous information and probably automated at 60%
  6. the monitoring is just another tool that used previous information to send alerts based on new exploit published: "This client was running Wordpress x.x.x, a vulnerability has been found in this product". That way you can provide a great  after-sales service :) I sent email to clients using Ruby on Rails after CVE-2012-2661 was published, they really enjoyed this kind of after-sales service...

As a side note, I'm a strong believer that the pentesting industry will probably more and more move to a real time vulnerabilities disclosure during pentest (with a lot of pros and cons, maybe for a next post), and automation will play a real important part in this new methodology :)


Anonymous said...

How often do you get to do 1-5 in that order?
I generally find it quite difficult to get scoping done correctly....

Louis Nyffenegger said...

Mostly depends on the client but the scoping is often not performed as correctly as it should be. Sometimes I only work with some design document, sometimes just few notes, sometimes I managed to get all accounts and details to properly visit the site.

It's already hard to get the information in time for the testing... so it's even harder for the scoping :/ Mostly depends on the person on the other side unfortunately...