Defence In Depth Penetration Testing

Never before has it been more important to think the unthinkable: what if an attack succeeds? (If you need some stats and arguments to persuade the Board of this, try this article of mine, of which this is a summary.) The solution to mitigate the threat of a successful attack is already very familiar to us all: defence in depth. But to what extent are those inner defences tested? What about a “second-level” penetration test, which would start from the assumption that a first-level defence has been bypassed?

Beyond a few run-of-the-mill scenarios, this type of penetration test is not widely considered – at least not that I’ve seen in the UK. First, let’s be honest, the reality is that such testing is often not required to tick the boxes necessary to achieve the minimum level of legal and regulatory compliance. Second, penetration tests are traditionally categorised by the amount of knowledge the tester has of the target system – for example, “white box” versus “black box”. (The OSSTMM also considers the level of knowledge the target has about the test.) Then we have the generic “external” versus “internal” test, which both carry assumptions about the initial level of access. For the external test, it’s usually zero or credentials have been supplied or an IP address has been white-listed. For the internal test, it’s implicit that the tester has physical (or virtual) access to the system (and possibly credentials to go with it).

There’s no reason, however, why a pen-test could not start from a more adventurous position of access. Consider, for example, the scenario of a compromised web server on which a web shell has been dropped – or indeed a SQL shell! A second-level penetration test could start with this in place for the tester to see what access could be achieved should such an initial attack ever succeed. This would obviously require careful configuration so that the web shell would only be accessible to the tester but this could be done quite simply.

So let’s make the level of initial access more of a variable in pen-tests and get creative. Think about various attack scenarios and what, if anything, is in place to thwart them should the first line of defence be breached. These can form the basis of scopes for further penetration tests and will really help an organisation to move forward with its security – in particular, preparing for and reacting to successful attacks.

Do add a comment if you’re in a company that has done this (well done you) or perhaps you’re a pen-tester that’s performed such a test (interested to know the scenario).

2 thoughts on “Defence In Depth Penetration Testing

  1. 2cents

    My 2 cents:

    Pen tests (in the way they are typically handled) are useless. Vulnerabilities are dealt with on a case by case basis rather than highlighting the systemic flaws within a system/network.

    Consider the scenario:
    Web facing box compromised via Tomcat, jump to backed db box, elevate privilege with default sa account, gain access to system with xp_cmdshell, steal domain creds, compromise domain.

    Report:
    Patch tomcat, disable sa account, turn off xp_cmd shell, done.

    This is one attack path taken care of but the systemic flaws in the network still remain. Next pentest, similar report comes out again.

    The actual “fixes” to the systemic issues require effort, explanation and time – insufficient patching procedures, no DMZ, different domain/trusts between DMZ domain/internal domain, Insufficient domain password policies, etc. None of which most pen testers can offer or have the skills to offer these days.

    Pen tests only make up a small offering in the overall scheme of things IMHO.

    Reply
    1. Jerome Post author

      Thanks for the comments. I agree with you that pen-tests should be just one element in an overall process but I’d add that pen-tests aren’t meant to find systemic flaws in a comprehensive fashion – that should be the job of architecture reviews, etc. Some organisations see pen-tests as validating their entire set-up, which is of course unrealistic. In the relatively short period of time a pen-tester is given, that’s just impossible, which is why a pen-test has a scope, with a well-defined target area. I agree that a good pen-test report should take the wider view and pick up on architectural weaknesses where the test results have proven such a flaw. That’s the difference between a customised report and a copy-and-paste job from the output of [insert_tool_of_choice].

      Reply

Leave a Reply to Jerome Cancel reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>