The differences between a red teaming and a penetration test
Red teaming is an offensive cybersecurity testing method. By means of a realistic attack simulation, we test the cyber resilience of an organization against an advanced attacker. The terms red teaming and penetration testing are used interchangeably with some regularity. The two techniques show several similarities, but there are also a number of crucial differences that make these instruments not interchangeable. It is therefore important to understand the difference and which technique you can best use to increase your level of resilience.
The framework of the National Institute of Standards and Technology (NIST) can be used to indicate the difference between a red teaming and a penetration test. This organization categorizes activities for increasing cyber resilience into five so-called functions.
Although the framework focuses on cybersecurity, a parallel can be drawn with physical security. In order to make the framework more tangible, it has been applied to the physical security of a bank in the table below.
Each of these actions aims to contribute to the bank's resilience against an attacker. As such, it is important to test whether these actions actually have the desired effect. When you look at techniques to test the effectiveness of the various actions, the difference between a red teaming and a penetration test becomes more clear.
Penetration tests generally have a more limited scope than red teaming. For example, a penetration test looks at technical vulnerabilities in individual applications, specific network segments or the internal network. Red teaming uses a holistic approach where, to a certain extent, all possible ways to achieve a goal can be used. Think of physically entering offices to gain access to the internal network or using keyloggers to retrieve passwords. But also the fact that the entire internal network and Cloud systems can be targeted. A red teaming does not work from a scope determined by the organization, but from an objective defined by an attacker. To achieve that objective, attack paths can be used that the organization itself has not thought about. With regard to the physical security of the bank, the conclusion can, for example, be that:
- The greatest risk for the money lies not in the storage but in the transport.
- The weakness of the safe lies not in the construction of the safe itself, but in the way in which the access code is stored.
- The safe is left open unattended for a period of time each day while the money is being loaded and unloaded.
A red teaming tests the effectiveness of the activities from the Identify function, which are largely disregarded in a penetration test.
A red teaming is a simulation of a realistic attacker with a specific objective. While there are always multiple ways to achieve this objective, a real attacker only needs to take one of these. A penetration test is aimed at exposing as many vulnerabilities as possible within the scope in order to be able to close them. For example, when the bank's safe is attacked as part of a red teaming, the fact that the access code can be guessed based on wear and tear on the keys can be abused. The red team will then focus on removing the money in the safe undetected. In the case of a penetration test, we will continue to look for other possibilities to enter the safe. For example, the pentesters come to the conclusion that disconnecting the power supply automatically opens the safe. The penetration test thus revealed two vulnerabilities of the vault, where the red teaming only came to one. Within the Protect function, a penetration test therefore offers more depth than a red teaming.
A red teaming project is secret from the blue team (the SOC analysts). The red team (the hackers) tries to penetrate the organization in an unobtrusive way. The blue team will have to track down the attack in their network, just like they would in case of a real attack. Although a penetration test can also provide data about attacking techniques, this data does not give a realistic view on the detection capabilities because a pentester does not hide. If the motion sensor in the safe is not activated during a penetration test, this provides information about the sensor malfunction. However, when it goes off, it does not provide any information about its effectiveness, as the pentesters were not bypassing the sensor. When the sensor goes off during a red teaming, this is a good indication of the effectiveness, because the red team is deliberately trying to remain unseen. Red teaming therefore puts the detection capabilities to the test in a realistic manner.
As an extension of the Detect function, the Respond function is also realistically tested with a red teaming. After detection has taken place, the blue team has the task of removing the red team from the network. The red team will take actions to prevent them from losing access to the network, such as installing backdoors. Such actions are not part of a penetration test and removing penetration testers from the network will probably not be appreciated. For example, in the example of the bank, with a red teaming it can be found that the guard does not arrive fast enough at the safe to stop the attack. A penetration test will not come to this conclusion. Red teaming is therefore also the right choice for testing response capacities.
In this respect there are no differences between a red teaming and a penetration test. Both are unsuitable for testing the measures from the Recover function. A technique such as a cyber crisis simulation can be used for this.
A red teaming and a penetration test are two different instruments that can both contribute to increasing the cyber resilience level of an organization. They both serve their own purpose and one is not a replacement for the other. A penetration test helps in an efficient way to close as many specific holes as possible. A red teaming is aimed at verifying whether the total set of security measures taken provides adequate protection against a real attacker.