I want a "Red Teaming"
Michael Schneider
All about the TIBER-EU Framework
The TIBER-EU Framework was standardized with the aim to streamline the procedure for red teaming projects for national central banks as well as critical functions in the EU financial sector. The framework can currently be voluntarily adapted nationally. A national TIBER implementation will be marked with the corresponding country code, e.g. TIBER-BE (Belgium) or TIBER-NL (Netherlands).
On one hand, a governance structure for correct and safe implementation is described. This is to ensure that red teaming projects can be comparable and recognized throughout the EU, as well as the possibility to collect Lesons Learned and incorporate them into improvements.
This is to be achieved, for example, by establishing a corresponding body (TIBER Cyber Team, TCT) at national level and a central team (TIBER-EU Knowledge Center) at European level. In addition, it is described in detail which stakeholders can or must be involved in which function.
On the other hand, the framework describes how the test phase End-to-End is to be carried out and provides concrete requirements as well as recommendations. If possible, real, current or even future attack scenarios should be worked out by means of threat intelligence activities and then imitated by means of red teaming on the productive systems of the target organization in order to check the current resilience of the target organization.
In short, TIBER-EU pursues the following goals:
TIBER-EU defines a threat as:
On this basis, Threat Intelligence is defined as follows:
Information that provides a relevant and sufficient understanding of the mitigation of the effects of a potentially harmful event.
Threat Intelligence includes:
An intelligence-led red team test imitates the TTPs (Tactics, Techniques and Procedures) of real attackers based on tailored threat information. It targets the people, processes and technologies underlying the critical functions of the target organization to test its protection, detection and response capabilities without prior knowledge. This enables the target organization to understand their real resilience by putting all the elements_ of their business operations against the threat actors’ TTPs.
Apart from the necessary characteristics for a European-wide acceptance across different jurisdictions, we are especially interested in the effective process of implementing red team projects. Therefore, we will not look at the overall aspects and processes in detail.
The TIBER-EU process roughly follows a classical project approach. Optionally, an analysis of the entire financial center in which the target organizations are located is recommended as an initial starting point.
The Threat Intelligence (TI) and red teaming (RT) process must involve independent third party providers. The total project management is carried out by the so-called White Team (WT), which consists of personnel from the target organization with the corresponding support of the TCT.
TIBER-EU mandatory requirements:
TIBER-EU recommendations:
In addition to the classic project start, the preparation phase includes the procurement of IT and RT providers, the scoping process and the development of the project plan. Special attention is paid to the selection of the TI and RT providers. Their skills and quality are decisive for the value of the test and for a smooth and secure execution.
For TI and RT providers, high requirements are set to ensure the necessary quality and care for the sensitive test.
TIBER-EU recommends to choose only certified providers, however, there is no appropriate certification body.
Therefore, target organizations must carry out the necessary due diligence during the selection process themselves. However, the TIBER-EU procurement guidelines and checklists document detailed minimum requirements for external providers. TIBER-EU describes that the responsibility for selecting TI and RT providers lies with the target organization.
TIBER-EU mandatory requirements:
TIBER-EU recommendations:
In addition to the selection of external providers, the scoping process is the second decisive factor in the planning and execution of an RT test, since it defines the scope and content of the test and thus significantly determines the expressiveness of the report.
Critical functions (CF) are used to build up the scope. CFs are defined as follows: The people, processes and technologies that the target organization needs to deliver a core service, the interruption of which could adversely affect the financial stability, security and integrity of the organization, the company’s customer base or the organization’s market behavior.
The CFs are then used to define flags (Capture the flag), i.e. the description of actions or targets that confirm a successful RT attack. An example could be: The unnoticed exfiltration of customer data from a PCI zone.
TIBER-EU mandatory requirements:
TIBER-EU recommendations:
Active testing is divided into two phases:
TIBER-EU defines that defined attack scenarios should be developed as a starting point for red teaming. These in turn should be based on a Threat Intelligence Report. This should allow for the derivation of attack scenarios that are as relevant and realistic as possible, or a real threat situation with its actors should be drawn up.
The first result should be a Targeted Threat Intelligence Report (TTI). TIBER-EU recommends to plan a period of about four weeks for these activities.
Among others the following goals are mentioned:
The result of this activity is the identification of the areas of attack of people, processes and technologies in relation to the target organization and its global digital footprint on a CF-oriented, systems-based basis.
Furthermore, effective attack scenarios along the project scope are to be defined based on the insights gained. These scenarios form the link to RT.
TIBER-EU mandatory requirements:
TIBER-EU recommendations:
The RT phase is explained accordingly quickly. Through the preparations, the team is given a clear mandate based on the scope definition and the scenarios. The RT defines a concrete RT test plan based on the scenarios. On the one hand, very detailed information on TTPs in relation to the attack targets should be documented in advance. However, TIBER-EU explicitly admits that scope, flags and TTPs can be changed during the course of the test and that the RT should be granted the greatest possible flexibility and creativity.
The output is the report of the RT, which documents the findings.
TIBER-EU mandatory requirements:
TIBER-EU recommendations:
The Blue Team (BT) of the target organization is now informed about the test and is to create a BT report with corresponding countermeasures based on the RT report. With Workshops, RT and BT should clarify the details and, if necessary, repeat certain RT actions in order to understand processes better.
Of course, the target organization should now plan and execute the implementation of any appropriate countermeasures.
TIBER-EU mandatory requirements:
TIBER-EU recommendations:
The TIBER-EU Framework appears basically as a solid work, many reasonable requirements and hints for a successful red teaming are documented. Of course, the framework brings a certain degree of formalism and thus the corresponding bureaucracy with it, but this seems absolutely required for the overall acceptance of the framework as well as the desired quality. However, this may – depending on how it is interpreted – also have a negative influence on the work of the TI/RT teams. TIBER-EU countered these risks with clear indications regarding the necessary flexibility and dynamic scoping during the test phases.
In many details, the requirements corresponded to the procedure, which we also strive for with our attack simulations. However, our overall approach differs somewhat. TIBER-EU strives for a most realistic scenario, therefore the development of “real-world” scenarios by the TI-Team in advance. The scoping is also defined early in the process by the target organization with the help of the TCT. This detailed scope and scenario definition creates the risk that the red team will be restricted in its ability to be strengthened, and although the RT is granted a great deal of creativity, a too strict interpretation of the defined scope and scenarios will not reveal any valuable information by the red team. Therefore, it is recommended that suggestions from the red team are generously accepted during the testing phase and that the RT should be part of the discussion during the scoping phase.
The expectation that a RT is capable of simply having all possible TTPs “in the know” in a very technical depth seems not quite realistic. The corresponding engineering effort that would be necessary for this is probably not worthwhile for many offensive security companies. As well as the hint by TIBER-EU that “good” RTs should be able to imitate nation-state actors is something special. Technically this may be partially true, but many other aspects, such as access to effective intelligence information, such as data from Internet providers, or even basically the scope and quality of resources (budget, personnel, equipment, etc.) is probably rarely given at the nation-state actor level by commercial providers.
Our approach follows a pragmatic and economically effective way. In many respects it does not differ from TIBER-EU, but we tend to use simulated rather than realistic scenarios. Our experience shows that the customer can gain more weak points/knowledge within the given budget. In doing so, we focus on the broadest possible scope, i.e. the entire target organization is ideally defined as a scope and corresponding CF analogous to TIBER-EU is documented and submitted to the RT. Furthermore, we advise to define the scenario of a compromised client as a starting point. We gladly offer the initial compromise as a separate module, so that a consistent story can be documented.
Starting from a compromised client/route employee scenario, reconnaissance is performed and Privilege Escalation and Lateral Movement is analyzed and executed step by step. This results in various attack paths, which either lead to the compromise of CFs or not. This approach reveals various weaknesses in the entire target organization, independent of defined real-word scenarios. Unfortunately, in today’s world it seems to be a given that detected weaknesses and successful attack paths can and will be exploited by malicious actors. For this reason, we often dispense with detailed TI analysis and proof of this fact in RT projects.
This does not mean, however, that TI is not relevant. We would, however, carry out analyses in this area independently of RT projects as a separate task. We would also loosely encapsulate corresponding weak-point analyses of the perimeter and OSINT, for example, as modules.
It remains to be seen whether TIBER-EU will continue to assert itself in its current form. Various European countries have already implemented or are working on their own adaptations. A possible obligation of such tests by the regulator could also have very interesting effects.
Our experts will get in contact with you!
Michael Schneider
Marisa Tschopp
Michèle Trebo
Andrea Covello
Our experts will get in contact with you!