Cybersecurity Archives - Prism Infosec

The Cost of a Breach

Posted on 25th June 2025 by Prism Infosec

IBM’s 2024 Cost of a Data Breach report, identified that the average cost of a data breach in the UK reached £3.58 million, and that this cost had increased 5% since 2023.

Verizon’s 2025 Data Breach Investigation report, suggested there was a 37% increase in ransomware attacks being reported, with a median payout of $115,000 paid by 36% of victims, of which 88% were smaller businesses. Keep in mind, this is just the cost of decrypting the ransomware, when you consider lost productivity, reputational risk, shareholder losses, service impacts, and potential fines, the cost skyrockets.

Even the European Union Agency for Cybersecurity (ENISA) has published a report discussing the impact of cyber security breaches, and highlights the impacts of such breaches across the financial sector; this reporting will only increase now that the Digital Operational Resilience Act (DORA) has come into force.

The news so far this year has identified a number of significant breaches: M&S, Co-Op, Harrods, Cartier, and North Face. More could be on the horizon, and the expectation is that this trend will only continue upwards.

Organisations do have tools to help them prepare for and potentially prevent these sorts of issues. Companies such as Prism Infosec offer red team engagements, where for a fraction of the cost of dealing with a breach, we can simulate how these threat actors operate, and help the organisation identify how they could be attacked, what they can do about it, and exercise how they would respond if or when this occurs, to minimise the impact, disruption, and damage these actors profit from. If your organisation is serious about managing the risk of being breached, then do reach out to us at Prism Infosec: Cyber Security Testing and Consulting Services so we can discuss how we can help secure your business.

ENISA Threat landscape: Finance sector

2025 Data Breach Investigations Report | Verizon

Cost of a data breach 2024 | IBM

AI and Red Teaming

Posted on 23rd June 2025 by Prism Infosec

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.

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!

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.

Capitalising on the Investment of a Red Team Engagement

Posted on 3rd December 2024 by Prism Infosec

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/

How to Protect the Business Against a Data Breach/Ransomware

Posted on 16th January 2023 by Prism Infosec

Threats to the business can come in various forms but by far the most common and significant is a data breach. Usually leveraged via a successful phishing or spear phishing attack, this then results in either sensitive information (such as a username and/or password) being disclosed or a compromise of target endpoints such as laptops or mobile devices

Both attack vectors could then see unauthorised remote logins to organisational services or data, which an attacker can then use to exfiltrate sensitive information. This could include personal data (names, addresses, dates of birth, medical data et al), banking details, credit card information, or company intellectual property.

The information will then either be sold (usually at a price per record), used to target other individuals with fraudulent attacks, or be associated with a ransomware situation where either it may then be permanently encrypted and/or released publicly if the attackers do not receive payment within a certain time. Over the last few years, it’s this latter scenario that has come to dominate, as organised criminal gangs become more adept at extorting funds from targets.

Are you prepared?

Yet, despite the dearth of data breaches reported year after year, organisations still fail to prepare for what is rapidly becoming almost inevitable. If the business isn’t ready, it can’t respond effectively or communicate with internal and external stakeholders such as customers and clients, C-Suite and third-party organisations such as the ICO. This results in a loss of confidence and unwanted publicity, as well as the organisation spending unnecessary time resolving incidents effectively and the potential financial loss of paying the ransom.

To protect themselves from such attacks, organisations should implement a variety of defences. It’s important to deliver regular security awareness programs to staff, warning of the risk of clicking on unknown links or opening files or attachments, for instance, but these need to be regularly scheduled and be appropriate. The most effective security awareness briefings will be relatively succinct and interesting to staff, for example by containing relevant and interesting examples of the potential impacts, rather than being a lecture.

With regards to technical security controls, the business should implement endpoint and cloud-based protection which can protect against known and new attacks and as well as monitoring and alerting systems to facilitate rapid identification and reporting of any potential attempts and actual breaches within the business environment. Also, put in place strong endpoint configuration that limits the privileges of users, restricts the execution of unknown and untrusted applications and reduces the attack surface through reduction of unnecessary functionality (Command Prompts, Powershell, default bundled software etc).

Locking down data is essential so ensure that data storage is resilient to unauthorised attempts to modify files, using techniques such as inherent versioning and/or offline data snapshots and backups. Remain vigilant through the implementation of monitoring and alerting mechanisms across server, endpoint and cloud environments and keep things fresh through regular security reviews of device endpoints and data storage and applications to test their resilience to ransomware attacks.

If the worst does happen, you’ll want to rely on an effective incident response plan being in place as well as team preparedness, having conducted scenario-based penetration testing (“red team”) attack simulations as well as desktop simulated breach exercises to ensure that the security teams know how to handle breaches quickly and effectively.

Policy and process

However, it cannot be overstated how important it is to have a reasonable and applicable (to the business) set of security policies, procedures and plans to support information security and to govern user behaviour.

An overarching information security policy should put security centre stage and reveal the management commitment to it as well as prescribing a framework of other documents such as an acceptable use policy, incident response plan, access control and data handling policies. Many organisations are now already aligned or certified to standards such as ISO27001, which provides a framework for management of an information security management system (ISMS).

Be Proactive

Finally, be proactive. Regularly review the data that is being collected and stored by the organisation, whether on-premise or in the cloud, assess its importance to the business and ensure that there are suitable controls in place to protect it from exposures and loss. Ensure that offline backups, snapshots, and/or data versioning exist and consider the impact of data being deleted, encrypted or leaked. Regularly advise your staff on existing and new cyber security threats, and consider future and evolving attacks such as voice/messaging attacks, as detection of email based phishing attacks forces attackers to seek alternative avenues.