A color-coded guide to pen testing
The confusion around pen testing increases when you venture beyond the "simulated cyber-attack to evaluate the health of your security" basics and start digging deeper into different pen test methodologies and outcomes. Which is why I thought it might be useful to set out a color-coded guide to pentesting in an attempt to help clarify the situation...
Pentesting Knowledge is power
Before I start digging into the color-coding though, it's important to point out from the get-go that penetration testing alone does not promise to lift your organization into mythical 100% security territory. Nobody can guarantee that level of perfection in an imperfect world. What pen testing can do, however, is help in identifying and validating misassumptions regarding your security posture. By choosing the correct type of testing to best align with the sensitivity of the tested application or system your business will be better served when it comes to balancing risk be that costs vs. benefits or security vs. usability. Knowledge really is power, and there's a reason why cybersecurity is also called information security. Being better informed about not only the strengths, but weaknesses as well, of your systems helps build a better overall security strategy.
Which brings me nicely onto the small matter of being better informed about pen testing methodologies and the colors I keep referring to. There are three ‘boxes’ that you need to consider: black-box, white-box and grey-box. These ‘boxes’ can be defined as the classification of the level of information disclosed to the testers before an assignment begins. The pen testing devil really is in the detail; how much knowledge of the internal structure, algorithms, source code, level of access is disclosed to the testers will determine both how the test is approached and how the results can be interpreted and applied.
Sometimes referred to as crystal-box testing, white-box is so-called as the tester gets to see everything pretty clearly. The testers are given full information regarding the target system or application. This can include internal network topology, use case and actual source code in some cases. The important point being that a white-box testing operation demands full-disclosure of relevant information before it begins and co-operation from the company during it. While this might sound like a pretty poor way of 'testing' security, that's not so. In the real world, organized criminals and state sponsored actors have the time and resources to spend large amounts of both on attack reconnaissance and adopt a 'low and slow' approach to a targeted attack. A white-box approach simulates a completed reconnaissance phase, allowing the testers to look for vulnerabilities and attack vector much more efficiently. This level of collaboration between target (the company) and attacker (testing provider) makes for very effective, and cost-efficient, testing.
Black-box testing is the polar opposite of the white-box methodology, as you would expect. This means that the pentesters are effectively going in blind with virtually no information about the system disclosed beforehand. It is the most literal when it comes to replicating real-world attack modes, as neither the well-resourced criminal endeavor nor the average threat actor will have any prior inside knowledge of the target. It does, however, could lead to far greater engagement times for the testing (and so require bigger budgets), with as much as half of any pen-test exercise being consumed by the recon or discovery phase of the operation. It is very accurate in pinpointing those gaps in security processes that can be exploited by an attacker to both gain an initial foothold and move laterally across systems.
Have you guessed what grey-box testing is yet? Yep, that's right: a mix of both black and white methodologies. Grey-boxing falls somewhere, and quite where will depend upon the precise nature of the testing brief as determined by accurate goal alignment (and more of that in just a moment), between full disclosure and zero-knowledge. You might think that this just muddies the testing waters, but actually it can be very effective in mimicking the kind of knowledge levels that many threat actors might have if they have spent any time researching, foot-printing and accessing a system. Indeed, some shade of grey-box testing is probably the most commonly commissioned.
Eh? You never mentioned red before. Well, there's a reason for that. Red in the pentesting sense doesn't refer specifically to a knowledge disclosure scale per se, but rather a role-based one: it's the team that undertakes the testing. Red teaming is the most realistic of simulated attack modes that testers can bring to the security assessment party because it pretty much involves a team of ethical hackers using any means necessary to expose vulnerabilities across technologies, processes, people and even the physical realm of information security. The organization commissioning the test will give permission for the testing, and usually have a very specific objective for the red team to achieve but won't know precisely when or how it will happen.
What color is best for you?
Here's the thing: picking the right pentesting methodology for your business isn't as straightforward as just choosing a color. You need to align the right pentest type to your goals and your willingness to follow up on the test results, be that a simple management report establishing annual security system considerations or maybe an attack simulation to prove (or deny) that operations and security teams are ready for whatever threats come their way. Once you properly understand your goals you are better positioned to determine the correct pen test structure, and of the right shade, to meet those needs. Whatever colors best suit your requirements the result should paint a picture that helps map your route to a more mature, and lower risk, security strategy.
About the author:
Davey Winder is a veteran security journalist with three decades under his belt. The only three-time winner of the BT Security Journalist of the Year award, he was presented with the Enigma Award for a 'lifetime contribution to IT security journalism' in 2011. Currently contributing to Digital Health, Forbes, Infosecurity, PC Pro, SC Magazine and The Times (via Raconteur Special Reports) you can catch up with all his latest writings at www.happygeek.com