By Nick Selby (Managing Director,
Trident Risk Management)
Vulnerability assessment vendor Rapid7
has announced the first of a series of steps to integrate its
penetration testing and vulnerability assessment scanning products. The
first step is a module that allows users of the Metasploit Framework,
which Rapid7 acquired in October to natively import NeXpose scanner results and then take automated action against vulnerabilities MSF is capable of attacking.
This is not the forum for a discussion of product news. But the
integration, modest as it currently is, speaks to some high level
trends in the penetration testing space that I feel are of continuing
interest to businesses that currently perform or are considering
setting up the capability to perform penetration tests using an
internal pen test team.
In a nutshell, users of MSF 3.3.1 console and NeXpose can control
the latter from the former, start a scan, import into MSF and
cross-reference available exploits to the results of the scan, then
automatically exploit the matching vulnerabilities.
Obviously as a console-only product, the update to MSF is going
to be first used by pen testers who know how to get their luggage off
the carousel without a red-cap. It must be said that the functionality
is not unlike that offered for some time from Immunity Security‘s Canvas, D Square Security and Tenable’s Nessus and other scanning products, and indeed by importing into Core Impact
the results of scans from a range of vulnerability assessment scanners
including Nessus, Lumension PatchLink Scan, Nmap, IBM ISS, nCircle
IP360 and Qualys QualysGuard. With the integration, and the automation
which I understand is going to be continually enhanced, the industry is
moving towards some interesting places rapidly.
Penetration Testing Has Left The Lab
This is an indication that Rapid7 is indeed aggressively pursuing
integration and professionalization of its MSF assets. This definitely
means that there will be three enterprise-class pen test frameworks
sometime within 2010 or 2011. That’s big news.
In 2006, I wrote a report
outlining the fact that penetration testing was moving closer to
mainstream enterprise respectability. Today, many organizations still
view pen-testing as some kind of magical hocus-pocus. But a range of
issues has changed this. The Payment Card Industry Data Security
Standard, something I have railed against for some time, has been (I grudgingly admit) useful in its insistence
on pen testing both networks and applications and their controls and
processes, from within and from outside the network, by internal and
external teams. This has created, for better or worse, a far more broad
awareness of the need to perform penetration testing.
Since You’re Doing It Anyway…
If PCI is going to force firms to pen test, that means there’s budget
to pen test. And if you’re going to spend money because you’re forced
to, you might as well get some actual security benefit from doing so.
There are strong drivers to train people to do penetration testing as
part of an internal team. A couple of them include:
- Reducing the amount of work that consultants have to perform
A well-trained internal pen-test team can periodically run checks
against low-hanging fruit and reduce the scope of work that external
pen-testing teams need do – that is, let your contracted experts
concentrate on the hard and really important stuff; - Raising the level of discourse between internal and external teams
If you’ve got smart people getting smart about pen-testing, chances are
they’ll be better poised to understand the findings that an external
team brings back from a test; - Finding Broken Stuff
A more regular look at what you have, performed responsibly and under
adult supervision, is likely to turn up more broken applications and
processes than any spot-check or quarterly scan will; - Validating Vulnerability Scans
Ever wonder whether that laundry list of things kicked out by your
vulnerability scanning software or service is giving you accurate
information – that is to say, that the things it says are vulnerable
actually are? Banging on them is a good way to see if they are
exploitable, and get a better understanding of what is and what is not;
which could lead to - Re-prioritizing Vulnerability and Patch Management
Rather than simply addressing everything that your scanner calls high
and critical, a new approach would be to re-prioritize a given
vulnerability based on business risk. This leads inevitably to; - Using Vulnerability Management For More Than Security My partner Paul Davis,
who managed security for very large organizations including General
Motors, runs vulnerability scans regularly to create metrics that
improve overall operational efficiency. By regularly scanning
correctly, one can enforce a methodology that ensures servers and
applications are set up in a secure manner, and increased awareness of
rogue or vulnerable servers popping up on the network. SLAs would
improve, outages are reduced, fewer security incidents,
misconfiguration incidents or virus outbreaks. This transcends security
and allows vulnerability scanning to become an IT QA tool
Converged Pen-Tests
As the tools get better on the network side, end user customers must be
better aware of the trends around holistic or converged penetration
tests, to provide more realistic attack information. This is an area in
which my company, Trident Risk Management has a vested interest, so lest this devolve into a white paper, I will merely state our position.
Our enemies do not segregate their attack resources between physical
and logical domains, and you as an organization should not segregate
your defense resources. Counter-social engineering training and
awareness and testing, and physical penetration tests combined with
logical ones and other means of providing realistic security testing
should be considered by organizations wishing to truly understand their
security posture.
What All This Means
I regularly run a track at IANS conferences
on establishing internal penetration testing capabilities. This is not
about the tools, really, it’s about the process and logistics of doing
it. [1]
The level of interest in this subject is rising, in companies large and
small. Because more people who’ve never done this before will be trying
to do it in 2010, the vendors of penetration testing frameworks like
Core, Immunity and Rapid7 will be offering better automation, better
and more meaningful integration with enterprise security tools, better
metrics and reports, and more ways to interact with the pen test
products themselves. They’ll become easier to use.
Here are a few near to mid-term changes to expect in the industry as a whole, from all the vendors within it:
- The use cases will be more clear Right now
getting use cases to allow internal penetration testing is still tough,
and even though the value proposition is clear to security
professionals (“You think it’s secure? Really? Want to find out?”), it
still needs explaining at the C-suite. Vendors and people like us will
have to help customers understand how to explain the value in business
terms; - The Use Cases Will be More Compelling
Amateur or inexperienced pen-testers are filled with glee when they get
root on a box (W00T!!), but business leaders need to see and feel
viscerally the results of a pen-test and how security (or bad security)
affects business and effects the bottom line; - Metrics Must be More Realistic
– For example, perhaps there will be metrics speaking to
exploitability, either through ease or availability of an exploit, or
something like that – I am not authoring or suggesting the metric, just that there may be one; - Quality Assurance Will Get Even More Important
QA is already very very important, but with an increase in people
banging on software, it will become even more critical that the vendors
ensure that exploits behave as expected. For Core and Immunity, this is
already a professionalized process and a selling point. For Metasploit,
it will be more challenging. It has hired an additional exploit writer,
raising to three the number of people who do QA – this is clearly not
enough, and this is a key part of the Rapid7 integration plan for
Metasploit; - A Better Public Exploit Database is Needed
Currently there are databases of exploits and of vulnerabilities;
without going into enough specifics to derail this conversation by
irritating security researchers’ passions, suffice it to say that
improvement of the way the community shares information on available
exploits is a topic of great interest to researchers and incalculable
value to the community as a whole. Having said that; - Disclosure Policies Must Become More Transparent
With more companies using penetration testing frameworks, pen-test
framework vendors will be held to an increasingly high standard. Their
behavior, especially around areas like disclosure, sales of 0days, and
whom they sell to, will become increasingly of interest to their
customers; - Usage Policies Must Be Refined
With vendor support behind a powerful and free product, who uses MSF
and how they use it must be better defined, at least conforming to the
de facto industry standards set by Core and Immunity. With Rapid7
standing behind MSF, it is only a matter of time before this is tested
in court in the form of an enterprise, damaged by a MSF-launched
exploit, sueing Rapid7. I won’t speak to the eventual success of such a
suit (I am so not a lawyer), just that it will happen – and
when it does it will be costly, time consuming, and potentially
hazardous for the industry as a whole should some precedent be set; - More Consistent and Better Reporting Is Coming
This does not mean simply more automated reports taking up reams of PDF
files, but rather that with the enhancement of integration between
scanners and pen test frameworks from all the vendors, better
automation of attacks and post-exploit management and workflow, and
more accurate risk-related metrics, users will be able to create
better, more business-relevant reports.
As I’ve said before, this is a great time to be a customer in the penetration testing market.
[1] – The talk itself is a hodgepodge started by a presentation on the subject given by Craig Balding last March at the eCrime Congress
in London. I borrowed (with permission and much gracious help and input
from Craig) the format and then started building up slides and a
schtick around it – it’s had input from several vendors, about 400
attendees, and IANS faculty and security professionals including Paul
Davis, Josh Corman, Will Gragido, Randy Sabbett and others.
