Blog Posts Archives - Page 2 of 5

Data Hygiene

Posted on 20th June 2025 by Prism Infosec

Most organisation’s that are breached and compromised are done so not because they are lax with security, have poor patching, or are gambling that they will never be a victim; instead they usually suffer from poor data hygiene.

Users store data on desktops, in shared folders, in online repositories (such as Jira, SharePoint, Confluence, etc.), sometimes without appropriate controls, encryption, or consideration for who else may have access to it. As a result, threat actors who establish a foothold will often spend time sifting through these data repositories, harvesting credentials and testing if they are valid and what damage they can cause with them. This is a tactic we use in red teams to great success for completing objectives. The days of needing to throw zero days and exploits to compromise networks is not quite done, but why would any threat actor waste burning an exploit when an organisation’s data hygiene is poor and they can get all the credential material they need to threaten the organisation just by looking in accessible file stores?

Unfortunately hunting across corporate data stores for poorly secured passwords is not easy, in all my years of testing I’ve not seen a single solution that is 100% effective at this. Instead it often requires multiple sweeps, policies, user education, users being provided with appropriate tools and guidance, amnesty periods, and if all else fails, disciplinary measures to fix this sort of issue. Often it is not addressed until after a breach occurs, and even worse is that most firms don’t realise how bad the situation might be.

At Prism Infosec, we conduct red teams, where we do some analysis of your data hygiene and can help you address issues we find.

DORA TLPT Guidance Update

Posted on 18th June 2025 by Prism Infosec

Today the EU provided the long awaited updated guidance in relation to DORA’s TLPT: DORA TLPT Guidance Update

This 30 page document further clarifies the necessity for Threat-Led Penetration Tests (TLPTs) under DORA.

We will be posting a more in-depth post about this in the very near future, but the key points that should be taken away are:

Who can Invoke a TLPT?

DORA’s TLPT requirements mirrors the TIBER-EU methodologies, process and structures – they will use the same structure for overseeing DORA TLPT’s as TIBER-EU engagements and will be overseen by either EU or national level authorities. The authorities are defined as those who are the single designated public authority for the financial sector; or an authority in the financial sector who has been authorised and delegated to manage TLPTs; or any competent authorities referred to in Article 46 of Regulation (EU) 2022/2554.

Who is in scope for a TLPT?

It will be down to the national or EU wide authorities to determine who will be in scope for a TLPT test; however the guidance is clear that it should be restricted to entities for which it is justified. This can include financial entities that operate in core financial services subsectors, as long as a TLPT cannot be justified for them.

Ultimately this means it will be down to the regulator’s discretion as to whether or not a TLPT should apply for any financial organisation and will be taken on a case-by-case basis. This will be based on the overall assessment of an organisation’s ICT (Information and Communications Technology) risk profile and maturity, the impact on the financial sector and of related financial stability concerns which must meet qualitative criteria.

In Article 2 of the update the specific requirements for the identification of financial entities required to perform TLPTs are defined. Essentially the authorities will consider the following factors:

The size of the entity
The extent and nature of the financial entities connections with other entities in the financial sector of one or more EU member states.
The criticality or importance of the services the entity provides to the financial sector
The substitutability of services the entity provides
The complexity of the entity’s business model
The entity’s role in a wider enterprise with shared ICT systems

The authorities will also consider the following ICT risk-related factors:

The entity’s risk profile
The threat landscape for the entity
The degree of dependence their critical/important/supporting functions have from ICT systems
The complexity of the entity’s ICT architecture
The entity’s ICT services which are supported by third parties (including the quantity and contractual arrangements for third party and intra-group service providers)
The outcomes of any supervisory reviews relevant for assessment of the ICT maturity of the entity
The maturity of ICT business continuity plans and the ICT response and recovery plans
The maturity of ICT detection and mitigation controls
And whether the entity is part of group that is active in the financial sector of the EU that shares ICT systems.

The expectation is that that TLPT will be required for entities such as:

credit institutions, payment and electronic money institutions, central security depositories, central counterparties, trading venues, insurance and reinsurance undertakings. The definitions for these types of entities is included in the update and many will be related to their definition in other EU articles (all referenced), or in relation to total payment transactional amounts within a 2 year calendar period, or for entities which provide undertakings for gross written premiums (GWPs) or technical provisions above specified levels. It should be noted however that these same entities could be excused from a TLPT if the authority agrees it is inappropriate.

The authority is also required to consider points such as market share positions, and the range of activities the financial entity provides when making this assessment.

Furthermore, that criteria must also be applied and assessed in light of new markets as they enter the financial sector, such as crypto asset service providers authorised under Article 59 of Regulation (EU) 2023/1114 of the European Parliament and of the Council.

Shared ICT Service Providers

The guidance also touches on financial entities that have the same ICT service provider. In those cases it will be down to the regulator as to whether a shared or entity level assessment is conducted, if a TLPT is deemed necessary.

If a TLPT is deemed as required by the authority, then the financial entity will be contacted and clearly presented with the authority’s expectation with regards to testing.

This regulation update will come into force 20 days after its publication (8th July 2025), so after this date is when entities could be contacted by letter from authorities notifying them of the requirement to conduct a TLPT test.

Additional Notes

Much of the rest of the regulation update covers the delivery of a TLPT in regards to roles, responsibilities, and expectations for TLPT providers (both Threat Intelligence and Red Team/Penetration testers). It also covers the basic expectations for financial entities being tested with regards to secrecy, procurement and scoping of the TLPT engagements. We will touch on those topics in more detail in a later blog post.

TIBER-BE Insights

Posted on 16th June 2025 by Prism Infosec

The TIBER-EU framework is designed to help organisations improve their Cyber resiliency.

It has multiple stages: initiation (scoping, procurement, planning), threat intelligence, penetration testing (red teaming), purple teaming (attack replays, additional untested control tests, variances in attack methodologies working alongside the Blue team), and closure (reporting, remediation plans, attestation).

As a framework, TIBER can be used by any organisation, even though it was created for financial institutions. However, using the framework does not make your organisation compliant for the regulator or with DORA unless it is supported by an EU TIBER regulator team, and a TIBER test manager.

This information was presented and discussed at the NBB (National Bank of Belgium) TIBER-BE TLPT (Threat-Led Penetration Testing) launch event. The morning session was only for institutions who are, or will be undergoing a TIBER to inform of them of the framework. Prism Infosec were invited to the event as suppliers, and joined other suppliers and the institutions to mingle and attend relevant presentations.

The NBB TIBER-BE team discussed their implementation of TIBER and how it will align with DORA. At present additional guidance on the TLPT element of DORA is still pending (and has been since February), though is expected at some point in June, which should help clarify the TLPT phase, requirements and implementation in greater detail. Until that arrives, DORA compliant TLPT exercises cannot begin.

During the TLPT launch event there were a number of presentations. These included a keynote from the newly formed Belgian Cyber Force, a presentation on NIS2, the Belgian Cyber Fundamentals (CyFun) framework (looks like the UK’s Cyber Essentials) and was linked to the Belgian Centre for Cybersecurity who have a role similar to the UK’s NCSC and can support Belgian entities during cyber incidents.

We also had a presentation on how one multinational Belgian organisation had implemented their own internal red team, what they learned along the way and importantly, how they measured and showed to the board how the organisation’s maturity and capability to defend itself improved over time.

The panel discussion contained a number of useful insights, from a variety of c-suite level individuals, some of which had been through TIBER and others who were waiting to go through TIBER. They shared insights into how to plan for and prepare for engagements, suggesting organisations prepare by doing a small red team before their TIBER to understand the process. They recommended choosing scenarios where you will get key learnings and do as much preparation for contingencies (leg ups, backup accounts, information) as you can.

These presentations, panels, and even the quiz were all backed by networking discussions over food and softdrinks.

All in all, it was an insightful and useful event!

Cyber Threats & The Boardroom

Posted on 13th June 2025 by Prism Infosec

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

Posted on 11th June 2025 by Prism Infosec

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

Posted on 9th June 2025 by Prism Infosec

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

Posted on 6th June 2025 by Prism Infosec

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.

The Cyber Security and Resilience Bill – April 2025

Posted on 30th April 2025 by Prism Infosec

In the King’s Speech it was announced that further details would follow about the CSR Bill, and it looks like we now have the confirmed and proposed measures:

Cyber Security and Resilience Bill: policy statement – GOV.UK

These have been proposed by both MPs and the Department for Science, Innovation and Technology (DSIT) and backed by the NCSC:

Cyber Security and Resilience Policy Statement to… – NCSC.GOV.UK

The bill looks to enhance the Network and Information Systems (NIS) 2018 Regulations:

The NIS Regulations 2018 – GOV.UK

Which was aimed at providing legal measures for improving the security (both physical and cyber) of IT systems for the provision of digital and essential services (online marketplaces, online search engines, cloud computing services) and essential services (transport, energy, water, health, and digital infrastructure services). Twelve regulators were identified as responsible for enforcing those regulations.

The major policy proposals and changes being introduced with the CSR not only increase the number of entities covered by NIS 2018, but also enhances the powers of these regulators, whilst aligning the UK, where appropriate with the approach taken in the EU’s NIS 2 directive:

Directive – 2022/2555 – EN – EUR-Lex

Understanding the Proposed UK Cyber Security Policy Changes

The UK government has laid out potential changes to its cyber security policy, aiming to bolster the nation’s resilience against evolving digital threats. These proposals encompass a range of measures designed to broaden the scope of regulation, strengthen supply chain security, and empower regulatory bodies. Here’s a breakdown of the key elements under consideration:

Expanding the Regulatory Framework

A significant aspect of the proposed changes involves bringing more entities under the umbrella of cyber security regulations.

Bringing More Entities into Scope: The policy seeks to extend its reach to organizations that play a crucial role in the digital ecosystem.
Managed Service Providers (MSPs) to be Regulated: Recognizing the critical access MSPs have to client IT systems and their potential vulnerability to cyber-attacks, they will now be subject to regulation.
- Definition of MSPs: The policy defines MSPs as entities that:
  - Provide IT-related services to external organizations (not in-house).
  - Deliver services reliant on network and information systems.
  - Offer ongoing management, administration, or monitoring of IT infrastructure, networks, and cyber security activities.
  - Include network access or connection to a customer’s systems.
- Regulatory Alignment: MSPs will be required to adhere to the same duties as digital service providers (RDSPs), with the Information Commissioner’s Office (ICO) acting as their regulator.

Strengthening Supply Chain Security

The proposals also place a strong emphasis on securing the digital supply chain.

New Duties for OES and RDSPs: Operators of essential services (OES) and RDSPs will face new obligations to actively manage cyber risks within their supply chains.
Designation of ‘Critical Suppliers’ (DCS): Regulators may designate certain suppliers as ‘Critical Suppliers’ (DCS), even if they are small firms, if a disruption to their services could significantly impact essential or digital services.
- Criteria for DCS Designation (Proposed, Not Yet Agreed): A supplier could be classified as a DCS if:
  - It provides goods or services to OES or RDSPs.
  - Disruption to its services would have a significant effect on the delivery of essential or digital services.
  - Its operations depend on network and information systems.
  - It is not already subject to similar cyber security regulations.
- Obligations for DCSs: Once designated, DCSs will be subject to the same security and reporting requirements as OES and RDSPs.

Empowering Regulators & Enhancing Oversight

The proposed policy aims to equip regulatory bodies with greater authority and tools to effectively oversee cyber security practices.

Technical and Methodological Security Requirements: It is proposed that security requirements will be aligned with the National Cyber Security Centre’s (NCSC) Cyber Assessment Framework (CAF). Additionally, the Secretary of State may issue sector-specific codes of practice to tailor standards.
Improving Incident Reporting: The scope of reportable incidents will be broadened to include those impacting data confidentiality, integrity, and availability. Furthermore, a two-stage reporting process is being introduced:
- An initial notification within 24 hours.
- A comprehensive report within 72 hours.
- Reporting will be mandatory to both the relevant regulator and the NCSC.
- Firms will also be obligated to alert affected customers following significant incidents.
Strengthening ICO’s Information Powers: The ICO will be granted enhanced powers to proactively gather information, enforce registration requirements, and new channels will be established for other bodies to share threat intelligence with the ICO.
Improving Cost Recovery for Regulators: The proposed bill seeks to allow regulators to set fees, publish their charging principles, and consult with the industry. This aims to address cash flow issues and alleviate cost burdens on taxpayers.

Keeping Pace with Emerging Threats

The policy acknowledges the dynamic nature of cyber threats and the need for adaptability.

Delegated Powers: The Secretary of State will be granted the authority to update regulations through secondary legislation, following consultation. This is intended to enable swift responses to evolving threats and technological advancements.

Additional Measures Under Consideration

Beyond the core elements, the proposed bill also includes additional measures that may be incorporated later, depending on legislative opportunities:

Regulating Data Centres: Data centres with a capacity of ≥1MW (or ≥10MW for enterprise-only use) could be recognized as Critical National Infrastructure (CNI) in 2024 and brought under regulation. This is estimated to affect approximately 182 data centres and 64 operators.
Statement of Strategic Priorities: The Secretary of State could publish a statement outlining strategic priorities for regulators every 3–5 years. This aims to ensure a consistent national cyber security strategy across different sectors and regulatory bodies.
Powers of Direction (National Security): The bill might be expanded to grant the Secretary of State the power to:
- Direct entities to take specific actions against particular cyber threats.
- Instruct regulators to tighten sector-specific guidance.
- It is anticipated that these powers would only be invoked when necessary and proportionate to address national security concerns.

These proposed policy changes represent a significant step towards strengthening the UK’s cyber resilience in an increasingly complex digital landscape. Businesses and organizations across various sectors should pay close attention to the development and implementation of this legislation.

Roles & Responsibilities

As can be seen above, the bill will affect several entities, we have tried to summarise this into the following table:

Entity Type	Definition / Characteristics	Role & Obligations
Managed Service Providers (MSPs)	– Provide services to other organisations (not in-house) – Rely on network/information systems – Involve ongoing IT system management or monitoring – Have network access	– Newly regulated – Same duties as RDSPs – Must follow cyber security and incident reporting requirements
Relevant Digital Service Providers (RDSPs)	– Digital services like online marketplaces, search engines, cloud providers	– Already regulated under NIS 2018 – Subject to enhanced incident reporting and transparency duties
Small & Micro RDSPs	– Smaller digital service providers currently exempt	– May be regulated if designated as a Critical Supplier
Operators of Essential Services (OES)	– Organisations providing essential national services	– Existing regulation under NIS – Will have new duties to manage supply chain risk
Designated Critical Suppliers (DCS)	– Supplier to OES or RDSP – Disruption could significantly affect service – Relies on IT/network systems – Not regulated elsewhere	– Will be brought under regulation – Must meet security and incident reporting standards
Data Centres (Proposed)	– Facilities hosting data infrastructure – Thresholds: ≥1MW capacity (general), ≥10MW (enterprise)	– Expected to be included – Duties include registration, risk management, and incident reporting
Regulators	– ICO and sector-specific bodies	– Enforce the regulations Gain stronger powers for oversight, cost recovery, and cyber threat monitoring

Summing Up

Ultimately, the impact of the CSR will be wide-ranging. It will seek to provide stronger protection of critical services, enhance supply chain security, improve regulatory oversight and capabilities, improve incident response, provide regulator flexibility and some futureproofing, and improve national security and government readiness. The cost for businesses which have not previously fallen under these requirements, both in meeting these new obligations and in complying with them, will be high. However, when compared to the cost of a breach and disruption to these services, not just to the organisation but to the wider supply chain and country will be significantly higher.

Prism Infosec’s cybersecurity services, already work with several regulated industries and regulators, if you would like to discuss this with us, please feel free to reach out.

Prism Infosec Achieves CBEST Accreditation

Posted on 20th January 2025 by Prism Infosec

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?

Posted on 7th January 2025 by Prism Infosec

The Digital Operational Resilience Act (DORA) is a European legislative act that will be applied from the 17^th 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.

Risk Management – Chapter 2, Articles 5 to 16
Incident Reporting – Chapter 3, Articles 17 to 23
Digital Operational Resiliency Testing – Chapter 4, Articles 24 to 27
ICT Third Party Risk – Chapter 5, Articles 28 to 44
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.