Red teams and how they protect your business - part 1

In today’s increasingly digitized world, it is easy to think that security is only about protection against IT attacks and data breaches. To meet the threat landscape and the advanced methods of threat actors, traditional penetration tests alone are no longer enough. An important part of the security work is to test the organization from several different combined attack angles.

Red team testing is a method used to evaluate the security of the organization by simulating the attack methods of the threat actors. By using the various techniques and tactics that threat actors have historically been proven to use, the organization can identify gaps in its security and take steps to ensure that these gaps are addressed. Basalt offers tests in several different areas and these tests can be combined according to the customer’s wishes. When several of these individual types of testing are combined, such as physical penetration testing, infrastructure testing, and social engineering, this begins to resemble red team testing.

The financial sector is one step ahead

The red team process is described in several different frameworks, where TIBER-EU is a framework for the financial sector in the EU, and it is the first red team framework that has been implemented in Sweden through the National bank (TIBER-SE). This framework is already today a requirement when conducting red team tests in the banking system and has a clearly defined workflow. The financial sector is often early on with good cyber security, and the rest of the business is likely to follow this development.

Combined attack vectors and intelligence gathering

The testers scope of allowed methods and allocated time is expanded in red team tests and more attack vectors can therefore be used, combined and exploited to achieve maximum penetration in the organization. In regular penetration tests, a significantly smaller percentage of the time is usually spent on information gathering, and instead priority is given to so-called greybox or whitebox methodology where a lot of information is provided to the testers to reduce or completely skip the information gathering stage. With limited time, the testers can instead focus on finding vulnerabilities and do not have to spend as much time analyzing the exposure of the organization.

In red team tests, so-called black box methodology is applied instead, where no internal information is provided to the testers. A lot of time is therefore spent on information gathering to mimic the reality of the work the threat actors carry out in their mapping of the organization. A red team test therefore always starts with a basic OSINT investigation, and can sometimes be sufficient to identify certain deficiencies in the organization’s security. OSINT stands for Open Source Intelligence and involves gathering information from public sources to build a picture of the organization and its security culture. The information may include IT systems, buildings, employees, business partners as well as information about security measures that are used and what work culture exists.

Many organizations choose to also include physical penetration testing along with social engineering to simulate the tools that government actors often use, while it is an attack vector that is often forgotten or ignored in traditional penetration testing due to its complexity. It is also common to include both infrastructure tests and web application tests as both of these areas can often be further exploited if the testing team gains physical access to servers or other local sensitive devices, as the devices then also become vulnerable to physical attack methods that are otherwise not available in standard penetration tests. More on this in part two.

So what is a blue team?

An important part of red team tests is the opportunity to test your blue team sharply. Blue team is the grouping within the organization that is responsible for defending the IT systems against attacks and can be either experts in the IT department, the IT security department or perhaps most commonly in a SOC (Security Operations Center). The tests against the blue team are carried out to review routines, processes and the tools used to detect and prevent intrusions and to find possible improvement points in the IT systems. Most of the time, the blue team does not know that the tests are to take place, but only the CIO is notified before the test.

When the test is completed, both parties sit down and go through the results of the testing, where the blue team finds out about vulnerabilities and how they can implement new protection mechanisms, while the red team also finds out how much of the tests have been visible. With this feedback, the red team tests are also developed to become more efficient at going under the radar, so that the level of difficulty for the blue team increases for future tests. In the long run, this results in the cyber capabilities of both parties being increased and provides realistic and relevant cyber protection.

The difference between red team and a penetration test

The biggest difference between regular penetration tests and red team tests is that read teams almost always work in production systems (sharp business-critical systems) and therefore proceed very carefully with the aim of not breaking anything in these systems. This, together with attempts to avoid detection, often results in a significantly longer test period than standard penetration tests, but reduces the risk of mission-critical services becoming unavailable.

In a regular penetration test, dedicated test systems are sought instead if available, and the test systems should reflect the production systems in all critical and relevant functions, the only difference should therefore be that it is not filled with sensitive production information in terms of content. Then more destructive tests are allowed without the risk of negative consequences. In addition, the testers do not have to focus on trying to avoid detection by a blue team, and tests of a more aggressive nature can be used to speed up the testing phase. This results in most of the limited testing time being spent on identifying potential vulnerabilities.

Read part two about the human factor and simulated burglaries here.