We will model the results of a penetration test using network and application monitoring tools. The end result will be a dashboard showing you the vulnerabilities that still exist and the ones that have been remediated. This gives you a quick view of your vulnerabilities and the speed with which they’re resolved.

Penetration Testing these days is often done on a one-off basis, meaning companies do them once a month, once a quarter or once a year and then never think about them again. I find that to be a shame and think that penetration testing can be an invaluable tool in vulnerability management when performed properly.

One of my hobbies/passions/interests/whatever in the industry is finding a way to effectively operationalize security. That is, moving security out of the this is theoretically possibly realm and into the hey, we should fix this because it’s happening now realm. Part of this, I think, is finding a way to utilize the tools used by our compatriots in the network and applications management domains. This article will use two very popular (well… one very popular and one really-should-be popular) tools in the network monitoring and application monitoring spaces respectively. This will give us a way to display that the vulnerabilities from the report still exist as reported and measure the response/remediation time.

Tools Needed:
- Icinga (http://www.icinga.org – A fork of the popular Nagios (www.nagios.org) monitoring suite.
- Webinject (http://www.webinject.org) – A very powerful Perl script tool that allows you to build test cases for web applications.
- DVWA – Damn Vulnerable Web Application (http://www.randomstorm.com/dvwa-security-tool.php) – An intentionally naughty web application.
- A Linux operating system. I used Ubuntu 10.10 for everything, but you may use what you wish.

You will obviously need network connectivity between the machines and virtual machines are recommended for this exercise. You will also have to be able to talk to the web application on the desired ports (typically ports 80, 443).

Setting up these tools is beyond the scope of this article, but the installation documentation for all three tools is excellent, plus there are LiveCDs for two out of the three of them, so go ahead and get your environment set-up.

In our theoretical world, let’s pretend we just received a penetration test report that our web application (DVWA) has a weak password associated with it. For this example the login is admin/password. We begin by using Webinject to test that the login does indeed work. This is done by creating a testcase in Webinject language: see Listing 1.

LISTING 1:

The first test, cleverly given the id of ‘1’, verifies that the login.php page loads correctly, we want to be sure it’s there before we try to login to it. The second test then posts our username (admin) and our weak password to login.php and then verifies we can see the content behind the login. We can further extend this to test cases encompassing everything on our reports. SQL Injections, XSS bugs, etc., can all be modeled this way and monitored for. The beauty of using Webinject is it allows us to use it easily as a nagios/Icinga plugin. Simply add…

<reporttype>nagios</reporttype>

…to config.xml and you will get nagios/Icinga compatible output.

Now you could very easily be done at this point. You have some test cases to run that verifies the issues found in the report. You could put this in a cron job that emails you the status every couple of days and be perfectly happy. However, with a little more work you can integrate this verification with Icinga and then have a near real-time dashboard showing the status of your remediation efforts. This integration will do a few things for you, most importantly, it will provide some perspective on how much badness was really found during your penetration test. It will also add some accountability as you can break up the dashboard by responsible groups. This way the server administrators can see what is going on with the servers and the application team can see just the applications. Finally, it can provide some reporting for you on how fast vulnerabilities are getting resolved. This can be a powerful tool in your arsenal and it speaks the languages of your network and application teams, as well as, articulating the vulnerabilities to your security team while, providing metrics for your business team.

This article originally appeared in PenTest Magazine – April 2011