DORA Digest August 2024

Public consultation feedback 

The ESAs conducted a public consultation to gather feedback on the draft RTS. Respondents generally supported the cross-sectoral approach, which promotes uniformity and simplicity across the EU and has proven effective by TIBER-EU. 

Concerns were raised about the complexity and ambiguity of the text, with practitioners seeking more clarity and outreach from regulators. 

Second batch of RTS/ITS published 

On 17 July 2024, the ESAs published the second batch of level 2 rules under DORA. This includes RTS and implementing technical standards (ITS) on major incident reporting and TLPT, among others. 

These rules aim to provide clarity on the reporting framework for ICT-related incidents, including timelines, templates, and requirements for threat-led penetration testing. 

The final draft level 2 rules on subcontracting have not yet been published, which remains a critical area for financial entities and IT suppliers. 

Implementation and compliance 

As we are all no doubt aware by now, financial entities are required to comply with DORA by 17 January 2025. There is significant pressure on financial entities to implement the necessary changes, with concerns about readiness and the short timeline for compliance. 

The main concerns expressed by respondents regarding the DORA RTS on TLPT were: 

• Requirements for TLPT providers: Respondents were particularly concerned about the requirements applying to both testers and threat intelligence providers. 
• Complexity and ambiguity: There were concerns about the complexity and unclear language in the RTS, with practitioners seeking more clarity from regulators. 
• Timeframes: Respondents requested more time, particularly for the closure phase of testing. 
• Organisational structure: Smaller organisations expressed concerns about the feasibility of establishing multiple independent teams (control team, control team lead, blue team, and purple team) due to limited people resources and organisational structure. 
• Proportionality: There were calls for applying proportionality to the requirements associated with the testing process, reflecting the varying size, profile, and information and communication technology (ICT) resources of financial entities. 
• Scope and mutual recognition: The RTS had unclear language regarding how a TLPT authority would consider the scope or relevance of a test for, “the facilitation of mutual recognition.” 
• Criteria for selecting insurance and reinsurance undertakings: There were concerns about the predictability of criteria used to select these entities for performing TLPT by default. 

In response to these concerns, the ESAs made several changes to the draft RTS, including:  

• revising the criteria for selecting insurance and reinsurance undertakings;  
• clarifying processes for pooled and joint TLPTs; and  
• revising requirements for testers and threat intelligence providers to allow for more flexibility, while maintaining appropriate risk management measures. 

The ESAs addressed the concerns about the requirements for TLPT providers in the following ways: 

• Revised criteria for testers and threat intelligence providers: The ESAs introduced changes to allow for more flexibility while maintaining appropriate risk management measures. This includes different criteria on experience levels required from TLPT providers. 
• Greater flexibility: The final draft RTS allows for the engagement of testers who may not fulfil all the criteria, provided the risks have been appropriately mitigated. This change aims to address concerns about the strict requirements previously proposed. 
• Risk management focus: While introducing more flexibility, the ESAs maintained a focus on appropriate risk management measures. This approach balances the need for qualified providers with practical considerations raised by respondents. 
• Clarifications on processes: The ESAs provided clarifications on processes related to TLPTs involving several financial entities and/or ICT service providers, including intragroup or third parties in pooled TLPTs and joint TLPTs. 
• Extended cooperation: The changes require extended cooperation between the three involved TLPT authorities for cases involving multiple entities or service providers. 

These adjustments demonstrate that the ESAs took into account the feedback received during the consultation process and made efforts to address the concerns raised by respondents while maintaining the overall integrity and effectiveness of the TLPT framework under DORA. 

Recommendations for financial entities required to perform TLPT 

Based on our experience of performing these exercises, we recommend that financial entities without past experience of TLPT and entities that want to refine their approach consider the following: 

• Objectives and goals: It is not the main aim of a TLPT to find all vulnerabilities. The main aim is to understand the most likely attack path a threat actor will use to breach an organisation. This knowledge can help organisations understand the performance of protective and detective controls against such threat actors. We highly recommended that organisation should at least have mature phishing controls and vulnerability management controls prior to undertaking TLPT to understand more complex attack paths and possible gaps in associated protective and detective controls. 
• Threat intelligence data provider: Organisations should aim to partner with a threat intelligence (TI) data provider that is not only on top of the latest developments but has a team with hands-on experience in active incident response. While some providers rely on open-source data, which depends on the accuracy of third-party collection and processing, a partner that gathers and analyses data directly from active cases offers a distinct advantage. Such providers can deliver insights and information that may not be publicly available, offering a more comprehensive and reliable perspective on emerging threats.  
• Red team services provider: Selecting a partner that offers both TI and red team services allows for collaboration that significantly enhances the effectiveness of the TLPT. By having these services under one roof, the exchange of information between the two teams becomes more streamlined. As a result, the overall security assessment is more precise, cohesive, and likely to yield better outcomes. 
• Social engineering capabilities: A primary goal of a red team is to gain initial access to an organisation, and this is usually by any means necessary. The most common entry is via targeted phishing (spear phishing), but not always as it will depend on the threat intelligence received. If your organisation is likely to be targeted by an advanced persistent threat (APT) group, a physical break-in may be required. This tests an organisation’s controls by introducing a less-common initial access vector that may allow attackers to remain undetected once in the network. Consider asking your red team provider if it is possible for them to run this kind of test for you. 
• Communications during a TLPT: Due to the nature of a TLPT engagement, organisations need to ensure all stakeholders involved have multiple methods of communication available. This will allow teams to react, manage and capture all the events happening during the engagement and ensure reporting is accurate.  
• Blue team detections: TLPT engagements are not just about a red team meeting its objectives and providing a report on its activities. It is essential that the organisation collects every event carried out in a red team and works with the blue team/security operation centre (SOC) to map detections and log any deficiencies. This will allow the organisation to ensure it can improve its security posture. 

Our Cyber Risk team is available 24/7 to help with all aspects of cyber incident preparation, regulatory compliance, penetration testing, threat intelligence, incident response, eDiscovery and more. Find out more about Thomas Murray TLPT services and cyber advisory services.