Do you want to better understand the different types of Pentests available on the market?
In this article, we will cover each type of penetration test, and explain at what time and context they are recommended.
What we need to keep in mind is that there are differences and more appropriate times for each of these tests, and they must be observed to have a better return on their results.
If you have questions about what it is and when to use each type of pentest, check out the guide we have prepared below.
Contextualizing different types of Pentest
To start talking about the types of pentests, we first need to understand the context of the tests and where they fit into a safe development process.
When it comes to secure development, one of the key features is that you need to focus on code security at each stage of the development cycle – not just at the end.
That is, during the development process, we thought to validate application security in several steps. This method aims to find problems at the beginning of an action.
However, when it comes to types of pentests, the scenario is changing a little: it has its specific moment to apply. In addition, it must be done carefully so that it is done correctly and at the right time.
Within the safe development process, we expect the types of pentests to be accomplished at two basic times. The first moment is in the testing phase, where we seek to identify runtime vulnerabilities.
And as we are still in the development process, we can say that this test can be a little more controlled.
We can also periodically test our currently active applications for vulnerabilities and focus on making a closer attack on the real one.
Although the two tests can be considered very similar, some things differ, such as focus and depth of analysis. Let’s see a little more about this below.
What are the Penetration Test phases
However different the types of pentests and their goals, there are a few steps that can be common to all tests.
We can put it as 5 basic steps, which we will describe a little better below.
1. Knowing the target
The first phase is the acknowledge phase, where the attacker seeks to discover information that can be used to perform the target attack. At this point the attacker will seek to understand and know which components are important and how they can be exploited.
At this stage we have no effective attack actions, and the search for relevant information that may facilitate penetration is predominant. For example, if there are any open source libraries being used, what might their vulnerabilities be?
Therefore, this phase is where the overall context of the target is understood.
2. Scanning the target
Now in this second phase, the attacker looks for more knowledge using scanning techniques and using a series of tools to obtain such information.
At this time, tools like nmap are widely used to map the target.
3. Accessing the target
With the information and mapping completed, it is time to seek to gain access to the target. And this is the third step of the pentest process.
Then, using the information that was gained in the previous phases, the attacker seeks to identify ways to perform the attack and gain access to it.
These access attempts may be, for example, in sending payloads to exploit some weaknesses that were previously identified.
For those unfamiliar with the term, payload is a data set specially crafted to exploit a vulnerability.
4. Maintaining Access
In the fourth step, we already have access, it’s time to maintain access because each system can have layers of protection that can prevent or even block the continuity of access.
In general, maintaining access may mean choosing to compromise a running process that is unlikely to be shut down, or even include in the application code any ports that can allow access whenever it is needed.
This step can be performed in different ways with each attack, it will depend on the moment and the type of application being tested. And that is why you should not just keep a layer of protection in the software to ensure its security.
5. Cover up our tracks
In the fifth and final step, we need to cover up our tracks. Therefore, at this stage, the attacker will seek to hide from his analysts and even tools his trail within the system or application.
In a real attack, this phase aims to remove any evidence that could identify that the system has been compromised. And that could be to rule out possible culpability from the attacker or even to maintain and secure access to the system.
There are several methodologies for structuring a penetration test. In our review, one of the best is delivered by OWASP in its OWASP – Web Application Penetration Test.
If we understand these five steps, which may vary due to the types of tests, we can proceed to understand what these types are and what the basic characteristics of each are.
But before we go into a more detailed description of each of the tests, we need to remember that each test has a specific focus and is often done by different teams with different backgrounds.
One of the most basic tests that can be performed on an application, or even on a network structure, is the so-called White Box test.
A White Box test performed for an application is usually run by a team of developers and aims to identify vulnerabilities that could be exploited in the event of information leakage.
This is because when executing a White Box Penetration attack, all information about the system is known, and this makes the attack much deeper.
And because the attacks are carried out by developers, and they have all the possible information about the application, the application security assessment is expected to be much more rigorous.
In general, this type of test is still performed with the application being developed, more precisely in the testing phase of the application.
Penetration test as part of the Development Cycle
Within the DevSecOps process, as shown in the image below, performing penetration testing is an important component of ensuring application security.
Within this development flow, we would have to perform an penetration test: in this case, White Box, which happens in the verify phase.
As we said, because we have full information about the internal structure of the application, test professionals can look for weaknesses in a deeper way.
This opportunity gives professionals the ability to identify and demonstrate application bugs, failures and vulnerabilities.
If you choose to hand this type of test to an outside company, one of the biggest points that may impact the process is communication.
The company that performs the test must be reliable: not only in terms of ownership of content or information but reliable in the knowledge and experience of its professionals.
As we have seen in the image above, this type of testing is highly integrable with the Software Development Lifecycle (SDLC) process, and when it is in fact tied to the development mat, it offers a number of security advantages as its end product.
Gray Box Penetration test
A test performed with Gray Box features is a test where the attacker can partially access the information, and it is necessary to explore from it to get more data and perform the attack.
This type of test is between the White Box and Black Box tests, so it can be considered a compromise in running the tests.
Generally, the client provides a detailed scope of what needs to be tested to ensure that professionals remain within the limits of what they want to test.
Gray Box tests are the most common tests in web applications, the vast majority of tests performed today fall into this category.
This is due to the degree of communication that exists between the testing company and the contracting company, as in some cases there is an exchange of information to clarify a doubt about a process within the scope of the test.
To perform this test, test cases can be designed based on an algorithm, knowledge of architectures, internal states, or other advanced descriptions of program behavior.
So, in general, we can say that Gray Box is a combination of the other two types of tests, and can add more and more with improved application protection and security controls.
Black Box Penetration test
Black Box tests, as we can already imagine, are tests performed almost without information. That’s because, in them, the attacker has little or no information about the target besides the name.
Therefore, this type of testing is much more common when the goal is to simulate an actual attack by an attacker. In this case, the goal is really to test the protective measures and controls.
Also, in this type of test, usually, the attacker will spend much more time than in the previous types. This is because the preparation and planning time must be longer and more careful.
In the recent past, Black Box tests were used a lot to show people the risks that applications were exposed for not being properly cared for.
Therefore, the scope must be very well defined, and the execution time must always be followed by the company that hires the test. After all, there are always risks involved for both the framework and other applications that may not be part of the initial scope of the test.
“Black” box, with visible results
However, because of the term “black”, some people get confused and give the term a more limited view, where little things end up appearing in the end result.
But this is not true, as this type of testing should always be done by experienced professionals with deep development knowledge. And besides, that they can use all their creativity to perform tests.
This can even be one of the most informative tests an application can pass.
As with previous types, Black Box penetration testing can and should be inserted into the development process and, as we speak, within its own time. That is, just before the actual release of the final product.
And if your application is already in production, you can also perform a Black Box test – even recommended.
What have we concluded?
Once we have understood the various types of pentests, and in which situations penetration tests should be performed, we can understand that there is no test more important than the other.
When we think of different types of pentests, we have to consider what the purpose, the scenario and the results we want to demonstrate with the tests. Thus, each test has its particularities and importance.
So the key is to understand which test is best to run at any given time. This insight comes with the experience and time of maturity of a development process.
There is no purpose in using a deeper test in an application that is known to be vulnerable, just as there is no purpose in conducting a more thorough test in a critical application that will be exposed to all external risks.
So what matters when choosing to do each test is that the person performing the test has the experience to get a good result. We have to be clear in our goal that when we perform these tests, we seek to be certain of the protection of our application.
In a nutshell: Delivering a Ferrari that you can’t drive is not a good choice.
Therefore, we must have the perception and knowledge necessary to adapt the test to the moment, and neither can make the other’s performance unfeasible.
That is: each of them has their moment!
What more can I do besides Pentest?
But it is important to remember that Pentest itself does not guarantee application security: it is a snapshot of how security is today. That is, if there is a deploy, it is already out of date. So Pentest is one of the security procedures that must be followed to make the application secure.Also important are SAST and DAST tests, Secure Code Review, and security training. That way, yours can build code more and more securely, making the security culture a habit from the ground up.
