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.

Categories: Compliance, Vulnerabilities

Comments (3)

  1. SmithWill
    1

    Not to diminish the importance of penetration testing, but I believe this is one area of IT management that is SERIOUSLY OVER-HYPED! We’re really talking about patch management process.

     

    Let’s also not forget that we’re only dealing in the world of “known” flaws. There are numerous quite serious flaws that have been exploited in the past, and likey there will be more in the future, that laid dormant and undetected for years. What’s common to all exploits are threat vectors, conditions and the actions that actually cause disruptions. Risk is the product of a flaw plus a threat action. Pen-testing only identifies known conditions per the vendor’s signatures that exist at the time of the scan. It can’t identify compromise that already occured. It can’t identify device miss-configurations. It can’t identify abuse and misuse. It can’t identify subterfuge being perpetrated by the users of pen-testing software who may want to obfuscate their scam. Pen-testing is an important aspect to good managment processes but I hardly think it deserves an entire year discussion focus….unless you’re selling pen-testing services. :-)

     

    Administrators and company principals would be better off understanding how their IT resources are contributing to their bottom line (WAN utilization, communications security, data leakage, employee productivity, legal liability and so forth) versus one aspect to maintaining their software and equipment. Pen-testing is like regularly checking your tire pressure. How you drive your car and where is a tad more important in determining the outcome.

  2. Rob Hughes
    2

    I would agree to this statement to a certain extent, yes automated Pen-testing tools do rely on known signatures being added to the exploit and vulnerability databases.

    But this is not how a hacker works – and thus not how a Manual experianced Pen-tester works. Experianced people look for out of the box flaws and workarounds – such thing as race conditions etc that these automated tools cannot replicate.

    The Pen-test methodologies are fully aware of this, and if one completes a competant assignment based on for Example the OWASP testing checklist then these Manual type of checks are to be followed.

    The use of automated Pen-testing frameworks are limited and should not be used to replace an experianced Pen-testing team using Manual Methods and any CHECK, CREST accredited Company providing these Services will be fully aware of this.

    Basically, CORE, Immunity and Rapid7 will only perform half the Job for you – Pen-testing is a highly skilled area and much, much more involved than Patch Management.

    Rob Hughes

    Manageing Director,

    SentryCheck Ltd.

  3. Dolan McComb
    3

    I would agree with Rob, if you are looking for a PEN testing company to perform this service, you should focus on a company that goes above and beyond the “PEN TEST IN A BOX’ routine.

    Should a vulnerability be found, this will ultimately lead to patch management.

Comments are closed.