Cyber Threats & The Boardroom

In cybersecurity, the prevalent and growing threat from criminals is ransomware operations. This is where a threat actor manages to establish a foothold into an organisation, will try to position themselves to gain control of the organisation’s data, will often steal some or all of that data, and then encrypt as much of it as they can. They will then contact the organisation and demand payment to restore that data, often they will also use the stolen data they have in their possession to prove their access, and use it to blackmail the organisation into paying, or sell it on to other threat actors. Regardless of the outcome, the impact to the organisation is usually severe with losses to share price, customer confidence, massive operating cost increases, and additional supply chain knock on effects. These attacks have crippled many organisations and the number of attacks continues to grow. They cannot be treated as purely an IT department issue and often sit as a risk with the board.

The UK and the EU have started to take steps to raise the priority of defending against these sorts of issues through DORA (the EU Digital Operational Resilience Act) and the CSR (the UK’s Cyber Security and Resilience Bill). These empower regulators and appropriate bodies to take action against firms that fail to address specific threats, sometimes with significant fines. Whilst many organisations do invest in security systems, they have insurance, and they even sometimes have third party incident response retainers, properly exercising those systems is often seen as too costly and too impactful for the business. This is unfortunately short-term thinking, as most organisations have no idea how effective these systems actually are until they are tested under fire and fully utilised to determine if what is down on paper, will match reality should the worst happen. It’s a bit like installing a fire alarm in a house but never actually testing it to see if it works, and instead just hoping it will if a fire breaks out.

In Red Teaming simulations, companies like Prism Infosec will often assume the role of these real world threat actors to help an organisation understand how vulnerable they are to these sorts of attacks, and to help them exercise their incident and response systems. This gives an organisation the ability to understand how staff and their systems react if a threat actor manages to gain a foothold.

These simulations however are only effective when the executive body of an organisation engage with them to understand the identified risks, and put emphasis on addressing them.

Passwords

NIST, like the NCSC have updated their password guidance. It is now no longer advisable to set them to be random strings of nonsensical letters, numbers and symbols. The focus is now on password length, by stringing together multiple words. Inclusion of uppercase, and symbols or numbers is still helpful, to make them even harder for threat actors to guess. It is also no longer advisable to rotate passwords frequently – instead, passwords should be checked against known bad lists and breaches should be monitored. If the password is identified in those lists, or an incident occurs with the associated account, then it should be rotated.

Frankly it’s about time these caught up with the realities of the real world. Users will often choose weak but easy to remember passwords, and deliberately craft them to match password complexity rules. Often these will be incremented by a digit when a forced expiry occurs. This makes them extremely weak and vulnerable – especially once the pattern is identified!

At Prism Infosec we often don’t need to breach systems with fancy exploits due to poor credential management practices. We often get asked to help clients conduct credential audits by performing cracking exercises and testing against known bad lists to support them whilst they are updating their internal guidance and strategy.

Updated guidance:

NIST Special Publication 800-63B

Password policy: updating your approach – NCSC.GOV.UK

DORA

The Digital Operational Resilience Act (DORA), the EU regulation that came into force in January 2025, and affects financial entities and their suppliers mandates Threat-Led Penetration Testing (TLPT), alongside Risk Management for third parties, information sharing and incident reporting. The full impact of DORA’s requirements is still be absorbed by the industries it affects, and the full implications of getting all of these systems tested to meet compliance has yet to be realised, with elements such as the The TLPT element is still being worked through, but we do know that TIBER tests will satisfy the requirements, and that financial entities will only use testers for carrying out TLPTs, that:

  • Are of the highest suitability and reputability;
  • Possess technical and organisational capabilities and demonstrate specific expertise in threat intelligence, penetration testing and red team testing;
  • Are certified by an accreditation body in a Member State or adhere to formal codes of conduct or ethical frameworks;
  • Provide an independent assurance, or an audit report, in relation to the sound management of risks associated with the carrying out of TLPT, including the due protection of the financial entity’s confidential information and redress for the business risks of the financial entity;
  • Are duly and fully covered by relevant professional indemnity insurances, including against risks of misconduct and negligence.

At Prism Infosec, we not only meet these requirements with our accreditations as a CBEST, STAR-FS and STAR TLPT supplier in the UK, but we are also recognised by the National Bank of Belgium’s TIBER-BE team as a supplier of TLPT services.

Regulation – 2022/2554 – EN – DORA – EUR-Lex

The Quantum Spectre at the Banquet

Quantum is tipped to be the next big thing in computers, and it has been for some time – in fact it was first conceived in the 1980s; however the issue was not really considered until the mid-1990s. Now, it’s seen as a potential game changer in the world of cryptography, where the world’s secrets will be laid bare and the privacy will be compromised unless we can develop post-quantum cryptography.

Unlike present day computers, which use bits (1s and 0s – basically on and off) for representing states, quantum computers use qubits (these can be both 1 and 0 simultaneously – a state known as superposition) which are considerably more efficient and permit the computer to conduct complex parallel calculations faster than traditional computers, exponentially faster. In theory, a calculation that would take a present-day computer millions of years to find, a quantum computer could do in minutes.

The technology though has a few issues, for one, qubits are extremely fragile, environmental factors can interfere with them, and as a result they need specialised architecture and error correction to compensate, and for the technology to actually threaten cryptography as it currently exists, it will need considerably more qubits than we currently are capable of building into our architectures. The most qubits we can currently create in a stable architecture is about 1000, whilst NIST theorises that in order to properly threaten cryptography potentially millions of qubits would be needed and they would need to operate in a near error free state – something we are nowhere near close to reaching.

This does not mean we should be complacent; we also need to be practical. The cost and technology for a threat actor to build a practical quantum computer is still some significant time away, and when we start to reach that threshold, it will likely lie in the space of militaries and governments seeking to gain strategic advantages over their rivals. In practical cybersecurity terms quantum is viewed as a theoretical threat that may well eventually manifest, but it’s a next decade problem in a present-day world of patching and data hygiene issues. Whilst it is right we should be mindful and challenge vendors to consider how they will address quantum; we also need to avoid doom mongering and hype by staying focussed on the issues that we currently have rather than focus on possible problems in a decade.

Prism Infosec Appoints Andrew Turner as Chief Commercial Officer 

Cybersecurity consultancy Prism Infosec, with offices in Cheltenham and Liverpool, is pleased to announce the appointment of Andrew Turner as its new Chief Commercial Officer (CCO)

Andrew brings a wealth of experience in cybersecurity and commercial leadership. He holds a degree in Computer Information Systems Design from Kingston University and most recently served as Vice President of Sales, EMEA at VikingCloud. Prior to that, he held senior commercial roles at leading cybersecurity consultancies including F-Secure and Context Information Security, where he was instrumental in driving growth and expanding market presence. 

“The opportunity to join a business like Prism, with its outstanding technical capabilities and prestigious client base, presents a fantastic platform for growth,” said Andrew. “I’m excited to work alongside the team to develop new service offerings, strengthen existing client relationships, and expand into new verticals where our specialist approach can deliver real value.” 

In his role as CCO, Andrew will lead the development of Prism Infosec’s commercial strategy, focusing on scaling the business and deepening its footprint within the FTSE 250 and other key markets. His appointment marks a significant step in the company’s growth journey. 

“We’re thrilled to welcome Andrew to the leadership team,” said Phil Robinson, CEO at Prism Infosec. “He brings a deep passion for cybersecurity, along with a proven track record of building high-performing teams, delivering commercial value, and consistently exceeding client expectations. Andrew’s experience in scaling businesses will be instrumental as Prism Infosec continues to grow. His strategic insight and commercial acumen have helped organisations expand into new markets, strengthen client relationships, and drive sustainable revenue growth.”

Recent Breach News

Marks & Spencer and the Co-Op have suffered a brutal breach in the recent few weeks, the full scale of which is still unknown. 

It should be clear that whilst the attack has been attributed to SCATTERED SPIDER, a group made infamous for their breach of the MGM casinos in Las Vegas in September 2023[1], a lot of speculation has been made about the exact attack methodology they used to gain a foothold in, and ultimately compromise Marks & Spencer, but no real information has been shared about the exact methodology to date. In the past, this group have been known to use several social engineering tactics to trick helpdesks, or to use sim swapping to compromise MFA, but it is not yet known what they did in this case.

What is known is that the breach has resulted in significant share price drops, loss of earnings from online ordering systems (with some estimates placing this at up to £3.5m per day[2]), and tertiary impacts to third parties Marks & Spencer do business with. Anonymised media report suggest that Marks and Spencer’s incident response plan was inadequate for the extent of the breach they have suffered, and indications are that customer information may have been compromised in the breach. The full cost of the breach is yet to be fully assessed, but recent media reports suggest the insurance claim could come in at £100 million[3]

Neither Marks & Spencer or the Co-Op were thought to be overly lax in their cybersecurity however, securing an enterprise the size of these organisations, with the number of staff they employ and contract with, the complexity of their supply chains, is exceptionally challenging.

Whilst it is far too early to conduct a root cause analysis of the breach and a lessons learned exercise, all organisations should sit-up and take note. They should be asking themselves when they were last properly assessed with a simulated threat actor attack (a red team), or even when they last fully exercised their incident response playbooks (not just a tabletop) for an attack of this magnitude but invoking it and testing disaster recovery.

Prism Infosec understands these challenges and complexities, and we can help, not just test your plans but also help clients improve them and support them in the event of a breach.


[1] MGM cyber attack: How a phone call may have led to the ongoing hack | Vox

[2] Empty shelves at M&S as store faces losses of ‘millions each day’ in wake of cyber attack | ITV News

[3] Financial Times – M&S Insurance Claim article

Prism Infosec Launches Vulnerability Remediation Service

Prism Infosec is proud to announce the launch of a remediation service line that will enable organisations to promptly implement effective fixes for vulnerabilities identified during engagements. The remediations service connects organisations with Prism Infosec’s team of IT and security experts to deliver tailored solutions that address  vulnerabilities while ensuring compliance with industry standards and minimising operational disruptions.

Through leveraging Prism Infosec’s in-depth understanding of vulnerabilities and effective mitigation strategies, organisations can take advantage of a comprehensive vulnerability management service spanning from discovery to resolution, working collaboratively with our teams to develop and implement effective remediations.

Often, after an engagement, organisations are left burdened with the challenging task of resolving a large number of complex vulnerabilities and configuration issues, without the necessary expertise or resources to effectively address them. Prism’s remediation service aims to alleviate this challenge by providing a dedicated team of IT and security professionals to guide organisations from discovery to resolution.

“Post-engagement, organisations often find themselves at a crossroads, with identified vulnerabilities but no clear path to remediation. Naturally, we are seeking to bridge that gap between discovery and resolution by providing an end-to-end service that leaves organisations confident with their security posture. We’re delighted to build on our reputation further by leveraging our extensive in-house talent to deliver more value to our clients through remediation services.” – Ollie Stepney, Head of IT & Remediation Services at Prism Infosec.

Our remediation services will be available to our clients as an extension of engagements, providing a natural progression from the identification and assessment phases. This approach ensures that organisations can immediately begin addressing vulnerabilities without any gaps. Remediation services will also be available as an offering within our Cyber Security as a Service platform, LuxisAI and via direct engagement as organisations look to improve their security posture in support of any certification or regulatory requirements.

“I am delighted that Prism Infosec has developed the in-house capability to support our clients with remediation services following the end of a security test or consultancy engagements. Always working in partnership with our clients, we understand that there is much to do beyond assessments and audits and sometimes remedial activity can lead to complex and/or overwhelming challenges to solve. Prism Infosec will support our clients every step of the way in partnership to ensure that vulnerabilities and weaknesses are appropriately addressed and without introducing new security risks.” – Phil Robinson, CEO at Prism Infosec.

Key to the remediation service, expansive documentation offers transparency throughout the process. Recognising the value in not only resolving vulnerabilities but also providing detailed information about the issues addressed, the reasoning behind the fix, and the specific steps taken to remediate. This comprehensive documentation allows organisations to gain a deeper understanding of their vulnerabilities, the recommended mitigations for them, and best practices moving forward.

If you are interested in learning more about our remediations service and how it can benefit your organisation, please contact your account manager or email us at remediations@prisminfosec.com for more information. 

Prism Infosec Achieves CBEST Accreditation

Prism Infosec, an established CHECK accredited Penetration Testing company, is pleased to announce that we have achieved accreditation status as a Threat-Led Penetration Testing (TLPT) provider under the CBEST scheme, the Bank of England’s rigorous regulator-led scheme for improving the cyber resiliency of the UK’s financial services, supported by CREST.

This follows our recent accreditation as a STAR-FS Intelligence-led Penetration Testing (ILPT) provider in November 2024, and . These accreditations put us in a very exclusive set of providers in the UK who have demonstrated skills, tradecraft, methodology, and the ability to deliver risk managed complex testing requirements to a set standard required for trusted testing of UK critical financial sector organisations.

Financial Regulated Threat Led Penetration Testing (TLPT) / Red Teaming

The UK is a market leader when it comes to helping organisations improve their resiliency to cyber security threats. This is in part due to the skills, talent, and capabilities of our mature cybersecurity sector developed thanks to accreditation and certification schemes introduced originally by the UK CHECK scheme for UK Government Penetration Testing in the mid-2000s. As the UK matured, new schemes covering more adversarial types of threat simulations began to evolve for additional sectors.  Today, across the globe, other schemes have been rolled out to emulate what we in the UK have been delivering for financial markets since 2014 in terms of resiliency testing against cyber security threats. This post examines two of the financial-sector oriented, UK based frameworks – CBEST and STAR-FS, explaining how they work, and how Prism Infosec can support out clients in these engagements. 

What is CBEST?

CBEST (originally called Cyber Security Testing Framework but now simply a title rather than an acronym) provides a framework for financial regulators (both the Prudential Regulation Authority (PRA) and Financial Conduct Authority (FCA)) to work with regulated financial firms to evaluate their resilience to a simulated cyber-attack. This enables firms to explore how an attack on the people, processes and technology of a firm’s cyber security controls may be disrupted. 

The aim of CBEST is to:

  • test a firm’s defences; 
  • assess its threat intelligence capability; and
  • assess its ability to detect and respond to a range of external attackers as well as people on the inside. 

Firms use the assessment to plan how they can strengthen their resilience.

The simulated attacks used in CBEST are based on current cyber threats. These include the approach a threat actor may take to attack a firm and how they might exploit a firm’s online information. The important thing to take away from CBEST is that it is not a pass or fail assessment. It is simply a tool to help the organisation evaluate and improve its resilience.

How does CBEST work?

A firm is selected for test under one of the following criteria:

  • The firm/FMI is requested by the regulator to undertake a CBEST assessment as part of the supervisory cycle. The list of those requested to undertake a review is agreed by the PRA and FCA on a regular basis in line with any thematic focus and the supervisory strategy.
  • The firm/FMI has requested to undertake a CBEST as part of its own cyber resilience programme, when agreed in consultation with the regulator.
  • An incident or other events have occurred, which has triggered the regulator to request a CBEST in support of post incident remediation activity and validation, and consultation/agreement has been sought with the regulator.

CBEST is broken down into phases, each of which contains a number of activities and deliverables:

When the decision to hold a CBEST is made, the firm is notified in writing that a CBEST should occur by the regulator, and the firm has 40 working days to start the process. This occurs in the Initiation Phase of a CBEST. A Firm will be required to scope the elements of the test, aligned with the implementation guide, before procuring suitably qualified and accredited Threat Intelligence Service Providers (TISP), and Penetration Testing Service Providers (PTSP) – such as Prism Infosec.

After procurement there is a Threat Intelligence Phase, which helps identify information threat actors may gain access to, and what threat actors are likely to conduct attacks. This information is shared with the firm, the regulator and the PTSP and used to develop the scenarios (usually three). A full set of Threat Intelligence reports is the expected output from this phase. After the Penetration Test Phase, the TISP will then conduct a Threat Intelligence Maturity Assessment. This is done after testing is complete to help maintain the secrecy of the testing phase.

The next phase is the Penetration Testing Phase – during this phase each of the scenarios are played out, with suitable risk management controls to evaluate the firm’s ability to detect and respond to the threat. During this phase, the PTSP works closely with the firm’s control group and regular updates are provided to the regulator on progress. After testing, the PTSP then conducts an assessment of the Detection and Response (D&R) capability of the firm. Following these elements, the PTSP will then provide a complete report on the activities they conducted, vulnerabilities thy identified and the firm’s D&R capability.

CBEST then moves into the Closure phase where a remediation plan is created by the firm and discussed with the regulator and debrief activities are carried out between the TISP, PTSP and the regulator.

The CBEST implementation guide can be found here:

CBEST Threat Intelligence-Led Assessments | Bank of England

What is STAR-FS?

Simulated Targeted Attack and Response – Financial Services (STAR-FS)

STAR-FS is a framework for providing Threat Intelligence-led simulated attacks against financial institutions in the UK, overseen by the Prudential Regulation Authority (PRA) and the Financial Conduct Authority (FCA). STAR-FS has less regulatory oversight in comparison to CBEST, but uses the same principles and is intended to be conducted by more organisations than CBEST. Like CBEST, STAR-FS uses the same 4 phase model.

How does STAR-FS work?

STAR-FS has been designed to replicate the rigorous approach defined within the CBEST framework that has been in use since 2015. However, STAR-FS allows for financial institutions to manage the tests themselves whilst still allowing for regulatory reporting. This means that STAR-FS can be self-initiated by a firm as part of their own cyber programme. Self-initiated STAR-FS testing could be recognised as a supervisory assessment if Regulators are notified of the STAR-FS and have the opportunity to input to the scope, and receive the remediation plan at the end of the assessment.

The Regulator, which includes the relevant Supervisory teams, receives the Regulator Summary of the STAR-FS assessment in order to inform their understanding of the Participant’s current position in terms of cyber security and to be confident that risk mitigation activities are being implemented. The Regulator’s responsibilities include receiving and acting upon any immediate notifications of issues that have been identified that would be relevant to their regulatory function. The Regulator will also review the STAR-FS assessment findings in order to inform sector specific thematic reports. Aside from these stipulations, the regulator is not involved in the delivery or monitoring of STAR-FS engagements and does not usually attend the update calls between the firm and TISP and PTSPs.

Like CBEST, there are also Initiation, Threat Intelligence, Penetration Testing and Closure phases, and accredited TI and PT suppliers must be used. In the Initiation and Closure phases, the firm is considered to have the lead role, whilst in the Threat Intelligence and Penetration Testing phases, the TISP and PTSPs are respectively expected to lead those elements. Again, a STAR-FS implementation guide is available to support firms undergoing testing:

STAR-FS UK Implementation Guide

How are we qualified to deliver Threat Led Penetration Testing?

Prism Infosec are one of a small handful of companies in the UK which have met the criteria mandated by the PRA and FCA to deliver STAR-FS and CBEST engagements as a Penetration Testing Service Provider. That mandate is that the provider must have, and ensure that engagements are led by a CCSAM (CREST Certified Simulated Attack Manager) and a CCSAS (CREST Certified Simulated Attack Specialist). Furthermore, the firm must have at least 14,000 hours of penetration testing experience, and the CCSAM and CCSAS must also have 4000 hours of testing financial institutions. The firm must also have demonstrated their skills through delivery of penetration testing services for financial entities which are willing to act as references, and must have been delivered within the last months prior to the application.  

How we deliver Threat Led Penetration Testing?

At Prism Infosec we pride ourselves on delivering a risk managed approach to Threat Led Penetration Testing – ensuring we deliver a test that helps us evaluate all the controls in an end-to-end test. Our goal is to help our clients understand and evaluate the risks of a cyber breach in a controlled manner which limits the impact to the business but still permits lessons to be learned and controls to be evaluated. Testing under CBEST, STAR-FS or simply commercial STAR engagements is supposed to help the firm, not hinder it, which is why we ensure our clients are kept fully informed and are able to take risk aware decisions on how best to proceed to get the best results from testing.

Prism Infosec will produce a test plan covering the scenarios, the pre-requisites, the objectives, the rules of the engagement and the contingencies required to support testing. A risk workshop will be held to discuss how risks will be minimised and agree clear communication pathways for the delivery of the engagement.

As each scenario progresses, Prism Infosec’s team will hold daily briefing calls with the client stakeholders to keep them informed, set expectations and answer questions. An out of band communications channel will also be setup to ensure that stakeholders and the consultants can contact each other as necessary, should the need arise. At the end of each week, a weekly update pack outline what has been accomplished, risks identified, contingencies used and vulnerabilities identified will be provided to the stakeholders to ensure that everyone remains fully informed.

Once testing concludes, Prism Infosec would seek to hold a Detection and Risk Assessment (DRA) workshop which comprises of two elements – the first a light touch GRC led discussion with senior stakeholders to provide an evaluation of the business against the NIST 2.0 framework; the second is a more tactical workshop with members of the defence teams to examine specific elements of the engagement. This second workshop is invaluable for defensive teams as it helps them identify blank spots in the defence tooling, and gain understanding to the tactics, techniques and procedures (TTPs) used by Prism Infosec’s consultants.

Following this, Prism Infosec will produce a comprehensive report on how each scenario played out, severity rated vulnerabilities, a summary of the DRA workshops and information on possible improvements to support and assist the defence teams. We will also produce an executive debriefing pack and deliver debriefing tailored to c-suite executives and regulators. We will also provide a redacted version of the report which can be shared with the regulator, as required under CBEST.

DORA – What Does it Mean for Business?

The Digital Operational Resilience Act (DORA) is a European legislative act that will be applied from the 17th  of January 2025 and will apply to all financial entities (except for microenterprises).

It is designed to strengthen European financial entities against cyber-attacks and ICT (Information and Communication Technology) disruptions. The full original text (in English) can be found here: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32022R2554&from=FR

and a second batch of documents which updated those articles were published here:

https://www.eiopa.europa.eu/publications/second-batch-policy-products-under-dora_en

Whilst DORA was written to focus on financial entities, it also applies to some entities typically excluded from financial regulations. For example, third -party service providers that supply financial firms with ICT systems and services—like cloud service providers and datacentres; they must comply with DORA requirements as they are servicing the financial industries and therefore cannot be excluded. DORA also covers firms that provide critical third-party information services, such as credit rating services and data analytics providers.

DORA Requirements

DORA is composed of five pillars. Each pillar lays out requirements and expectations for different aspects of resilience.

Additionally DORA explicitly defines the responsibility of organisation and governance for the compliance of DORA in an organisation.

  1. Risk Management – Chapter 2, Articles 5 to 16
  2. Incident Reporting – Chapter 3, Articles 17 to 23
  3. Digital Operational Resiliency Testing – Chapter 4, Articles 24 to 27
  4. ICT Third Party Risk – Chapter 5, Articles 28 to 44
  5. Information & Intelligence Sharing – Chapter 6, Article 45

Governance

The financial entity’s management body is responsible for establishing the organisation and governance structure to effectively manage ICT risk. DORA outlines a set of responsibilities and requirements that the management body must fulfil, one of which is for them to enhance and sustain their understanding of ICT risk.

Risk Management

This pillar underlines the need for financial entities to adopt a proactive approach to risk management.

It requires financial entities to precisely identify, assess and mitigate ICT-related risks with robust frameworks in place to continuously monitor key digital systems, data, and connections.

Incident Reporting

This pillar places a strong emphasis on standardising the process of Incident Reporting within the European Union’s financial sector. Under DORA, financial entities are required to implement management systems that enable them to monitor, describe, and report any significant ICT-based incidents to relevant authorities.

It is important to note that the reporting framework must include both internal and external reporting mechanisms:

Internal reporting refers to quickly identifying incidents and communicating them to all important internal stakeholders. Their impact must then be evaluated, and steps put into action for mitigating damage.

External incident reporting refers to alerting regulatory authorities in case of a disruptive incident. For cases such as a data breach, this may also include the affected customers who must be notified if their sensitive financial information has been compromised.

Digital Operational Resiliency Testing

DORA insists that financial institutions periodically assess their ICT risk management frameworks through digital operational resilience testing. Testing must be conducted by either independent parties, either external or internal, but if internal is used then it will be a requirement that the sufficient resources must be allocated and that conflicts of interest are avoided in the design and execution of the tests.

These tests can include:

  • vulnerability assessments and scans,
  • open-source analyses,
  • network security assessments,
  • gap analyses,
  • physical security reviews,
  • questionnaires and scanning software solutions,
  • source code reviews where feasible,
  • scenario-based tests,
  • compatibility testing,
  • performance testing,
  • end-to-end testing
  • penetration testing 

Basic tests like vulnerability assessments and scenario-based tests must be run once a year.

Financial entities however must also undergo threat-led penetration testing (TLPT) at least every three years , and it was confirmed (July 2024) that TIBER-EU framework tests will satisfy this requirement if it incorporates any additional DORA TLPT requirements. The three-year requirement may be relaxed or shortened dependent on the decision of the designated competent authority.

Each threat-led penetration test shall cover several or all critical or important functions of a financial entity, and shall be performed on live production systems supporting such functions. Critical third party service providers are included in the scope of this and are expected to participate; however where participation is reasonably expected to have an adverse impact in the quality of service delivery for customers outside of the financial entity, they can be excluded but only if they enter into a contractual agreement permitting an external tester to conduct a pooled assessment under the director of a designated financial entity.

TLPT can also permits the use internal (if the financial entity is not a significant credit institution) or external testers; however it is a requirement that every three tests, an external provider must be used. Furthermore if internal testers are used, then the threat intelligence provider must be external to the financial entity.

Beyond that, testers must :

  • Have high suitability and reputation;
  • Possess technical and organisational capabilities and specific expertise in threat intelligence, penetration testing and red team testing;
  • Are certified by an accreditation body in a Member State or adhere to formal codes of conduct and ethical frameworks;
  • Provide independent assurance or an audit report in relation to TLPT risk management;
  • Are insured including against risks of misconduct and negligence.

ICT Third Party Risk

This pillar requires financial organisations to thoroughly conduct due diligence on ICT third parties.

It mandates that financial entities maintain strong contracts with their third-party service providers. They must ensure that their partners adopt high standards of digital security and operational resilience. Furthermore, certain ICT service providers can be designated as “critical” for financial entities. These will have even more obligations (further info below).

Article 30 of DORA has an embedded list of contract requirements that financial services will want to implement for ICT service providers but, the bare minimum is this:

  • Clear and complete description of all functions and ICT services to be provided by ICT 3rd parties.
  • Locations (regions or countries) where the contracted/subcontracted functions are to be provided, processed, stored and requirement to notify in advance if that changes
  • Provisions for the availability, authenticity, integrity and confidentiality of the protection of data
  • Provision of ensuring access, recover and return in an easily accessible format of data processed by the financial entity in the event of insolvency of the third party
  • Obligation of the third-party provider to support the financial entity in an ICT incident related to the service provided at no additional cost, or at a cost determined ex-ante.
  • Obligation of the third-party provider to fully cooperate with competent authorities/representatives of the financial entity.
  • Termination rights and min notice period for contractual arrangements
  • Conditions for the participation of third-party providers in the financial entities ICT security awareness programmes.

Financial entities are also expected to document any risks observed with their third-party ICT providers. Importantly, DORA highlights the need for financial organisations to implement a multi-vendor ICT third-party risk strategy.

Critical ICT third-party service providers will be subject to direct oversight from relevant ESAs (European Supervisory Authorities). The European Commission is still developing the criteria for determining which providers are critical. However, at the time of this article, under existing law it is defined as: “a function whose disruption would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or whose discontinued, defective or failed performance would materially impair the continuing compliance of a financial entity with the conditions and obligations of its authorisation, or with its other obligations under applicable financial services legislation”. Those that meet the standards will have one of the ESAs assigned as a lead overseer. In addition to enforcing DORA requirements on critical providers, lead overseers will be empowered to forbid providers from entering contracts with financial firms or other ICT providers that do not comply with the DORA.

Information & Intelligence Sharing

This pillar promotes a collaborative approach to managing cyber threats, ensuring that financial entities can collectively enhance their defences and respond more effectively to incidents.

Supporting Business

Whilst DORA is written with European Financial entities in mind, compliance for organisations outside of the EU providing services to EU Financial Services is a requirement. The designated European authorities and regulators will ultimately oversee the testing and will guide entities in being tested.

At Prism Infosec we are a CREST accredited company, this means we can deliver Threat-Led and Scenario Based Penetration Testing services at the levels expected for DORA compliance. Furthermore we offer GRC, Incident Response, Vulnerability Scanning and Penetration Testing services which align with many of the requirements in DORA’s 5 pillars.

If you want to know more about how we can help with compliance, then please reach out and contact us.

Capitalising on the Investment of a Red Team Engagement

Cybersecurity red teams are designed to evaluate an organisation’s ability to detect and respond to cybersecurity threats. They are modelled on real life breaches, giving an organisation an opportunity to determine if they have the resiliency to withstand a similar breach. No two breaches are entirely alike, as each organisation’s organic and planned growth of their infrastructure. They are often built around their initial purpose before being subjected to acquisitions and evolutions based on new requirements. As such the first stage of every red team, and real-world breach is understanding that environment enough to pick out the critical components which can springboard to the next element of the breach. Hopefully, somewhere along that route detections will occur, and the organisation’s security team can stress test their ability to respond and mitigate the threat. Regardless of outcome however, too often once the scenario is done, the red team hand in their report documenting what they were asked to do, how it went, and what recommendations would make the organisation more resilient, but is that enough?

Detection and Response assessments are part of the methodology for the Bank of England and FCA’s CBEST regulated intelligence-led penetration testing (red teaming). However, their interpretation of it is more aligned at understanding response times and capabilities. At LRQA (formerly LRQA Nettitude), I learned the value of a more attuned Detection and Response Assessment, a lesson I brought with me and evolved at Prism Infosec.

At its heart, the Detection and Responses Assessment takes the output of the red team, and then turns it on its head. It examines the engagement from the eyes of the defender. We identify the at least one instance of each of the critical steps of breach – the delivery, the exploitation, the discovery, the privilege escalation, the lateral movement, the action on objectives. For each of those, we look to identify if the defenders received any telemetry. If they did, we look to see if any of that telemetry triggered a rule in their security products. If it triggered a rule, we look to see what sort of alert it generated. If an alert was generated, we then look to see what happened with it – was a response recorded? If a response was recorded, what did the team do about it? Was it closed as a false positive, did it lead to the containment of the red team?

Five “so what” questions, at the end of which we have either identified a gap in the security system/process or identified good, strong controls and behaviours. There is more to it than that of course, but from a technical delivery point of view, this is what will drive benefits for the organisation. A red team should be able to highlight the good behaviours as well as the ones that still require work, and a good Detection and Response Assessment not only results in the organisation validating their controls but also understanding why defences didn’t work as well as they should. This allows the red team to present the report with an important foil – how the organisation responded to the engagement. It shows the other side of the coin, in a report that will be circulated with the engagement information at a senior level of engagement, and can set the entire engagement into a stark contrast.

The results can be seen, digested and understood by C-level suite executives. There is no point in having a red team and reporting to the board that because of poor credential hygiene, or outdated software that the organisation was breached and remains at risk. The board already knows that security is expensive and that they are risk, but if a red team can also demonstrate the benefits or direct the funding for security in a more efficient manner by helping the organisation understand the value of that investment then it becomes a much more powerful instrument of change. What’s even better is that it can become a measurable test – we can see how that investment improves things over time by comparing results between engagements and using that to tweak or adjust.

One final benefit is that security professionals on both sides of the divide, (defenders and attackers) gain substantial amounts of knowledge from such assessments – both sides lift the curtain, explain the techniques, the motivations and the limitations of the tooling and methodology. As a result both sides become much more effective, build greater respect, and are more willing to collaborate on future projects when not under direct test.

Next time your company is considering a red team, don’t just look at how long it will take to deliver or the cost, but also consider the return you are getting on that investment in the form of what will be delivered to your board. Please feel free to contact us at Prism Infosec if you would like to know more.

Our Red Team Services: https://prisminfosec.com/service/red-teaming-simulated-attack/