Navigating NIS2 and DORA: The "Paved Road" to Secure Development

In today's rapidly evolving digital landscape, European organizations are under increasing pressure to enhance their cybersecurity posture while maintaining agility and innovation. With the introduction of the Network and Information Systems Directive (NIS2) and the Digital Operational Resilience Act (DORA), the stakes have never been higher. Balancing compliance with these regulations and the need for speed in development can seem daunting.

But what if there was a way to turn this challenge into an opportunity. Enter the "Paved Road" approach—a practical, experience-driven methodology that not only enhances cybersecurity but also aligns seamlessly with NIS2 and DORA requirements.

Understanding NIS2 and DORA

NIS2: Securing Critical Infrastructure and Essential Services

The NIS2 Directive aims to improve cybersecurity across sectors deemed essential to the functioning of society, such as energy, healthcare, transport, and digital infrastructure. NIS2 expands upon the original NIS Directive by broadening the scope and introducing stricter security obligations. The key NIS2 requirements include:

• Risk Management: Organizations must establish comprehensive risk management practices that address both physical and digital threats.

• Incident Handling and Reporting: Entities are required to have mechanisms in place for detecting, managing, and reporting cybersecurity incidents promptly.

• Supply Chain Security: NIS2 emphasizes the need for organizations to assess and secure their supply chains, particularly third-party vendors.

• Business Continuity: Continuity plans must be in place to ensure services remain operational in the event of an attack.

• Access Control and Encryption: Strict access management and data encryption must be enforced to safeguard critical systems and sensitive data.
  

DORA: Ensuring Financial Resilience and ICT Risk Management

DORA is tailored to the financial sector, addressing the growing reliance on information and communication technology (ICT) for operational resilience. It introduces a regulatory framework to mitigate ICT risks, ensuring that financial institutions can withstand, respond to, and recover from cyber incidents. The core DORA requirements are:

• ICT Risk Management Framework: Financial institutions must implement robust frameworks for managing ICT risks, including prevention, detection, and recovery measures.

• Incident Reporting: Rapid reporting of significant ICT incidents to the relevant regulatory authorities is mandatory.

• Digital Operational Resilience Testing: Regular testing of systems and controls to validate their resilience against cyber threats is essential.

• Third-Party Risk Management: Organizations must monitor and mitigate risks stemming from critical third-party ICT service providers.

• Governance and Internal Controls: Senior management must be actively involved in overseeing ICT risk management and ensuring compliance with DORA.

NIS2 and DORA Objectives for Software Supply Chain Security

Both NIS2 and DORA recognize that software supply chain security is a fundamental aspect of risk management. Key provisions from both frameworks include:

• NIS2 emphasizes the need for supply chain security and the importance of identifying and mitigating risks posed by third-party suppliers and service providers.

• DORA mandates robust ICT risk management frameworks, with an emphasis on preventing and mitigating risks stemming from third-party software and infrastructure providers.
  

NIS2, DORA and The "Paved Road" Approach to Software Supply Chain Security

The "Paved Road" approach isn't just a set of guidelines—it's a philosophy that weaves security seamlessly into the development lifecycle without compromising speed or innovation. Let's explore how you can integrate this approach effectively within your organization.

• Architectural Alignment

  • To align your development practices with NIS2 and DORA requirements, security must be a foundational design principle. This isn't an afterthought—it’s a proactive strategy to build robust systems from the ground up. For example, for better incident response, implement centralized logging and monitoring systems from day zero to capture data in real time. Such practices allow for quick incident detection and a comprehensive view of your infrastructure, supporting both security needs and compliance requirements.
    

  • Additionally, managing access is crucial. Robust Identity and Access Management (IAM) solutions can effectively control access to your systems, ensuring that only authorized personnel have entry. Alongside IAM, integrating automated audit trails within development pipelines provides an added layer of compliance reporting without creating an extra burden for developers. This alignment not only builds secure systems but also simplifies regulatory compliance, making it a natural part of your development flow.
    

• Policy as Code

  • To ensure your security policies are consistently enforced across environments, consider embracing Policy as Code. Frameworks like Open Policy Agent (OPA) allow you to define policies programmatically, embedding them into your infrastructure and application code. By decoupling policy logic from your application, you gain flexibility and control over how security measures are applied.
    

• Infrastructure as Code (IaC)

  • The rise of Infrastructure as Code (IaC) has transformed how modern infrastructure is built and secured. By using IaC tools like OpenTofu, you can define security controls and configurations directly within your infrastructure templates. This means that best practices—such as enforcing network segmentation, automating encryption, and applying role-based access controls (RBAC)—are baked into your systems from the beginning.
    

  • Integrating security scanning tools into your CI/CD pipelines ensures that your infrastructure is assessed for vulnerabilities and misconfigurations before it ever reaches production. By adopting IaC, you not only create a scalable and repeatable security model but also enforce consistent security standards across your cloud-native environment.
    

• Proactive Incident Management

  • Proactive incident management is at the heart of compliance and resilience. Ensuring comprehensive logging of all activities is a baseline requirement, but it doesn’t stop there. Real-time monitoring tools play a critical role in alerting your team to potential security issues as they arise, giving your security team the visibility they need to act quickly. Regular drills and incident response exercises are equally important—they ensure your team is prepared and that your response mechanisms are effective.
    

  • By practicing proactive incident management, you’re not just putting out fires; you’re developing a culture of readiness and resilience, one that is ready to meet the incident response requirements of both NIS2 and DORA head-on.
    

• Evidencing Compliance

  • Compliance checks can be automated and incorporated directly into Infrastructure as Code (IaC) pipelines, ensuring that every deployment is validated against your security standards. This continuous validation guarantees that no deployment slips through the cracks. 
    

  • With OPA, enforcing these policies becomes a part of your development routine, creating a streamlined process that ensures every piece of code meets security standards before it’s pushed into production.
    

  • Clear, accurate documentation and audit trails are vital to demonstrating compliance. Security activities, decisions, and policies should all be meticulously recorded and easily accessible. It’s equally important to maintain up-to-date policy documents, keeping pace with evolving threats and regulatory requirements. And because security is only as strong as the people implementing it, ensuring that training records for security protocols are maintained helps provide an auditable trail of compliance for both internal use and external audits.
    

• Resilient Response Management

  • In an environment where continuous integration and rapid deployments are the norm, effective incident and crisis management are not just beneficial—they're essential. These plans should go beyond theoretical frameworks; they need to be practical guides that your team can execute confidently. Establishing clear communication protocols for both internal teams and external stakeholders during a crisis is equally important. This ensures that critical information is conveyed accurately and promptly, preventing misinformation and reducing the potential for further damage. Clear communication facilitates quicker recovery by keeping everyone aligned and informed, thereby maintaining trust with customers and partners.
    

  • In addition to robust response management, adopting strategic deployment methodologies can significantly enhance system stability and reduce risks associated with new releases. For example: 
    

    • Blue/Green Deployments: Embrace blue/green deployments whenever possible. This strategy involves running the existing production environment (blue) in parallel with a new version of the application (green). This methodology provides a safety net that allows for immediate rollback if problems are detected.
      

    • Canary Deployments: This technique enables a controlled release of new functionalities to a limited audience before a full-scale rollout. Canary deployments enable your team to test new features in a live environment safely, gather valuable insights, and iterate quickly based on real user interactions.
      

Where to Start? Container Registries and Orchestration

Containers? Really? What happened to the “shift left” approach? Great question! While shifting security left (towards development) is critical for proactively identifying vulnerabilities earlier in the software development lifecycle, starting your journey to secure the software supply chain at the container registry and orchestration level can be equally effective, especially for containerized applications already in production. 

Here’s why this strategy is beneficial:

• Centralized Control and Visibility

  • The Container Registry as a Single Source of Truth: The container registry acts as the central hub where all container images are stored, managed, and distributed. By focusing on security at the registry level, you gain a single point of control and visibility over what’s being deployed to production.
    

  • Orchestration Enhances Policy Enforcement: Kubernetes and other orchestration platforms play a pivotal role in managing and deploying containers. Security policies enforced at this level can ensure that only trusted, scanned, and compliant images make it to runtime.
    

• Prevention of Unauthorized or Vulnerable Deployments

  • Registry-Level Guards: By securing the registry, you can enforce controls like image signing, vulnerability scanning, and policy enforcement to prevent unverified or insecure images from being released into production. For example, tools like Harbor allow you to block images with critical vulnerabilities, ensuring only secure versions are deployed.
    

  • Reducing the Risk of Supply Chain Attacks: Focusing on the registry helps mitigate risks associated with supply chain attacks where compromised or malicious images might be introduced. This becomes especially important as organizations increasingly rely on third-party or open-source containers.
    

• Ensuring Consistency in Security Across Environments

  • Consistent Policies Across Development, Staging, and Production: While shifting left focuses on securing code, starting at the registry and orchestration levels ensures that only compliant containers get deployed across all environments. Policies and security controls that are enforced at the orchestration level apply to all deployments, providing a consistent security baseline.
    

• Runtime Security Is Critical to Threat Mitigation

  • Real-Time Monitoring and Incident Response: The container runtime is where vulnerabilities are actively exploited. While shifting left helps reduce vulnerabilities before they reach production, having security at the orchestration level enables you to detect and respond to threats in real time. For example, integrating tools like Sysdig or Falco at the orchestration level enables the detection of suspicious behavior, privilege escalations, or attacks on running containers.
    

  • Resilience and Self-Healing Mechanisms: Kubernetes and orchestration tools can enforce automated responses to security incidents. For instance, if a container shows abnormal behavior, orchestration tools can automatically isolate, restart, or destroy the compromised container to maintain the integrity of your application and infrastructure.
    

• Automation of Policy Enforcement and Compliance

  • Policies to the Center (Registry/Orchestration): While developers may integrate security checks into CI/CD pipelines (shifting left), the container registry and orchestration layer allow for automated, centralized enforcement of security policies. This includes:
    

    • Policy as Code (OPA): Automatically enforcing compliance policies on images at the registry level.
      

    • Compliance Reporting and Auditing: Orchestration platforms can track deployments, security events, and compliance status, providing audit trails for regulatory compliance.
      

• Practicality and Developer Enablement

  • Reducing Friction for Developers: Focusing on registry and orchestration-level security allows for automated enforcement without placing the entire security burden on developers. This means that security doesn’t hinder the speed of development, and secure defaults are applied automatically.
    

  • Enabling Secure Software Delivery Pipelines: By securing container images and orchestrating secure deployments, you streamline the path from code to production, making it easier for developers to deliver secure software without additional manual steps.
    

DORA Case Study: Architecting Resilience - Integrating Container Security into the Software Supply Chain

Let’s examine how a financial institution subject to DORA might implement a secure container pipeline to comply with regulatory requirements.

• Container Registry Setup:

  • The institution deploys a private container registry with automated vulnerability scanning enabled by Harbor.

  • Images are signed using cosign, ensuring that only verified images are allowed into production. This provides the necessary audit trails for regulatory reporting under DORA.
    

• Access Control:

  • RBAC policies are enforced through integration with OPA, limiting access to container images to specific teams and individuals based on their roles.

  • Logs of all access events are stored for a minimum of five years, meeting DORA’s audit trail requirements.
    

• Orchestration and Monitoring:

  • The financial institution’s Kubernetes cluster is configured with network policies to limit communication between containers to authorized services only, reducing the attack surface.

  • Real-time monitoring is deployed to detect unusual activity at runtime, triggering automated incident responses that include isolating the affected container and notifying the security team.
    

• Incident Reporting:

  • An unauthorized attempt to modify a container image is detected. The system generates an incident report, including a full audit trail of the image’s history, and submits it to the relevant authority within the timeline mandated by DORA.
    

NIS2 Case Study: Hardened Container Security Approach

To meet NIS2 requirements, a critical infrastructure organization needs a comprehensive container security strategy that focuses on the following key areas:

• Risk Management for Containers

  • Using NIST SP 800-190, the organization can develop a robust risk management framework for containers.

  • Integrate automated vulnerability scanning tools such as Trivy into the CI/CD pipeline to continuously scan container images for known vulnerabilities before deployment.

  • Implement tools like Checkov to audit container configurations and ensure compliance with security policies.

  • Adopt an immutable container approach, where containers are replaced rather than patched, reducing the risk of introducing vulnerabilities post-deployment.
    

• Securing the Software Supply Chain:

  • Automatically generate SBOMs for each container image using a tool like Harbor, a container registry that scans dependencies and tracks vulnerabilities in open-source libraries.
    

• Incident Detection and Response

  • Tools like Sysdig and Falco can provide runtime security and monitoring of container environments, allowing the security team to detect suspicious behavior, such as rogue container activity.

  • Implement automated incident response workflows using Kubernetes operators like Anchore, which could isolate or restart compromised containers without disrupting the entire service.
    

• Access Control and Encryption

  • RBAC policies can be enforced at the orchestration level using Kubernetes to ensure that only authorized personnel could access sensitive containers or modify critical infrastructure settings.

  • Secrets such as API keys and credentials were managed externally using Kubernetes Secrets and encrypted with AWS KMS to ensure that secrets were never embedded within container images.
    

•  Business Continuity and Resilience

  • The organization should implement regular backups of container images and persistent volumes. They can also use Kubernetes for self-healing and automatic failover of containerized services to ensure service continuity during disruptions.

  • Critical containerized services should be deployed across multiple regions and availability zones, ensuring that a failure in one zone would not impact overall service availability.
    

• Incident Reporting and Compliance

  • Integrate a centralized logging and monitoring system using ELK Stack to log container activities and incidents in real-time. The system should be configured to generate automatic alerts and reports for compliance with NIS2 mandates.
    

Conclusion

Navigating the complexities of NIS2 and DORA doesn't have to hinder your organization's agility or innovation. By implementing the "Paved Road" to secure development, you can:

• Integrate Security Seamlessly: Make secure choices the path of least resistance.

• Automate Compliance: Embed regulatory requirements into your development process.

• Foster a Security Culture: Encourage collaboration and continuous improvement.
  

Embrace the "Paved Road" and turn regulatory compliance into a catalyst for innovation and resilience in your organization.

Ready to embark on the "Paved Road" to secure development?

Stay ahead of the curve by integrating these practices into your development lifecycle today. Your organization's security, compliance, and innovation depend on it.

About the Author

Francis Ofungwu is the CEO of DevSecFlow, bringing over two decades of experience in cybersecurity, privacy, and AI governance. A recognized thought leader in the field, Francis has spearheaded global cybersecurity programs across finance, public sector, and technology industries, holding key positions at industry giants like GitLab, Salesforce, and Protiviti.

Francis's expertise spans cloud security, compliance, and technology governance, with a track record of successful ISO 27001, PCI-DSS, and FedRAMP certifications. His strategic vision and cross-functional leadership have driven innovation in cybersecurity, making him a sought-after speaker at major conferences like RSA.

With a passion for sharing knowledge, Francis has published numerous articles on software security and AI governance, contributing significantly to the cybersecurity community's body of knowledge. His unique blend of technical expertise and business acumen positions him as a valuable voice in the ever-evolving landscape of digital security.