TIBER-EU Framework - Threat intelligence-based Red Teaming

TIBER-EU Framework

Threat intelligence-based Red Teaming

Dominik Altermatt
by Dominik Altermatt
on November 19, 2020
time to read: 16 minutes

Keypoints

All about the TIBER-EU Framework

  • The framework covers many important factors of successful red teamings
  • TIBER-EU strives for a "Real-World" approach
  • The TIBER-EU process, however, can limit red teams and thus cause inefficiencies at best
  • scip AG focuses more on effective detection of vulnerabilities instead of the claim to act as "Real-World" as possible

scip AG has been successfully conducting red teaming projects and attack simulations for almost 20 years. Our customers are organizations that have a certain maturity in information security. Especially the financial sector is well represented as a customer. With TIBER-EU (red teaming based on threat intelligence) a framework for red teaming projects was published in 2018 by the European Central Bank. In this article we will deal with this framework to give an overview and compare its requirements and recommendations with our practical experience.

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:

What is “Threat Intelligence Based Red Teaming”?

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.

The TIBER-EU Process

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.

TIBER-EU high-level process overview

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:

Preparation Phase

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.

TIBER-EU preparations

Procurement of TI and RT providers

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:

Scoping Process

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:

Test-Phase

Active testing is divided into two phases:

  1. Threat intelligence
  2. Red teaming

Threat Intelligence

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:

Red Teaming

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:

Abschluss-Phase

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:

Conclusion

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.

About the Author

Dominik Altermatt

Dominik Altermatt is working since 2003 in the IT business and was responsible for Data Leakage Prevention at a Swiss bank for many years. Besides traditional penetration testing he is also focusing on the introduction and improvement of IT security management processes. (ORCID 0000-0003-4575-4597)

Links

Your Blue Team may use some support?

Our experts will get in contact with you!

×
JWT Issues

JWT Issues

Andrea Hauser

CIS Controls

CIS Controls

Tomaso Vasella

Ransomware Detection, Defense, and Analysis

Ransomware Detection, Defense, and Analysis

Marc Ruef

Trustworthy AI

Trustworthy AI

Prisca Quadroni-Renella

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here