Article by Felix Ryan, Co-author of Penetration Testing – published by BCS, The Chartered Institute for IT
It is far too easy to get caught up in the pursuit of “Best Practice” with any project, but at least with Penetration Testing, it is almost certainly better to not painstakingly strive towards the best, but to simply do “Good Practice”. Aside from the difficulty in achieving the best, the biggest reason to just aim for good, is that there is no time to waste in improving cyber security.
Penetration testing is a hard thing to get absolutely right, but when it's close it will either induce anxiety or instil a deep sense of calm. Those who end up anxious have discovered problems that not one of us would want to deal with when a real attacker is breathing down their virtual neck. For those organisations where anxiety doesn't hit, there is still no reason for them to be complacent, it just means they have the luxury of choosing how to take their security to the next level.
To be in with the greatest chance of having that luxury it is important to make the most of the penetration testing exercises that are available. I’ve had friends tell me before that their company doesn’t do penetration testing because of the “hefty price tag”. Ignoring the cost and impact of a breach for a moment, the lack of funds to pay for a large penetration testing exercise shouldn’t matter much at all. That’s because if you only have a very small penetration testing budget, it is still a budget and it can still be used to achieve something. The key is making the most of it and using good practice at every possible opportunity.
One of the most important ways to implement good practice in Penetration tests is to ensure that the test context is front and centre. Context is the biggest factor when considering the effectiveness of Penetration testing as it dictates everything from how the results are interpreted to the level of realism given to the test itself.
When thinking of penetration tests in terms of them being attacker simulations, the context can start to become a bit more apparent. When thinking of a simulation of a building it is easy to think of the context: what is the weather like; how old is the building; who are the people around the area; is it a tall sky-scraper or a sprawling mass of low-rise huts; is it designed to help educate children, or perhaps it houses criminals? All these qualities are fairly easy to bring to mind, and with a little guidance the same can be true for penetration tests.
First of all, don’t get carried away: this isn’t a discussion about Red Teaming – that is a whole different level of immersive simulation. Instead this is about a constrained exercise where one or more systems are targeted and the results analysed. As a general rule, it is worth considering a few key headlines of context: the organisation / industry; the technology; the attackers; the penetration tester; and the technical aspects of any vulnerabilities found.
Taking the technology as an example, it isn’t just a case of thinking about the type of technology in place, the languages used, and what supporting infrastructure is present. These things are all relevant to planning and executing a penetration test, but it may be that the volume of systems is key too. Best practice could well dictate that the penetration testing scope must include dozens of servers or the entirety of a large web application. Sometimes that just isn’t possible though, and instead the context of the technology should enable prioritisation, for example, so that Good Practice ensures that only the most important systems get tested this time round.
There is plenty of support and direction for organisations performing penetration tests out there, not least the book “Penetration Testing – A guide for business and IT managers” published by BCS, The Chartered Institute for IT - which covers this topic in chapter 11 and more in far greater depth. Other sources of help are available from organisations such as the NCSC, and as requirements for compliance to standards such as PCI-DSS or ISO 27001.
The second most important factor in penetration testing “Good Practice”, is the significance of thinking pragmatically about what the test is supposed to achieve and what is being tested. The most important factor though, is to not wait.
