Philip Pearson, Field Chief Information Security Officer at Aqua Security, discusses how meeting operational resilience targets is crucial for effective cybersecurity measures.
Operational resilience is the ability to prevent, withstand, recover, adapt and learn in the face of disruption, including cyber events.
Currently, it represents a far-reaching set of issues that are increasingly important to private sector organisations and lawmakers alike. In both the EU and the UK, stronger regulatory frameworks are evolving, accompanied by serious consequences for those who fail to comply.
For instance, the Digital Operational Resilience Act (DORA) and the NIS2 Directive are two major pieces of European cybersecurity legislation aimed at strengthening operational resilience and cybersecurity across various sectors, including finance. While they share common goals, they focus on different aspects and have distinct scopes of application.
Designed to strengthen IT security across a wide range of financial entities, DORA comes into force in early January 2025.
It focuses heavily on improving resilience “in the event of a severe operational disruption.” It is relevant to financial services industry organisations that supply services inside the EU. Failure to comply can result in penalties of up to 2% of the total worldwide revenue for any organisation found to be in breach.
For any business leaders that operate within the parameters set out by GDPR, the jurisdiction rules will have a familiar ring about them, and the UK’s position outside of the EU will, for many organisations, be an irrelevance.
The NIS2 Directive has been active since January last year. It aims to improve the level of cybersecurity protection across the EU, with an emphasis on harmonising security requirements and reporting obligations. In addition, it encourages member states to integrate new areas, such as supply chain security, vulnerability management and cyber hygiene, into their national cybersecurity strategies. The Directive also promotes improvements in knowledge sharing, collaboration, the development of an EU-wide vulnerability registry, a Crises Liaison Network and improved cooperation, among other measures.
The role of Critical Third Parties in meeting operational resilience targets
In the UK specifically, regulators have looked closely at the role played by Critical Third Parties (CTPs) – external organisations whose services are vital to the operational integrity and operational resilience of financial institutions. CTPs could include cloud service providers such as AWS or Microsoft and a range of other technology businesses that play a key role in supporting the sector. Additionally, the Cross Market Operational Resilience Group, chaired by the Bank of England, provides detailed guidance on operational resilience for the financial services sector, which, whilst not legally binding, acts as a good base for best practice.
Our recent survey conducted at the Cloud & Cyber Security Expo at Tech Show London in March with 100+ cloud professionals indicated that awareness remains low around new compliance obligations. Nearly half – 46.5 % – were unsure of their organisation’s ability to comply with supply chain regulations and frameworks such as NIS 2 or SBOM. And of those respondents who work in the finance sector, 30% were unaware of the Digital Operational Resilience Act (DORA). Just over a third – 35% – were confident of their organisation’s ability to comply.
Additionally, the shift towards cloud-native technologies, with their distributed systems and microservices architectures, presents a new set of challenges for regulatory compliance and operational resilience. This environment, characterised by dynamic resource scaling to meet demand, introduces complexities in maintaining compliance amidst the fluid nature of containerised deployments and autoscaling practices.
Autoscaling, a hallmark of cloud-native environments, allows for efficient resource management but necessitates a nuanced approach to operational resilience. The ability of systems to automatically adjust resources complicates adherence to stringent regulatory frameworks, requiring organisations to adopt innovative monitoring and management strategies that align with the fluid dynamics of cloud-native operations.
How can organisations be compliant, secure, and agile simultaneously?
So what impact are these regulations making (or will they make) in practical terms, and what technology priorities should organisations address to ensure compliance?
Across the current financial industry ecosystem, for example, there is an increasing reliance on the provision of agile, scalable and reliable applications, with Kubernetes and DevOps among the platforms and methodologies playing an important role in software development and delivery strategies. In this context, resilience and security are – understandably – key considerations.
Operational resilience ensures that organisations working with Kubernetes and cloud environments deploy robust, secure infrastructure and applications capable of swiftly recovering from disruption. This includes implementing best practices for Kubernetes security, ensuring high availability and disaster recovery capabilities, and effectively managing third-party risks associated with cloud service providers.
Operational resilience in these environments also involves continuous monitoring, incident response planning, and regular testing of recovery procedures to ensure that the organisation can maintain its critical functions under a variety of adverse conditions.
In relation to DevOps, which has become a widely adopted software development methodology globally, security can be improved by integrating advanced measures directly into development and deployment processes. This includes implementing ‘Compliance as Code’, which integrates automated compliance checks within the CI/CD pipeline.
The most effective approaches enforce compliance policies and regulatory requirements directly in the infrastructure as code (IaC) templates and container configurations. This ensures that every deployment automatically adheres to necessary compliance standards, reducing manual review processes and the potential for human error.
This should be accompanied by the use of immutable security policies for containerised applications and Kubernetes clusters. By defining strict security policies that cannot be altered once a container or service is deployed, this approach ensures that any attempts to change the security posture can only be made through the CI/CD pipeline, enforcing consistency, audibility, and compliance with existing security standards.
Looking more closely at the issues associated with CTPs or the wider supply chain, the creation of a Software Bill of Materials (SBOM) is a critical component in ensuring the security and integrity of software applications and their dependencies. This approach is increasingly relevant in the context of broader cybersecurity strategies and compliance with regulatory requirements such as DORA and is important for several reasons:
- Transparency: SBOMs provide a clear, comprehensive view of an application’s software components, including open-source and third-party libraries. This transparency is vital for assessing software products’ security posture and compliance
- Vulnerability management: With an SBOM, organisations can quickly identify which components might be affected by newly discovered vulnerabilities. This capability allows for rapid assessment and remediation, significantly reducing the window of exposure to potential threats
- Compliance and reporting: Regulatory frameworks, including DORA, increasingly recognise the importance of understanding and managing the risks associated with software supply chains. SBOMs facilitate compliance with such regulations by documenting the use of components and ensuring that they meet the required security standards
- Risk assessment: SBOMs enable organisations to perform detailed risk assessments of their software inventory, identifying potential security and compliance issues. This proactive approach supports DORA’s ICT risk management requirements by enabling financial entities to manage and mitigate risks associated with their software supply chain
- Incident response: In the event of a security incident, having an SBOM allows for a quicker and more accurate determination of impact, supporting effective incident response strategies as outlined in DORA
However, while SBOMs provide a comprehensive inventory of all the components present in a software application, including those that may not be actively loaded into memory or called during runtime, these inactive components can still pose security risks.
Inactive but vulnerable components could potentially be used as part of an exploit chain or become an active threat later if the application’s functionality changes over time.
Therefore, SBOMs are a critical tool for risk management in the supply chain, but they must be part of a larger holistic security. It’s essential to consider the security implications of all components within a software application, even if they are currently unused. Maintaining a comprehensive SBOM and regularly reviewing it for vulnerabilities, even in inactive parts, are crucial security practices.
Additionally, alongside utilising SBOMs, organisations must take a more comprehensive approach to vulnerability management, including continuous monitoring, prioritisation, and proactive remediation.
Organisations must act now to stay ahead of the curve and ensure compliance with emerging regulations. Some concrete steps they can take include:
- Educate staff on the requirements of DORA, NIS2, and other relevant regulations and take steps to assess the current level of compliance
- Engage with industry peers, regulatory bodies, and security experts to stay informed about best practices and evolving threats
- Develop a roadmap for enhancing your security posture, prioritising initiatives that align with regulatory requirements and their overall business objectives
- Partner with trusted security vendors and service providers who can provide the expertise, tools, and support needed to implement effective security measures and maintain compliance over time
Looking ahead, these represent just some of the key considerations for organisations operating in and around the finance industry ecosystem. In a climate where the role of regulation seems likely to increase even further, organisations that can integrate security into their development processes now will be better placed to adopt future changes in regulation as they emerge.
It’s essential to consider the security implications of all components within a software application, even if they are currently unused. Maintaining a comprehensive SBOM and regularly reviewing it for vulnerabilities, even in inactive parts, are crucial operational resilience practices.
