TIBER - threat intelligence led red teaming for financial institutions

EU rules require cybersecurity exercises to improve banks’ resilience. Mimicking real-life attacks is easier said than done, and many pitfalls remain.

_{Article written by Vito Rallo}

TIBER, intelligence led red teaming that works

Back in 2018, the European Central Bank published the TIBER (Threat Intelligence-based Ethical Red teaming) framework. Inspired by the UK's CBEST and adapted to each European member state, TIBER regulates cybersecurity assessments for improving financial institutions’ resilience by mimicking real-life attacks. To do so, TIBER prescribes a red team exercise strictly led by threat intelligence-inspired scenarios.

If you’re reading this article, you probably already know about TIBER. Good - let’s skip the typical overview of TIBER and red teaming expertise claims, and get straight to the point. For those looking for more details, the official ECB paper is a good place to start.

This article focuses on the viewpoint of the red team provider (RTP) and discusses success factors identified on the basis of experience. It’s important to appreciate that the TIBER framework has evolved across the years, overcoming pitfalls, to finally focus on the essential aspect: reciprocal value creation. If you’re leading an ethical hacking team, there are insights to be had while sparing yourself some unnecessary frustration. If you’re leading the security team of a financial institution, then this is a chance to discover together how to spend money wisely and make the TIBER exercise a success.

When winning isn’t about winning

A service provider should focus primarily on three aspects aligned with the essence of the framework: cyber resilience, quality and value. Quality comes with experience, skills and certifications, but it’s also all about the approach (or in red teaming vocabulary, ‘tactical exploitation’ - the provider must adapt all aspects to the constraints of a regulated test).

The value aspect is trickier: the goal is a real-life inspired experience, in a challenging game where three players - the regulator, the institution and the provider - are trying to win. Paradoxically, this makes it easy to end up ‘losing’ and missing the opportunity to create value for everyone involved.

For ethical hackers, success is often defined in terms of ‘capture the flag hacking’. For the bank, success means making sure that the red team provider doesn't win while avoiding criticism from the regulator. The regulator meanwhile is auditing the cybersecurity controls in place at the financial institution. In brief: a recipe for disaster.

Nothing could be further from the spirit of TIBER. It's a framework designed around feedback and collaboration where ideas, opinions, results and comments are part of a constructive process that starts from the modus operandi of a possible attacker (the threat intelligence), and which provides insight into the many aspects of a bank's security operations (secops).

A key ingredient in the recipe for success is setting the right mindset across the entire exercise, aligning the red team’s understanding and goals, setting proper and realistic expectations, and always highlighting the reciprocal benefits of fruitful and positive cooperation. Call it the W3 if you will, not referring to the web but rather a three-way win-win-win for all parties involved.

Red teaming with a difference

Banks are undoubtedly used to offensive security and related simulations; however TIBER is different from a classic or standard red team exercise. It’s worth taking a moment to compare a standard red team service to a TIBER delivery to highlight some of peculiarities in the RTP’s role.

Timing and schedule

TIBER requires accurate scheduling and planning. Activities are tightly linked to the defined scenarios, leg-ups, flags and other elements. Project management is not only for the service provider. Beyond the execution phase and across the entire exercise, project management is a critical task for the WTL (White Team Leader of the institution) - it must be an internal (bank) function.
The RTP must take into account more than just the execution time. The increased number of formalities and interactions needed due to the ‘regulated’ aspect lead to significant overhead.

Execution constraints

TIBER must be executed with rigorous respect of rules, scope and regulations. Compared to a standard red team exercise, the provider has less freedom.
The exercise is conducted in production, with flags defined for the bank’s critical business functions (CBFs). While this sounds exciting, in reality it translates into a risk management nightmare for the RTP and the WTL. Only an open collaboration can ensure success.
Scenario X in the TIBER framework is designed to be the final scenario, the most complex attack, used to overcome and circumvent constraints. Experience pleads in favour of reconsidering this approach. Waiting until later in the exercise to do this may not be ideal; given that other scenarios may mimic well known attack techniques likely to be discovered by modern detection technologies, it may be better to open with the stealthiest attack scenario.

Complexity

Capturing flags is complicated. In a standard red team exercise, the ethical hacker has more space for personal interpretation. Considering the security maturity level of a financial institution, capturing flags defined for critical business functions may require a lot of hard work and time. After all, a bank isn’t the grocery store on the corner.
Keeping the execution linked to the selected threat intelligence scenario may not be easy and can act as a limiting factor on the chances of success.
TIBER also aims at testing the secops capabilities. In this sense, it’s worth revisiting the ‘incremental noise’ approach. Being stealthy is a must for TIBER as the blue team is unaware of the exercise. The red team being detected might trigger the entire incident response process, making it difficult for the RTP to execute subsequent scenarios.

Common pitfalls

Those of us who have had the good fortune to be confronted with TIBER at the very beginning of its journey will agree that over the years it has developed into a mature and valuable framework. And this process is far from over; TIBER is in constant evolution. After each TIBER exercise, the national regulator typically refines its national implementation guidelines on the basis of lessons learned. Pitfalls highlighted by practitioners a few years ago have in the meanwhile been eliminated by this evolutionary process; TIBER improves with each iteration.

Some of the remaining common pitfalls listed below can be addressed with the help of careful planning and close cooperation.

Setting expectations too high
Missing intermediate flags
Failing to plan efficiently
Falling out of scope
Failing to activate leg-ups
TI provider disappears at execution time
Replaying the attack is not feasible

Setting expectations too high

Evaluate the scenarios, make sure there is close collaboration between the threat intelligence (TI) provider and RTP to adapt the intelligence, and craft a scenario that is not a sterile replica based on the bank’s modus operandi but rather one suited to the bank’s daily reality.

Make it feasible, don’t overshoot, consider the constraints and time available.

Missing intermediate flags

The RTP might not reach the flags defined for the critical business functions. Measure the success and the execution progress for each scenario by defining appropriate intermediate flags.

Failing to plan efficiently

Avoid executing scenarios in series. Plan for parallel execution as many aspects are common to multiple scenarios, especially during the through-phase.

Falling out of scope

This is a recurring issue, and remains a moving target. Try to clearly define the scope upfront, as it may be narrower than expected. The regulator's goal is neither to test Office 365, nor disclose to Microsoft a new bypass for ATP, nor to test third party SaaS platforms used by the bank.

Falling out of scope is easily done and not permitted.

Failing to activate leg-ups

The WTL may struggle to activate certain leg-ups, especially in real time given confidentiality limits (e.g. create a user in the Active Directory). Close and effective collaboration between RTP and WTL is, once again, the solution to avoiding this pitfall. Plan for leg-ups upfront; clearly define them in the red team plan (before the execution, and certainly not on your own).

The WTL must explicitly validate each leg-up and prepare by involving the necessary people in the rest of the organisation.

TI provider disappears at execution time

This won't work and rarely happens anymore. Having the TI provider aligned and present during execution's update meetings is strongly recommended.

Replaying the attack is not feasible

Here again, another issue that remains partially open. TIBER requires the replaying of successful attacks during a dedicated session to align and improve the bank's blue team capabilities. It correctly sounds like a purple team. Regulators have been pushing for purple teams since the early days of TIBER (more on this below). RTP providers will fully realise how technically challenging (if not impossible) the replaying of a specific attack is.

Modern attacks are chains, not just standalone exploitations.

Lessons learned

Each TIBER execution is an authentic learning experience. As such, each project sheds light on some of the critical success factors involved.

The W3 approach (win-win-win) pays off. Effective, constructive and relaxed cooperation between WTL, financial institution and providers, with gentle intervention by the regulator; this is the key to success. In TIBER, competition leaves no winner. Open dialogue will steer the execution wherever it counts, and reflects the right spirit of TIBER: testing not only for compliance but for improvement - the real value to be gained. This yields not only success but also a much better return on the bank's investment.
TIBER is about more than just technical excellence. The experience, the mistakes made in the past, shed light on potential future problems. Lessons learned in the past are an essential contributor to improvement in the future.

Good threat intelligence reasonably extended to technical concepts, and providing OSINT reconnaissance, can contribute to better scenarios and is much appreciated at execution time.
The WTL must proactively engage and strive for collective success.
Cross-border implications can be fundamental and need adequate consideration. Delivery for an international institution might become a multi-regulator exercise. Given the deliberately local aspect of TIBER's implementation, the vision of regulators may differ slightly from country to country. Having a global delivery network and the right experts involved at national level is a critical success factor in such cases.

In addition to success factors, there are a few key challenges worthy of attention and for which greater awareness is necessary.

Impact

The test exercise is being run in production. Don't focus only on the technology implications but also take into account processes and people. Don't assume that the RTP will fail to capture some very ambitious flags. Agreed, it isn't easy, but it could happen! The red team plan should foresee such cases and appropriately limit the execution scope; the WTL must be prepared to react to the unexpected and intervene.

A detected incident in a sensitive environment could trigger a broader cybersecurity incident within and even beyond the organisation. It could affect the business of connected entities and irremediably influence people’s KPIs.

Purple team

The current TIBER framework provides limited guidance on how to conduct the final workshop. At the time of writing, a purple teaming guide is work-in-progress for the Dutch regulator (TIBER-NL). In addition to the many possible interpretations, not everybody in the cybercommunity has the same understanding of the purple teaming concept.

According to one of the many interpretations, the purple team exercise should be a live workshop in which both red and blue teams cooperate to learn from each other. They share the common goal of translating the knowledge acquired during the exercise into defense capabilities, improving the runbooks by adversary simulation and producing actionable intelligence to enhance security operations and technology.

That’s way beyond the goals of TIBER, where the objectives are different for each party. In general, during the final workshop the framework calls for replaying attacks from the winning scenario (not a generic tool-based adversary simulation). It’s desirable to be able to mutate the techniques of detected attacks to explore variations and measure detection capabilities at run-time. Everything must happen within a drastically limited amount of time; it's not a project on its own but is part of a bigger picture.

The goals and expectations of a purple team during a TIBER exercise are likely to be specific; in other words, a generic approach will not fit. A purple team working on a TIBER exercise must deliver while aligning on each party's objectives, at a fast pace, while considering the human factor - people’s roles and their technical background.

Phishing still survives

Red team providers are in a constant, breathless race to find new breach vectors and advanced exploitation techniques. Despite increased awareness and predictions that phishing will die soon, this old enemy is still alive and healthy - and has actually been given a new lease on life by the COVID-19 pandemic.

The in-phase remains the most challenging one: breaching the perimeter and compromising a host. Don't underestimate something that requires a multidisciplinary approach, not just ‘hacking’. The target’s security awareness, outstanding protection technology to be bypassed at many layers of the attack kill chain, the psychological elements behind a good pretext; these are all part of the art of social engineering.

Thibault Van Geluwe De Berlaere, ethical hacker and experienced red teamer, states: “To succeed, real-life attacks require better and personalised pretexting, and time, a lot of time. Spear phishing of ten security-aware targets is bound to fail”. And nothing resonates better than Thibault's message regarding real-life TIBER executions: "Our journey usually starts where most compromises start: phishing. We execute several phishing campaigns, ranging from basic ‘spray-and-prays’ to highly technical, targeted campaigns. Unfortunately, these have little effect; mature clients have very capable email defenses. Other perimeter attacks, targeting publicly exposed infrastructure and attacking wireless networks, are often also ineffective.

When all these options are exhausted, time constraints force the use of a ‘leg-up’ to gain access to the internal network and keep chasing the test’s objective. Inside the network, we have to fight against several controls such as SSL/TLS encryption, antivirus, or worse - modern EDR software, firewall restrictions while beaconing out, etc. We use several techniques to gather access, such as credential dumping and Active Directory-based attacks. We usually move laterally throughout the organisation, jumping from one host to the next, each time getting one step closer to the critical function or flag.

At one point or another, during each of the scenarios, we usually keep hitting the same wall: Privilege Access Management (PAM) and strong two-factor authentication. To eventually overcome, the fastest is not to go for a zero-day but rather to go back to social engineering with timing and new fancy atypical attacks.”

In conclusion, the most useful piece of advice may be to go back to basics. In this case, the fact that TIBER is very much a team exercise, and one in which the only way to win is to make sure all the teams win. It’s worth remembering the raison d’être of TIBER: to safeguard our financial institutions against cyber threats. The real intelligence here is to focus on that - all together.