Red teaming: testing detection of and response to attacks
You have put protective measures in place and operate your own or an outsourced SOC – your team for security monitoring and attack detection. Does it detect coherent attacks, and does the agreed response work? With red teaming, we test this question against an agreed attack objective.
Red teaming: putting your defences to the test under real conditions, not on paper.
Your situation
You need to carry out threat-led penetration testing under DORA or want to know whether your SOC detects a real attack?
In regulated sectors – finance, energy supply, healthcare, telecommunications – frameworks such as the German IT Security Act (IT-Sicherheitsgesetz), TIBER-EU or the Minimum Requirements for Risk Management (MaRisk) require regular, comprehensive security reviews. For financial entities, the Digital Operational Resilience Act (DORA) requires targeted red team assessments in the form of threat-led penetration testing (TLPT).
Even without a regulatory reason, the question arises sooner or later: you have tested your environment with penetration tests and closed vulnerabilities, you operate your own or a managed SOC and an established security concept. Does your blue team detect a coherent attack – and does it act according to your internal policies?
This is where red teaming comes in. We agree on a specific objective with you, such as access to a particular database, the management’s e-mail mailbox or administrative rights in Active Directory. In a threat-led penetration test under DORA, we take on the role of the external red team tester and follow the guidance of the TIBER-EU framework; the threat intelligence is provided by a separate threat intelligence provider. Our work is based on our penetration testing practice: since 15 September 2013, secuvera has been certified by the BSI as an IT security service provider for IS penetration testing (BSI directory, in German).
If there is no SOC and no mature security concept, we advise against red teaming, because attack simulations can then involve considerable risks. In that case, a penetration test or our workshop approach WBRT® – White Box Red Teaming is more suitable.
Services & results
Red teaming and TLPT: control team, threat profile, three phases
You find out whether your SOC detects an attack on a pre-agreed objective that is carried out as inconspicuously as possible, and how it responds. Your control team defines the scenarios, starting point and rules of engagement with us; for a TLPT under DORA, we take on the role of the external red team tester in line with TIBER-EU. You receive a report on all scenarios, with a purple teaming workshop on request.
A penetration test aims to find as many vulnerabilities as possible within the defined scope and deliberately leaves visible traces. In red teaming, chaining individual relevant vulnerabilities is enough to reach the agreed objective – as inconspicuously as possible. This requires close coordination: before the assessment, we define the framework conditions and approach with you; this is followed by the preparation, testing and follow-up phases.
01
Before the assessment: threat profile, TTPs and rules of engagement
You put together a control team that knows about the assessment and works closely with our red team during the project. Together we develop the scenarios – based on specific criminal groups (advanced persistent threats, APT) or defined by you. In a TLPT according to TIBER-EU, the threat analysis comes from the threat intelligence provider; our red team implements the scenarios as the external red team tester.
The threat profile describes the threats to your organisation and forms the basis of the attack scenarios. The TTPs (tactics, techniques and procedures) define the strategic approach of the red team:
Tactics: which overarching objectives are to be achieved?
Techniques: which methods are used, e.g. spear phishing or pass-the-hash?
Procedures: how is the implementation carried out in detail?
Rules of engagement
A binding definition of what the red team may do – and above all, what it may not.
02
Choosing the starting point: assumed breach or initial compromise
In an assumed breach, the attacker is already in the network and the test focuses on internal attacks. In an initial compromise, we start from outside and first look for an attack vector into the target network.
This can also mean digitally “lying in wait”: we index your services, and as soon as vulnerabilities become known, we exploit them very promptly. We decide together which starting point fits your requirements.
03
Preparation phase: open source intelligence (OSINT)
Without an assumed breach, the red team gathers as much information as possible about your organisation to identify entry points: it scans publicly accessible systems, identifies your domains and much more.
For this, we use commercial tools that make the search efficient and thorough, supplemented by search engines and technical tools. We link organisational information with technical information from various sources. The processed data feeds into the testing phase.
04
Testing phase: inconspicuously to the agreed objective
Using the information gathered, the red team executes the prepared scenarios – unlike in a pentest, as inconspicuously as possible. It tries to get into the internal network, establish persistence there, extend permissions through privilege escalation and compromise further systems through lateral movement.
Throughout, the red team strictly adheres to the rules of engagement and the threat profile developed with you before the start of the project.
05
Follow-up and purple teaming
If the SOC has not detected the attacks, the staff are informed now. In any case, the SOC receives the results report with all scenarios carried out and their outcome.
In a purple teaming workshop, we can repeat the scenarios. This shows your SOC how the attacks unfolded and how it can detect them in future – possibly earlier.
What your SOC takes away
A report on all scenarios and their outcome, plus specific starting points for improving detection and response.
Our expertise
Our red team experts are CRTO-certified (Certified Red Team Operator) and have years of experience in penetration testing. We have been carrying out pentests since 2000, as an IT security service provider certified by the BSI for penetration testing.
We have been working on the limits of red teaming for years. A master’s thesis at Aalen University supported by secuvera has shown scientifically how demanding the prerequisites for meaningful red teaming are. For organisations that do not yet meet these prerequisites, we have developed our own workshop approach, WBRT® – White Box Red Teaming.
That is why we clarify before every proposal whether red teaming is the right next step for you. We place great value on individual planning so that the attack simulation fits your requirements and structures.
Getting started
Preparing coordination, authorisations and test boundaries
Name informed contacts
You put together a control team: an informed group for coordinating and safely steering the test. This control team works closely with us during the project. Together we decide who else is informed and when the SOC is involved.
Agree on binding test rules
Before the start, we agree on permitted actions, excluded systems and test windows. These test rules are called “rules of engagement”. We also clarify authorisations, contacts, and escalation and termination conditions.
Attack objective and time window agreed together – your operations stay on course.
Consider risks and the limits of what results show
Attack simulations can involve considerable risks for operations. Their preparation therefore requires the involvement of the people responsible. The results relate to the scenarios tested. They prove neither complete attack detection nor comprehensive security.
Questions about choosing and commissioning red teaming
Can we specify our own attack scenarios?
Yes. You can contribute scenarios from your organisation. Alternatively, we base them on the approach of specific attacker groups. Together we select which scenarios are relevant to your attack objective.
When is the WBRT workshop a better fit for our project?
When you first want to think through possible attack paths together. In White Box Red Teaming (WBRT®), we develop and discuss scenarios with your technical contacts. A permanently available defence team is not required for this. Real technical attacks are a separate step.
Does red teaming automatically cover a regulatory TLPT?
Not automatically. A threat-led penetration test under DORA has its own requirements for specifications, roles and test conditions, which we clarify with you separately in advance. secuvera takes on the role of the external red team tester and follows the guidance of the TIBER-EU framework. The threat intelligence is prepared by a separate threat intelligence provider.
Is red teaming suitable for our organisation?
Red teaming is particularly suitable for organisations with an advanced security concept and specialised resources. Check in advance: have technical vulnerabilities already been tested by penetration testing and closed? Does your SOC consistently implement an established security concept? Is technical monitoring part of your protection system? Without your own or a managed SOC, WBRT® – White Box Red Teaming or a penetration test is the appropriate starting point.
What distinguishes red teaming from a penetration test?
A pentest is a targeted technical test that finds as many vulnerabilities as possible within the defined scope – deliberately conspicuous and within a short time. The effectiveness of protection systems is usually not the focus. Red teaming pursues a specific objective, proceeds as inconspicuously as possible and tests whether your SOC detects and responds to the attack.
