Overview of the TIBER framework from a Red Team provider

Introduction

In an era dominated by digital transformation, the financial sector faces an ever-evolving landscape of cyber threats. To fortify their defenses, financial institutions globally turn to frameworks that assess and enhance their cybersecurity resilience. One such powerful tool in this arsenal is the Targeted Improvements for Enhanced Resiliency (TIBER) framework.

👀 This blogpost will be approached from an accredited Red Team TIBER provider's point of view, using the TIBER-LU implementation guide as a reference.

Understanding TIBER

TIBER, developed by the European Central Bank (ECB), is a framework designed to assess and improve the cybersecurity resilience of financial institutions. 

🎯 It aims to mimic real-life cyber threats through controlled and customized exercises, allowing organizations to evaluate their preparedness and response capabilities.

Each country may have its own TIBER implementation based on the TIBER-EU framework.

• TIBER-NL, for the Netherlands
• TIBER-LU, for Luxembourg

The country implementation describes in general terms how the TIBER-EU framework will be applied in the country for the entities participating in a TIBER test, and which optional elements of the TIBER-EU framework have been adopted.

Stakeholders

Several stakeholders are involved in a TIBER test, and they are the following:

• The participating entities, with:

  👨‍💼 The White Team (WT), which is aware of the test and manage the test activities.

  🛡 The Blue Team (BT), which is basically “the defenders” and are not aware of the test.

• The regulators, overseeing the test:

  👁‍🗨 The TIBER Cyber Team (TCT), which manages and monitors the framework implementation and ensure for uniformity and quality.

• The third-party providers:

  🕵️‍♂️ The Threat Intelligence (TI), which provides the targeted threat intelligence report.

  🐱‍👤 The Red Team (RT), which plans and executes the test of the in-scope assets.

   

Process

The TIBER test comprises four key phases:

1. The Generic Threat Landscape phase focuses on generating a report that outlines the participating entities’ role in the ecosystem, identifies threat actors including their Tactics, Techniques, and Procedures (TTPs), and Modus Operandi (MOs). It also highlights the expected motivations of these threat actors.
2. In the Preparation Phase, the TIBER test is formally initiated. This stage involves the establishment of the White Team (WT), defining the test's scope, and procuring the services of Red Team (RT) and Threat Intelligence (TI) providers.
3. The Testing Phase sees the RT and/or TI provider enhancing the generic intelligence with target-specific information, crafting attack scenarios. The RT provider then develops a test plan and executes it, aiming to capture predefined flags.
4. In the Closure Phase, a review of executed scenarios occurs between the Blue Team (BT) and the RT. The Participating entities' remediation plan is finalized, and the overall process undergoes assessment. Detection and response capabilities are evaluated. Participating entities may choose to share findings with relevant peers to enhance the cyber resilience of the sector. Additionally, participating entities communicate the TIBER test outcomes to their respective supervisors and/or overseers during regular meetings.

Red Team Providing

The Red Team is mainly involved in the testing and closure phase. Two deliverables, described below, are awaited from the provider.

Red Team Test Plan

Following the reception of the Targeted Threat Intelligence report, the Red Team is responsible for creating a Red Team Test Plan. The document must strictly indicate all the activities planned to develop and integrate the attack scenarios suggested by the TI.

💭 Imagine a scenario provided where an Advanced Persistent Threat (APT) is targeting the participating entity with the goal of deploying a ransomware to extort money in addition to disrupt business operations and exfiltrating data. This is a "classic" scenario frequently reported in news outlet affecting many companies, including financial ones.

For this scenario the RT plan may include, among other thing, the project planning and the attack scenarios. 

Project planning

In the TIBER framework, there are multiple scenarios spread over a period of 10 to 14 weeks. A non-exhaustive planning for the above scenario may look like the following:

The IN phase involves the Red Team gaining access to the target systems, the THROUGH phase focuses on lateral movement and achieving test objectives, and the OUT phase centers on the exit, with all actions logged and analyzed for the subsequent report.

🤔 You may wonder what happen if the actions of the IN phase failed (e.g. Phishing)?

For this purpose, the TIBER framework introduces the leg ups which is a help provided to the Red Team during the execution of the test. For example, if nobody is clicking the phishing attachment, the White Team may click it, simulating a user being trapped. All the legs ups must be described in the test plan as well.

Attack scenario

The scenario must clearly indicate the threat, his objectives and the critical functions targeted. Some critical functions for the discussed scenario may look like the following:

The Red Team must also plan the Tactics, Techniques, and Procedures (TTPs) based on the TI report. Still using our scenario, the following may be imagined:

🔑 Finally, the key milestones of each scenario and the according leg ups must be defined. Examples milestones for this scenario may be the following:

1. Phishing campaigns with goal of executing code are sent
   1. Did the email pass the email gateway? 
   2. Any user interaction? 
   3. Is the payload blocked?
2. Command and control connected and stable
3. Identification of critical functions
4. Exfiltration of sample data
5. Execution of ransomware on sample data

Each key milestones may be subject to questions as showed in the first milestone. If the negative is answered, a leg up must be triggered to access the next step.

Red Team Test

Process

Once the plan is redacted, the Red Team Test start based on the plan. During about twelve weeks, the Red Team provider conducts a stealthy exercise against the target systems, aiming to capture flags.

Creativity is encouraged to overcome obstacles, all while collaborating closely with the White Team (WT) and TIBER Cyber Team (TCT). Actions are logged for documentation and future reference purposes. 

💬 Regular updates to the TCT ensure transparency, and occasional guidance from the WT may be sought within ethical, legal, and resource boundaries. Effective communication is maintained through weekly updates and encouraged meetings, contributing to the overall quality of the test.

Purple team

🟣 During the test, if the attackers are discovered, it is possible to incorporate purple teaming which involves collaboration between the Red Team (RT) and the Blue Team (BT) to enhance both offensive and defensive strategies.

Reporting

📃 Apart from the usual sections found in more generic penetration test or red team operations (Executive Summary, Findings, Recommendations), TIBER differs by adding “Storyline”, “Provisional root cause analysis”, and “Artefacts” sections in the deliverable.

📖 The storyline section encapsulates the Red Team provider's detailed narrative, encompassing critical functions, deviations, attack scenarios, White Team support, compromised elements, findings, and insights into the cybersecurity posture of the tested entity.

📌 The provisional cause root analysis requires the Red Team provider to use their expertise to identify root causes of findings, considering people, processes, and technology; categorizing these causes by criticality, the analysis is preliminary and aims to foster forward-thinking discussions in the Replay workshop, rather than being solely technical and retrospective.

🧹 In the artefacts section, the RT provider detail any plausible artefacts, such as toolsets, remaining on tested entity systems, providing comprehensive information (filenames, paths, hashes, etc.) to facilitate their removal by the entity and prevent potential risks or interference with future incident investigations or security assessments; substantiation with clear evidence (e.g., log files, screenshots) is required throughout.

Replay workshop

Finally, to cloture the exercise, a replay workshop is organized with the Blue Team to identify logged actions and improve the entity’s overall security.

The objective of the Replay Workshop is to recreate and analyze the actions taken by both the Red Team (RT) and Blue Team (BT), fostering mutual learning. 

🟣 It may include a purple teaming component, where the BT and RT collaborate to explore alternative steps, the RT could have taken and assess potential BT responses. 

The RT provider is encouraged to provide insights into what could have been achieved with more time and resources, recognizing that real threat actors are not bound by the time and resource constraints of a TIBER test.

Conclusion

In conclusion, the TIBER framework serves as a robust and dynamic approach to testing and enhancing the cyber resilience of financial institutions. 

By combining realistic threat scenarios, collaboration between Red and Blue Teams, and a focus on continuous improvement, TIBER provides a comprehensive evaluation of an organization’s security posture.

References

• CSSF, TIBER-LU - Implementation guide
• ECB, TIBER-EU - Guidance for the red team test report

Author

Alexandre Guldner

Do you have any questions? Would you like to know more about the TIBER framework? Contact our experts!