In our previous post, we published an analysis of current TIBER implementations ahead of DORA’s TLPT requirements. To recap, this contained:

• An overview of existing TIBER implementations (situation mid-2024)
• A comparison of the respective guidance documents w.r.t. major building blocks, such as the generic threat landscape, purple teaming, leg-ups, scenario X
• Assurance that consistency across jurisdictions is guaranteed thanks to the overarching governance of the TIBER-EU guide.

We concluded part 1 by saying that Threat-led Penetration Testing as required by the DORA regulation will be specified in accordance with TIBER-EU and in agreement with the ECB. TIBER can be considered as the “How” to implement the “What” of the DORA (Digital Operational Resilience Act) Regulatory Technical Standard (RTS) on TLPT.

With the current post, we want to extend on the previous TIBER analysis and discuss particular requirements for the upcoming TLPT regulations as part of DORA that will likely result in an updated and more precise TIBER-EU framework.

The draft RTS has been in public consultation until March 4^th 2024 and the European Supervisory Authorities (ESAs) submitted the final draft RTS to the European Commission by 17 July 2024.

Under DORA, 20 types of -mostly financial- entities (identified as systemically important institutions) will be required to perform a TLPT exercise at least once every 3 years. A TLPT involves targeting live production systems supporting critical functions of a financial entity according to the following high-level process, which is based on the TIBER framework:

• Preparation
  The process starts with the entity receiving a notification from the TLPT authority. The entity must assemble the Control Team (CT), submit initiation documents and scope specification following certain criteria for including critical functions. In addition, the CT must perform a risk assessment and risk management, and procurement of TI and RT providers.
• Threat Intelligence
  The TI provider will analyse generic and sector-specific threat intelligence relevant for the financial entity and perform reconnaissance against the entity. The TI report contains scenarios referencing specific threat actors targeting critical functions.
• Red Team
  The RT provider creates a red team test plan based on selected scenarios and executes the simulated attacks according to plan, communicating closely with the CT. Completion of the RT execution culminates in a red team report and initiates closure steps.
• Closure
  The closure phase initiates collaboration between red and blue teams, requiring a replay workshop and purple teaming. In addition, multiple deliverables are required, such as the test summary report and remediation plan to be provided by the CT. These steps are subject to thorough timing constraints.

If you are familiar with TIBER, this should all still be familiar ground. The only difference you may have noticed so far, is the terminology to refer to the White Team. In TLPT language, this team is now referred to as the Control Team, immediately indicating the role they have to fulfill. In terms of stakeholders, there is not much change either compared to TIBER participants:

There may be a change in dynamic regarding the “power” of the TCT, who possibly go beyond a mere supporting role to having a stricter regulatory oversight duty.

So far, so good. However, there’s a few other particularities you may want to know about.

The TLPT RTS also brings a few specifics and we have listed the most interesting ones below, based on our opinion and experience executing TIBER engagements across multiple jurisdictions.

Internal Testers

TLPT allows the execution to be performed by internal testers. Instead of a third-party provider, internal testers can be used, with a number of caveats however:

• Every one in three tests should be performed by external testers;
• In case both internal and external testers are part of the team, this will be considered as a TLPT performed with internal testers w.r.t. previous statement;
• All members of the internal test team have been employed by the financial entity or by an ICT intra-group service provider for the preceding two years;
• Use of internal testers must be explicitly mentioned in TLPT-related documents, such as initiation documents or the report.

An exception to this rule is set aside for “Credit institutions that are classified as significant”, since they may only use external testers. This classification happens in accordance with Article 6(4) of Regulation (EU) No 1024/2013 and is based on size, economic importance, and significance of cross-border activities.

We believe in practice this might mean that:

• institutions that are large enough to have internal teams adhering to the requirements will not be allowed to use them, while;
• institutions that would be allowed to use internal teams may not have internal testers that tick all the required boxes…

resulting in limited use of internal testing teams.

Important to note is that use of an external threat intelligence provider is still mandatory! However, there are no restrictions on using additional or internal TI resources to complement the external TI provider.

Pooled Testing

TLPT exercises can target a financial entity where a third-party service provider delivers services to related to its identified critical functions (sometimes referred to as Critical Third-Party Providers or CTPPs). If such a CTPP is included in the scope of the TLPT exercise, it might be necessary to foresee representation of the CTPP in the White Team as well.

The TLPT regulation regarding participation of an ICT third-party service provider allows for an interesting concept called “Pooled Testing”. This may happen in case the exercise is reasonably expected to have an adverse impact on

• the quality or security of services delivered by the ICT third-party service provider to customers that are entities falling outside the scope of this Regulation, OR;
• the confidentiality of the data related to such services

In such instances, the financial entity and the ICT third-party service provider can agree that the ICT provider itself will directly procure external testers to perform a pooled TLPT involving several financial entities to which the ICT third-party service provider provides ICT services, under the direction of one designated financial entity.

This pooled test will be considered a TLPT carried out by each financial entity that participates and also requires every entity to provide a remediation plan.

This is an interesting concept, but we expect the high complexity and necessity to maintain confidentiality for all involved entities to make this very challenging in practice.

Stringent Requirements

The TLPT regulation includes additional mandatory or tighter requirements in comparison to the initial TIBER specifications:

• Purple Teaming: Whereas many TIBER implementations include purple teaming as optional element, TLPT makes it a mandatory aspect.

• RTTP: With TLPT the red team test plan has to be formally approval by the Control Team and TLPT Authority. Interesting to note is that this was already included in the TIBER-NL specification.

• Deadlines: Once a TLPT engagement is initiated, fairly strict deadlines must be respected. In particular, upon finishing the RT execution phase, each of the report delivery milestones has a specific deadline to adhere to.

• Restoration Procedures: The RTS includes a number of restoration procedures external testers should carry out, including:
  • command and control deactivation;
  • scope and date kill switch(es);
  • removal of backdoors and other malware;
  • potential breach notification;
  • procedures for future back-up restoration which may contain malware or tools installed during the test;
  • monitoring the blue team activities and informing the control team of any possible detections.

    The first two procedures should be adhered to by default from the start of the execution. However, a few others are not always possible to accomplish for the red team (e.g. removal of a backdoor in case access has been remediated by the blue team). In many cases, the Control Team will need to be involved. The existing TIBER specification does not make mention of such procedures yet, so we might see additional guidance in the next update.

• Test Scenarios: The proposed scenarios need to differ with reference to the identified threat actors and associated TTPs and have to target each and every critical or important function in the scope of the TLPT. The control team must select at least three scenarios to conduct the TLPT.

The specification does not say anything about the number of critical functions that have to be part of the scope. It “only” requires all functions that have been defined as part of the scope to be included in a scenario as well, with at least 3 scenarios being performed.

We have seen exercises with just 3 critical functions (and limited underlying systems) included in the scope, as well as exercises with 10 critical functions (and multiple underlying systems), resulting in large differences regarding the number of possible objectives or flags. With the aforementioned requirement, there will likely be more consistency regarding the scope size and a finer selection of critical functions.

• Reporting to authority: After reports and remediation plans have been agreed upon, the financial entity and external testers (if relevant) have to provide a summary of the relevant findings, the remediation plans and the documentation to the authority. The purpose is to demonstrate that the TLPT has been conducted in accordance with the requirements.

This also appears to be a stricter requirement, since there have been many TIBER engagements where we did not perform reporting to the TCT; instead leaving it to the discretion of the WT which information would be shared.

The European Central Bank (ECB) has released a publication dated to September 26^th of 2024 to confirm that by adopting the TIBER-EU framework, competent authorities will equip themselves and financial entities to perform sound TLPT and thereby meet the DORA requirements for such tests.

As mentioned in our previous blog post, the TIBER-EU framework can be considered a handbook or set of detailed guidelines (i.e. the “HOW”) on completing DORA TLPT (i.e. the “WHAT”) in a qualitative, controlled and safe manner – one which is consistent and uniform throughout the EU.

Building on TIBER-EU offers multiple benefits:

• Guidance and Best Practices: The TIBER-EU and country-specific implementations offer extensive documentation and additional guidance for managing TLPT.
• Experience and Knowledge: TLPT can leverage the experience of various national authorities that have already adopted the framework.
• Knowledge Sharing: Through the TIBER-EU Knowledge Centre, authorities can share knowledge, experiences, and coordinate initiatives.

While the TLPT RTS does come with some additional requirements or nuances compared to the TIBER framework, we can all be certain that adopting TIBER is indeed  the way to fulfill DORA’s TLPT requirements. As mentioned in our initial post, we expect many more European countries to publish a TIBER implementation guide and/or a TIBER-EU 2.0 to be published for additional convergence.

Want to know how we can help you with TIBER or TLPT? Visit the ARES team website or reach out directly.

About the author