Red teaming is still fairly young as far as cybersecurity disciplines go – most of us in this part of the industry have come in from being penetration testing consultants, or have some sort of background in IT security with a good mix of coding and scripting skills to develop tools. Our work often requires us to not only simulate the threat actors as closely as we can, but also manage the risks of our operations to avoid impacting our client’s business. This dichotomy of outcomes (simulating a threat actor who’s objective is to disrupt, whilst simultaneously trying not to disrupt) may seem confusing, but we also need to remember what red team is for. Its to help our clients test their detection and response capabilities. The objective of the red team is almost incidental – it merely sets a direction for the consultants to work towards whilst we determine what our clients can and cannot detect and what they do about it, if a detection occurs. That latter part is where the disruption is more likely to occur but even there, we can manage the risks.
So where does AI come into it? Well, we have all seen the news about AIs going to take over jobs in a number of fields, and red teaming is no different from the fears of this. The problem is, most AI systems these days are just really good guessers – I prefer to think of these things as almost expert systems, instead of a true intelligence. By that, I mean you can train them to be exceptional at specific tasks but if you go too broad with them, they really struggle. They don’t explain themselves; they can’t repeat steps identically particularly well; and they often forget or hallucinate critical elements when faced with large and complex tasks. A red team is a very large and complex series of tasks where forgetting or imagining critical steps will often lead to a poor outcome. Add into that mix, live environments and risk management, and the dangers of impacting a client become uncomfortably high. As a result, I have not yet met a single professional in this industry who would be happy to take the risk of letting a red team run entirely with AI, and I don’t see that changing any time soon.
However, I do see a future in which AIs help co-pilot red teams. By this I mean, that if the privacy concerns can be addressed, I can foresee a point where a private specialist red team LLM AI would be permitted to ingest data the red team acquires during an engagement (such as network mapping information, directory lists, active directory data, file contents, source code, etc.), and having it perform analysis on it. It can then provide suggestions on how the engagement can proceed. This would also have the added benefit of it being able to answer questions rapidly for the red team to help them consider additional attack paths, identify additional issues in the environment, and suggest additional things they could try. It could also quickly confirm if the red team had any interactions with systems within the client environment to deconflict if issues occur. In time I could even see this being an added real-time benefit for client control groups who would be able to interrogate the LLM for quicker results as to what the red team are doing and what has been identified to date.
AI is here now, and its evolving. We can’t really ignore it as it becomes a tool more and more used in everyday lives, and that means we need to find ways to make it work with the concerns we have. I personally feel that pushing them into smaller expert system roles is the right way forward, as this then allows them to fulfil the role of an assistant more fully. We also need to acknowledge that the public models have been trained unethically on source data taken without consent from authors and copyright holders. As their use grows, not only is there a considerable environmental impact, but I believe they will start to show strain in the near future. This is because, as the public further embraces these tools and uses them to generate new content, that AI generated content will also be absorbed by LLMs. This risks us entering a situation where the snake will eat its own tail and turn into the LLMs into an echo chamber, and we will see the quality of their output drop considerably. This will also likely be compounded by people losing critical thinking skills, which ultimately will harm us more than the AIs can help us.
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.
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.
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!
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.
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.
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.
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.
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.
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:
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:
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
– 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.
