On the usefulness of Penetration Testing methodologies
Let’s imagine for a moment how the “bad guys” are planning their attacks. In the dark basement with cyber-punk posters covering the graffiti on the walls, with a bunch of half-assembled computers lying here and there, malicious hackers gather around the poorly lit table to decide what version of a Black Hat Attack Methodology to use in the upcoming criminal operation. Sounds absurd, right? Of course, because the attackers are not methodical.
As Penetration Testers, we see our main goal in testing our clients’ defences functionally in order to assess their ability to withstand a real world attack. Do we have to rely on external knowledge for that? Obviously, yes, it is impossible to know everything about every attack vector in 2016. Do we have to stick to a predefined set of instructions, a so called methodology? That depends.
If you are not a pentester, and yet you have to act as one, the use of methodologies is inevitable. To conduct a pentest yourself or to reproduce the results in the report from an external consultancy, you have to get your head around a methodology of some sort. In fact, this happens all the time: the perception in the market is such that anyone, be it an accounting firm or an IT audit practice, can do Penetration Tests: look at the plenty of methodologies out there!
But if you do pentesting for a living, do you really need Methodologies? I am a big fan of seeing a pentest as rather a mission than a project. Of course, a mission has to have a plan, but it rarely can be scripted in detail. It’s essential to have a recurring chain of acquiring, analyzing, and applying data and share it within the team. It’s very good to have both specialization and knowledge sharing between the team members. But to write down “what we do”, “what we do when we’re in”, “how we exfiltrate” in a static document? No, thanks.
To succeed at something we have to have good mental models and actual practical how-tos at our disposal. The models let us build the insight about how the attack would go and what we would have to do along the way. The how-tos and examples let us prepare for the actual operations: collect the data, apply or build the tools, make moves and get the proof of risk to the client’s business out there. The methodologies try to bridge the gap between the two for those who need it. Do you?