Nimble and Cost Effective Pentesting
It’s sometimes hard to make the case for cost effective penetration testing, often because organizations aren’t yet at a mature enough cyber security stage that a pentest will yield any real and measurable value. So first and foremost, it’s important to have other security processes in place before diving into what can be seen as a surgical strike to an infrastructure. If an organization’s asset and patch management aren’t in place, if regular automated security assessments aren’t part of the organization’s security posture, there is little benefit to a penetration test. The exception would be during the product development phase: in the case of software or hardware development, there is a good deal of value to be attained from engaging in pentesting in the late stages of development.
But let’s concentrate on a few ideas to create a more nimble and cost effective pentesting engagement. It’s a complex scenario, especially since we often anchor our beliefs on well known and established development paradigms - penetration testing however is a very different endeavor and perhaps we should strive to develop our very own and specific standard operational procedures - even from a cost/benefit (and opex and capex) perspective.
From my perspective, there are currently three main drivers racking up the cost of a pentest: skilled assessors, travel and lodging expenses, and lousy (business driven) operations around pentesting.
We can’t do much about the cost of a skilled assessor, as it’s a market driven number, but we can certainly play with it on the operations side and reduce costs.
Time is money (and in consulting you need to add 200% to that price tag), so let’s start by analyzing where that time goes:
The figures on the chart above are estimations, everything varies with the enviornment and scope, but after asking around it seems most of us spend around 50% of their time with Scanning and Enumeration, but lets define scanning as host discovery (your nmaps and unicorn scans) and enumeration as the analysis of those scans, identifying OS’s, services and versions, hostnames, management data (such as SMNP), and credential harvesting (valid user accounts and default/easy passwords).
Typically these tasks are done on-site, along with the exploitation. After that the team is sent back with all of their findings and they spend the remainder of the engagement writing the report.
This is where you close this page and you go back to browsing the internet: everything but the exploitation should be done remotely and even the exploitation, on a non-critical environment should be done remotely as well. Hear me out:
Concerns of data breach are not concerns: Consider that you’re sending the consultant back with documented findings for the report writing phase. So it bears the question: from a purely pragmatic stand point, why are you so concerned about data exfiltration or leaks during the assessment when you are letting the consultant leave with all the data on an encrypted hard drive?
There is a valid concern about accessing a remote system, but there are ways to minimize the risk:
Let’s assume that the consultant is using a dropbox scenario, where a computer is shipped to the client, plugged into the network(s), and the consultant then connects to the system:
- VPNs work great - most organizations already use these for all sorts of purposes, if you don’t trust it with a penetration test, then you can’t trust it at all.
- Multi-factor authentication is a great way to minimize risk, the more multi the better (password, hardware token and shared key, for example).
- Call back systems are a great way of making sure an attacker can’t use the same channel to even attempt a break in - the dropbox can be configure to connect back to the consultant every hour, for example.
- GPRS is far more ‘under the radar’ than plugging something directly to the internet: the dropbox can have a mobile connection as the only way to communicate with it from and to the outside world, as an added bonus everything recommended before can still work on a mobile connection. If it reeks of old-school dial-up modems - it should, only at 3G speeds, which for a console output is more than enough.
There’s more to the operational side that matters in terms of cost reduction: in my experience, consulting firms often send out two analysts, a relationship manger for a kickoff, and closing meeting, and whatever else they can throw in. We can play with that a little: do you need two senior pentesters for all tasks? Unlikely. We could use a Jr (or not) pentester for the discovery phase as running nmap should be second nature to any penetration tester, regardless of skill level; enumeration can be performed by a Sr Pentester and the Jr; Exploitation by both again, or maybe bring in another Sr to the mix and let the Jr move on to the next engagement. The relationship manager can participate via web conference - sorry, but unless there’s a business need for them to be there, they just shouldn’t - and if we’re trying to angle for recurring business that should be coming out of the sales business unit budget and not being charged to the client under the guise of a penetration test or security assessment.
I feel the Junior analyst is being brought in at the right times, trained on the job, and steadily on the path to becoming a Senior.
There are a few technicalities that need to be addressed:
Information sharing: working with remote teams is hard (I’ve been part of remote teams for the past 10 years, and the struggle is very real), but these days it’s really a question of skillset more than anything else:
- Leverage on Metasploit Pro features to share findings between analysts (from dynamic duo to a red team of 8… MSF Pro does a great job when used correctly)
- Gather your findings centrally (internal wikis are a quick and dirty way of accomplishing this - standard templates help a bunch; Faraday may come with a pricetag, but it works really well, albeit there will be a learning curve)
- Can I make the case for decent video-conferencing that is multi-platform, and full featured Instant Messaging? I might leave this open for a future rant about managing and being a part of virtual teams.
- Ultimately sharing information is about discipline and making it easy for the analysts to do so.
I’m working on a post about how I create dropboxes - it’s my way of doing it and your milage will vary, but if you’re new to all of it I hope it will guide you in the general direction of something that works for you.
Before closing this post: a quick shout out to the fellow pentesters that I bugged about how they do what they do :) Thank you.