Vulnerability Scanning vs Penetration Testing: Part 2

After the explanation of the differences between vulnerability scanning and penetration testing in part 1 of this short series you recognize that your organization needs a penetration test. Next step is to determine what type of penetration testing exactly is required. Do you need a web application or a network penetration test? Should it be black box or white box? What is a red team engagement? Choosing to have a penetration test done is only the tip of the iceberg and our goal in this article is to help clarify what the different major testing methodologies are so that you can choose the best one to match your organization’s security goals.

Penetration Testing Methodologies & Scope

When looking at the different types of penetration testing there are two parts that need to be considered: methodology and scope. The first determines what exact type of penetration test will be performed – where the different types are primarily differentiated by the amount of information provided to the tester at the outset. The second breaks down the scope of the penetration test which can vary by what is being examined: Will it be limited to just web applications? Will the network be involved? Should the server software be included? Would DDoS be allowed for testing? In today’s article I will focus on the main types of penetration testing techniques, and in a future article we will go into the issue of scope.

Different Types of Penetration Testing: “Boxes”

The three main types of penetration testing are often referred to as “Black Box”, “Grey Box”, and “White Box”. A different set of information about the IT infrastructure to be tested is provided to the tester in each of these, simulating the different types of attack which might be perpetrated by a malicious actor. The choice of which “Box” to use will be driven by the type of information the test is intended to reveal.

Black Box Testing

“Black box” is a term used through programming and engineering to depict a situation in which you know what goes in and what goes out but have no information about what happens within the box. For example, let’s look at a car. The average driver knows that a step on the accelerator (gas pedal) accelerates the car, however, they do not know exactly what sequence of events causes acceleration (black box). What is known is that the input, stepping on the accelerator, provides the output of acceleration.

Similarly, in black box penetration testing all that is known to the tester is the target IP’s, domains, and/or applications that they can attack. It is up to the penetration tester to use their own ingenuity and resources to determine specifics about the target such as the operating system, open ports, possibly undefended resources, etc. This type of penetration test is most analogous to a real-world malicious actor attempting to break into your organization. A malicious actor will only know what they can publicly find or derive via scanning tools and base their attack on that information.

While this covers the most common scenario, it does have the downside of missing anything that could be derived from an insider threat or any information that a malicious actor may find that the penetration tester cannot for whatever reason. To account for the possibility that a malicious actor may have more information & resources available than thought possible – think i.e. state sponsored hacking – there are two more methodologies of penetration testing.

White Box Testing

The idea of a white box is meant to be the exact opposite of a black box: the tester can see every single internal working of the “box” that leads to an output. In terms of our vehicle acceleration analogy above, it’s more like a bicycle than it is a car engine. When you turn the pedal on a bicycle you can see the chain and the gears interacting which lets you see exactly how it is accelerated. In the same vein a white box penetration test is one in which the penetration tester has full access to the IT infrastructure source code, system architecture, and even internal security controls before beginning the penetration test. This allows the testers to perform a faster penetration test because they don’t have to wait for i.e. port scans to finish – instead they have that information available already. Similarly, the penetration tester does not have to gain access to an organization’s network via an exploit in order to find internal security controls that are lacking. The largest advantage of a white box test is that a penetration test is more likely to uncover problems than in a black box penetration test. Consequently, the resulting report will be more detailed which will allow an organization to have the greatest opportunity for improvement to its security posture.

Grey Box Testing

As the name implies, grey box testing is meant to combine the ideas from both black box testing and white box testing in a middle ground that uses aspects of both methodologies. Most often, this is achieved by providing the penetration tester limited information about the inner workings – i.e. by giving access to system architecture diagrams and possibly even source code for perusal. The idea here is to give the penetration tester knowledge that will allow them to target their attacks from the beginning like in a white box test, but still attack the organization from outside in a manner like a malicious external actor would. By utilizing diagrams and source code the tester can pinpoint the most likely weaknesses and get started on manually attacking those even while the automated scans a black box test uses are running concurrently.

Which Box Is Right for Me?

There is no one methodology that fits all organizations, as it is largely dependent on an organization’s individual security goals and requirements by security standards such as ISO 27001 or contract partners. To pick the appropriate methodology you need to determine what the goal of the penetration test is. If it’s simply to meet a contractual obligation, you may elect for a grey or black box test as it will most closely simulate an external actor.  Unless the penetration tester can breach the perimeter, it will keep the list of fixes potentially required to a manageable amount. On the other hand, if your goal is to be as secure as possible no matter the work required to fix potential issues, you may elect for a white box test or a grey box test with source code analysis included. Here, the list of findings can result in a much longer list of fixes required and include various internal mechanisms that need to be addressed.

In the next article we will address different scopes of penetration tests in relation to the methodologies and how both, the scope and methodology chosen can influence time and investment.

Tags: , ,
Previous Post

Cybersecurity Risks in The Healthcare Sector

Next Post

Vulnerability Scans vs. Penetration Testing: Part 1