When I look back at the history of commercial consultancy-based pentesting I see two distinct forks in the road. The first happened around 2000, and the second happened around 2003. But I think another fork is about to crop up.Prior to 2000, commercial pentesting was almost exclusively focused on the external hacking of an organizations Internet visible assets. Basically, professional full-time consulting teams (which can probably be tracked back to 1994 if you push hard enough) were following a loose pentest methodology (still mostly portrayed as a dark art and only "learnable" via an authoritative mentor) - plugging away with vulnerability scanners and exploiting anything that came up - where the goal was break in, plant a few flags, and then tell the client what patches and system hardening they needed to catch up on. This core area of pentesting (which is still a distinct suit of offerings and consulting skills today) focuses upon OS and network-level vulnerability discovery and careful exploitation.
The first fork
By 2000 though, simply hacking an IIS or Apache server through an unpatched vulnerability or permissions flaw and throwing up a command script to "root" the server wasn't really cutting it to anymore for all these new Web applications. So, the first real "specialist" services started appear - focused upon assessing the custom Web application itself - independent of the hosting platform. To my mind, that was the first forking of the pentest track. Sure, there were still (and are) security code reviews (dissecting lines of code and hunting for bugs and vulnerabilities) - but I don't class that as "pentesting" as such, thats either auditing or security assessment.
That first fork led to entirely new pentesting methodologies, training regimes and certifications. But, more importantly, it also led to distinct consulting teams - rather than a specialized subset of network skills learned as part of being a pentester. Today, there's so much to learn in the field of Web Application pentesting that to keep at the top of the game you'll never realistically have time to deep-dive more classical OS and network based pentesting.
The second fork
The next fork that altered the fundamentals of pentesting occurred around 2003 with the advent (and requirement) for specialized reverse engineering skills to "black-box" hack a brand-new commercial software product. Around this time major software vendors were struggling in their battles against blackhat hackers and the full disclosure movement - even the news media was keeping count of the vulnerabilities - and customers were scared.
The solution came from specialist pentesting consulting organizations that had established a name (and reputation) based upon their ability to discover/disclose new vulnerabilities. It was a simple business model - find new bugs in all the software that prospective customers use, tell the media you found some bugs, get recognized by prospective customers as being "elite" pentesters, and turn the "prospective" in to "loyal" customers.
I identify 2003 as the year that specialized bug-hunting and security reverse engineering services started to appear as commercial consulting offerings, and the first real wide-spread traction as software vendors began to procure this specialized consulting.
The skill-sets are (again) quite unique of any other arm of pentesting. While knowledge of the other two pentesting regimes is valuable (e.g. Network/OS pentesting and Web Application pentesting), it takes a different mind and training to excel in the area of security reverse engineering. While you could argue that some of the best "classical" pentesters had many of the skills to find and exploit any new bugs that stumbled across during a client engagement - it wasn't until 2003 that these services really became commercial offerings and sales teams started to sell them.
The impending fork?
Which all leads me to point out a probable new folk in the pentesting path - specialist malware and its employment in pentesting. Why?
It seems to me that we've reached a time where formalized methodologies and compliance mandates have pretty much defined the practical bounds of commercial pentesting (Network/OS, Web application and Reverse Engineering), and yet there is a sizable security gap. And that gap firmly lies within the "prove it" camp of pentesting.
What I mean by that is, as any savvy pentester will tell their customer, the pentest is only as good as the consultant and the tools they used, and is only valid for the configuration tested and the date/time of testing. No guarantees or warranties are inferred, and it's a point in time test. And, on top of all that the scope of the pentest has typically been narrowly defined - which means that you end up with phrases like "system was out of scope...", "...not all patches were applied", "...not allowed to install tools on the compromised host", etc., appearing in the final reports handed to the customer.
But, with the greater adoption/deployment (and availability) of technologies such as IPS, firewalls, ADS, Web filtering, mail gateways, host-based protection, DLP, NAC, etc. and the growing strictness (and relevance) of compliance regulations, those classic limitations of pentesting methodologies leave vacant the "prove it" - prove that those technologies are really working and that the formal emergency response systems really do work.
This is where I think a new skill set, mindset and pentesting methodology is developing - and is an area which I expect to see develop in to commercial offerings this year.
Pentesting with malware
What I envision is the requirement for specialised security pentesting offerings that focus upon developing new "malware" and "delivery systems" designed to not only test the perimeter defenses of an enterprise, but also every layer of their security system in one go.
I don't think it's enough to say "drive-by-downloads are a fact of life and all it takes is one unpatched host to browse a dangerous site to infect our network. but that's OK because we have anomaly detection systems and DLP, and we'll stop them that way". Prove it!
Given the widespread availability of DIY malware creation kits, and the staggering array of tools that can pack, crypt, armour, obfuscate and bind a custom malware sample - and make it completely invisible to any anti-virus technology deployed within an enterprise - I expect that there will be a demand for pentesting to evolve and encompass the use of "live" malware as a core pentest consultancy offering.
For example, does the customers enterprise prevent users from browsing key-munged web sites (e.g. www.gooogle.com, intranet.enterpriise.com, etc.)? Which browser plugings are installed and not fully patched? Can malicious URL's and zipped malware make it through the mail gateways? Can the host-based security package detect keyloggers and network sniffers? If a malware package starts to scan and enumerate the local network from an "infected" host, is it detected, and how fast? What types of data can be exported from an infected host? Does compression and encryption of exported data get detected by the DLP solution? Does the malware have to be "proxy-aware" and require user authentication? Is out-of-hours activity detected from an "infected" host? Is it possible to "worm" through the enterprise network and "infect" or enumerate shared file systems and servers?
All of these questions, and many more, can be answered through the deployment of specialized malware creations and focused delivery techniques. The problem though is that this is an untapped fork in the pentesting road, requiring new mindsets - particularly with enterpise security teams.
The bad guys are already exploiting enterprises with custom malware, yet its generally taboo for consultancies to test security using similar methods. To my mind, that means that new pentesting specialization is now required to deliver the expertiese needed by enterprise business to really test their security from today's threat spectrum.
Malware pentest anyone?
I would call it less of a "malware" pentest and more of a "full scope" pentest using custom tools.
ReplyDeleteresult is the same, is network monitoring, system integrity monitoring, patching, etc being properly performed and can you actually catch and/or remove someone in your network.
its time to stop making pentesters only look at 1% of a network with a limited scope and calling that secure.
I agree that this could be a potential avenue for growth in the near future. I think the real shame is that as companies begin to have these "prove it" mentalities, the company suffers. With each specialization comes less people who are able to demostrate these types of attacks, thus, the consultants can charge more for their services.
ReplyDeleteIt is dissapointing that the IT departement won't just fix the problem, instead of "installing" a work around.
There's a fork coming, but it's not the one you've described. The "prove it" mentality is going away, and companies will demand more rigor in pentesting in terms of completeness and depth. For example, there's a world of difference between finding a few random XSS holes and verifying that the entire application properly uses context-sensitive output escaping to eliminate XSS forever.
ReplyDeleteDifferent organizations tend to use (and mix) different terminologies for pentesting. "Full scope" pentest is used by some boutique security consultancies, while the term "Security Assessment" is often used in Europe to encompass chained exploitation of systems that US markets would typify as pentesting - but also includes full breadth vulnerability assessment and patch auditing.
ReplyDeleteRegardless, what I'm really talking about are the specilization of skills within the pentesting domain and the demands for focused security consulting offerings around those skills. Specialized pentesting offerings traditionally begin with domain expertiese within a team of experts/consultants. Once that's become "established" and a market for those services has proven to exist (and be profitable over a longer term), you typically see specialized tools enter (often authored by the initial seed of pentest experts). That is an established model - just look at vulnerability scanners (such as Internet Security Systems scanner and Nesus - harking back to 1994), reverse engineering tools focused on bug-hunting (e.g. IDA Pro evolution), Web application scanners (AppScan, etc), and automated exploit packs like MetaSploit, Impact and Canvas extend those "pentesting" capabilities.
You could argue that tools such as MetaSploit have "malware" capabilities - and to a limited degree they do.
However, modern malware - both the agents in use and the techniques used to deliver them successfully - are a much more sophisticated beast requiring a different scope of expertise. Weapons grade "Malware" can be tamed by experts, and some of those experts can (and do) use it as part of a network-based pentest today - as a sideline. However, dedicated consulting offerings around the malware aspects haven't evolved to mainstream yet.
There is of course a fear to be overcome. "Malware" involkes quite a bit of shock and awe amongst corporate security teams - but then again so did chaining exploits to hack the backend database and sniff its network for passwords... this can be overcome. Extablishment of formalized consulting offerings (by malware experts) with exhaustive methodologies (that the customer can review and become comfortable with) are underway today - buy several boutique pentesting companies that led the way in "black-box" compiled application reverse eningeering. Hence the idea of the impending fork to mainstream offerings.
With regards to the "prove it" mentality going away - I would dispute that. Mainstream automated tools (i.e. in the Web/OS/Network vulnerability assessment market) go out of their way to "prove it" with every check they do - for reproducable results and false-positive elimination. Again, as specializations mature in to standalone pentest offerings, their methodologies become well established and more rigorous - that then make it much easier to build automated (commercial) tools that can conduct the pentesting activities on behalf of a semi-trained expert (or monkey as the 'real' experts would argue).
I'm inclined to argue that "malware" assessment/pentesing (or whatever flavor of security naming convention a particular global market uses) requires a seperation of pentesting skills with new levels of expertise - and that a commercial market for focused consulting offerings in that area are coming - rather than an ad hoc tweak to an existing network pentest methodology.