Implementing the Digital Operational Resilience Act Using Secure Cloud Development

In the scope of application development, compliance with the Digital Operational Resilience Act Compliance (DORA) can be efficiently implemented with Secure Cloud Development Environments (CDE) such that it jointly enables data security and developer experience. We explain how this is achieved in this brief article.

Published: July 26, 2024

Author:Laurent Balmelli

Implementing the Digital Operational Resilience Act Using Secure Cloud Development

Operational Resilience and Cloud-Based Development

Cloud Development Environments (CDEs) allow organizations to migrate the application development process online. It also enables them to rethink operational resilience in this context.
In this discussion, I explore how requirements such as the ones laid out by the Digital Operational Resilience Act (DORA) can be covered efficiently by financial organizations with a Cloud-based development approach by using a platform to manage CDEs.
Since DORA is mostly about ICT risk management and security controls, DORA’s requirements have to be covered with a CDE platform that provides native data security mechanisms such as this one.
The main outcome of this analysis is the set of capabilities necessary to cover DORA. Hence by the end of this article, you should be able to understand both DORA’s requirements and the capabilities delivered by a secure CDE platform.
Let’s start by reviewing what DORA’s requirements are about.
In short, DORA aims to enhance digital operational resilience in EU’s financial services, as well as in ICT third-party service providers, by establishing a unified framework for managing ICT risks. This regulation harmonizes ICT risk management across EU member states, ensuring consistent and robust security standards for entities and their critical third-party technology service providers.
It establishes technical requirements across four domains of interest related to the governance of an application development process, namely (1) ICT risk management and governance, (2) incident response and reporting, (3) operational resilience testing, and (4) third-party risk management.
four domains of the DORA proposal
Figure: In the present discussion, four domains of the DORA proposal are discussed in the scope of an application development process.
In the rest of this text, I review each of these domains and review the necessary capabilities for a secure platform for Cloud-based development that are leveraged to address each of the domain’s requirements.
For conciseness, I sort out platform capabilities under four categories: (1) secure development, (2) resource orchestration, (3) audit and reporting, and (4) platform control and integration.

ICT Risk Management Using Cloud Development Environments

To cover this first domain, entities need a comprehensive ICT risk management framework, conduct risk assessments, document cyberthreats and mitigation steps, protection measures, and ensure business continuity and disaster recovery plans.
In essence, Cloud-based development brings a centralized mechanism to manage coding environments and access data necessary to developers. In addition, a secure CDE platform aims at protecting the development assets such as source code, data and access credentials. This article explains in detail how this is achieved.
This is in contrast to CDE platforms such as Codespaces, Google Workstations, OpenShift DevSpaces and others (smaller players such as GitPod, Coder, etc) that only focus on delivering an IDE and a coding environment, but do not provide any measure against data leaks.
Hence as a first core capability, centralization and securing of all developer services across the development workflow significantly enhances the opportunity for good ICT risk management and governance for the development process.
This is because classically, data in such a process is usually scattered across developers’ laptops, as shown in the left part in the next figure. In the right part, the platform (orange boundary in figure) acts as a centralized access mechanism for development environments. The centralization of services allows organizations to strengthen the governance of security mechanisms. The platform is usually self-hosted in a private Cloud so that organizations retain data control. The new setting has no impact on access to common DevOps, e.g. CI/CD tools as shown in the right side of the figure.
Figure: (left) Locally installed development environments access online DevOps applications, (right) Environments are now accessed as online resources.
Local development environments access online DevOps applications
As a result, organizations can standardize development environments and ensure uniform risk management practices, such as the identification and classification of critical assets, enforce technical controls, etc. In addition the immediacy brought by managing development environments online enables continuous risk assessments.
A second necessary capability is to provide a single control plane to manage development environments across multiple infrastructure providers, in conjunction to allocating computational resources for these environments in a way that optimizes user experience and cost.
Resource orchestration and allocation via a single control plane
Figure: Resource orchestration and allocation via a single control plane across several Cloud providers enable operational resilience.
This functionality is key to providing operational resilience against business disruptions to the aforementioned centralization of services and support business continuity and disaster recovery.
To cover the first domain, CDE capabilities that increase the organization’s compliance maturity with DORA’s requirements around ICT risk management and governance are summarized here:
    • Secure Development
    • Centralized management and securing of development environments.
    • Centralized and secured access to data and services, e.g. code repositories, CI/CD pipelines, security functions, etc.
    • Resource Orchestration
    • Single control plane for multi-Cloud allocation resources.
    • IT optimization via multi-region resource assignment.

CDE’s Support For Incident Response and Reporting

To cover the requirements of the second domain, organizations need to establish systems for monitoring, managing, logging, classifying, and reporting ICT-related incidents, including to regulators, affected clients and partners.
Managing development environments online brings a native capability for real-time monitoring and detection of security incidents over an entire workforce. Most importantly, the entire workforce’ environments are at reach for monitoring, inspection and evidence collection, including threat detection in environments (e.g. indicators of compromise) using third-party applications, systematically installed on environments by leveraging the opportunity to standardize environments’ composition using templates. In particular, a secure platform for Cloud Development Environments enables such interactions in a monitored and secure manner, as explained in this article.
These capabilities replace the need in a classical setting to install agents on each developer’s device to retrieve information, and significantly decrease the cost of maintenance for such a mechanism while improving governance. In collaborative settings, setting up such an agent and collecting data might even not be possible.
Overall, environment accessibility plays a critical role in systematically recording and analyzing incidents, thereby enhancing the response process. Typically, incident data as logs is exported in a SIEM tool via the Common Event Format, which assists in conducting thorough root cause analyses.
Platform’s environment accessibility plays a critical role
Figure: Platform’s environment accessibility plays a critical role in recording and analyzing incidents and connecting to a SIEM for continuous governance.
Part of the Information sharing requirements in DORA can be implemented from the integration between the platform and the SIEM, so that relevant information can be retrieved from the analysis of the platform logs. .
In conjunction to the CDE capabilities discussed so far, the additional ones below contribute to building maturity around incident response and reporting:
    • Audit and Reporting
    • Centralized network and user activity logging across environments, services and DevOps/SDLC applications.
    • Audit and evidence collection from environments, e.g. process activity, IoC detection, etc.
    • Platform Control and Integration
    • Support for secure integration and interaction with third-party tools such as SIEM tools, DevSecOps services, etc.
    • Application Programming Interface (API) to general remote control of the platform functionalities.

Benefits of Cloud-Based Environments for Resilience Testing

The purpose of resilience testing is to evaluate the strength of an entity's protections against various ICT-related risks and to identify potential vulnerabilities within their information and communication technology (ICT) systems.
In the scope of a development process, resilience testing applies both to the infrastructure, i.e. protect the process against data exfiltration, and the assets such as code and data, that ought to be protected against the infiltration of vulnerabilities. The latter can happen either via developer-induced or supply chain breaches, though a compromised SBOM.
This is holistically achieved through two distinct CDE capabilities: (1) provide data loss prevention (as discussed earlier), and (2) the integration of the platform with third-party software such as DevSecOps tool suites to handle attacks on assets.
In DORA, resilience testing includes vulnerability assessments, scenario-based testing, and threat-led penetration testing (TLPT). In all, entities must show their operational integrity and reliability amidst disruptions, such as ICT service failures, natural disasters, and cyberattacks.
Like in the previous domain, the online environment’s accessibility allows consistency when automating resilience tests, such as vulnerability assessments and scenario-based testing, in particular through the integration of third-party tools for DevSecOps. For example, it is easy to automate the scanning of the environment’s software composition for vulnerabilities such as Common Vulnerabilities and Exposures (CVE), as shown in the next figure. This ensures a comprehensive evaluation of the ICT infrastructure's strength and resilience, in this case, the development environment.
Vulnerability scanning software can be integrated to secure CDEs
Figure: Vulnerability scanning software can be integrated and consistently applied at the environment’s access time, i.e. before starting coding activities.
In conjunction to the CDE capabilities listed so far, these additional ones below contribute to maturity around resilience testing:
    • Secure Development
    • Data loss prevention measures.
    • Integration to DevSecOps services such as scanning, dependency management, etc.
    • Audit and Reporting
    • Audit of environment compositions for vulnerabilities.
    • Auditing of zero-trust access control policies.

Third-Party Risk Management Using a Secure CDE Platform

Cloud-based development is clearly an enabler for collaborative settings, in the same way as the advent of online code repositories and DevOps services have fostered a distributed approach to set-up a development workforce. In a previous article, I coined that organizational change as setting up a trusted liquid workforce.
In the context of application development, DORA requirements related to third-party risk management range mainly across three scenarios: managing software suppliers, software integrators, and collaborations with third-parties. In addition to managing ICT risks as in the first domain, a specific set of requirements attached to the present domain and relevant to the present discussion fall under oversight and monitoring.
All these above collaboration scenarios benefit from CDE capabilities reviewed so far such as centralized management, security against data exfiltration, automation of security controls, etc. Let’s look at additional capabilities that are essential in ensuring governance in collaborative settings.

Securing SaaS Suppliers in Development and Production

In addition to providing software components, suppliers increasingly provide access to services via a SaaS model.
These services can be used during the development process, or while running the developed application as part of delivered functionality. In both settings, services can be integrated via the capability discussed in the first domain, namely secured access to data and services. The capability is refined to cover the present domain to secure access to services using a zero-trust implementation (next figure). Again here, oversight and monitoring can be easily realized due to the service centralization and online access.
Access to resources via Zero-Trust and micro-segmentation
Figure: Access to resources via Zero-Trust and micro-segmentation brings essential security in a collaborative setting, in conjunction with a RBAC model and resource isolation, e.g. on a project or organization basis.

Securing Software Integrators and Collaborative Development

In the context of managing software integrators, a fine-grained Role-based Access Control Model (RBAC), coupled with access micro-segmentation (typically part of the Zero Trust implementation) are necessary to apply a least-privilege access principle and secure against data extraction from temporary or off-shore employees.
Here too, environment accessibility enables continuous monitoring of the integration process, tracking the integrator's adherence to security standards.
Finally, an important capability is the ability to segment access to data resources also across organizations and projects. Data and service access isolation, fine-grained network policies for environments, as well as role-based project assignment to participants are key to support an efficient governance of a collaborative development process. The above figure illustrates two collaborative projects (circled environments in the cloud) and how they benefit from these last capabilities. For example, the leftmost developer has distinct roles (hence permissions) in the two projects.
All the CDE capabilities listed in the previous parts are clearly beneficial to support collaborative development. In addition, I summarize the ones reviewed here:
    • Secure Development
    • Role-based/attribute-based access control model to manage diverse collaboration scenarios.
    • Zero-trust, micro-segmented access to data repositories and supplier services.
    • Platform/organization/project-level segmentation and access control of development resources.
    • Audit and Reporting
    • Reporting of access to resources across cross-organization teams.
    • Fine-grain audit of network access using environment-based policies.

DORA Compliance Using Secure Cloud Development

CDE capabilities that I reviewed here are important to effectively, both technically and economically, address DORA's operational resilience requirements, especially for financial institutions dealing with software suppliers, integrators, and third-party collaborations.
The four categories, namely secure development, resource orchestration, audit and reporting, and platform control and the specific capabilities that I reviewed provide an implementation roadmap for compliance with the four requirement domains, precisely in the scope of a development process.
A key takeaway is that, because a secure Cloud Development Environment platform combines both the efficiency of CDEs and security against data leaks, its use for DORA compliance results in significant reduction in implementation cost and complexity.
---
All material in this text can be shared and cited with appropriate credits. For more information about our platform, please contact us at hello@strong.network
Copyright © 2020-2024 Strong Network All rights reserved.

Recomended Reads