A Comprehensive Guide to Continuous Compliance-as-Code in the Cloud
A Comprehensive Guide to Continuous Compliance-as-...
A Comprehensive Guide to Continuous Compliance-as-Code in the Cloud
Public cloud adoption in Financial Services is maturing with several leading organisations adopting a broad set of services from multiple cloud service providers. To take full advantage of the services on offer application developers need direct access to the cloud provider’s management interfaces, which challenges the traditional, established lines of responsibility between infrastructure teams and application teams.
This blurring of roles is creating anxiety for the teams responsible for enabling the cloud (typically the “Cloud Centre of Excellence”) – upon which the burden of compliance is falling – and those responsible for governing the cloud – who are challenged with new operational and SDLC patterns.
As financial services firms prepare for application teams to take on additional compliance responsibilities in this new model, and as the services underpinning the applications become more heterogeneous in nature, there is a demand for a more accurate mechanism to describe how controls should behave in the cloud – both in a generalised way and in the context of the individual cloud services and architectures being implemented.
The shape of the control landscape needs to evolve to spread responsibilities across multiple teams, tools, services and third parties. Using the analogy of an apartment block to model the different responsibilities inside our organisation, we present a comprehensive model for managing compliance “as code” – with traceability from the canonical sources of compliance requirements through to the manifestation of those requirements in the cloud and reporting of the efficacy of the controls we have in place.
To address the need for a consistent mechanism for expressing control objectives we describe our favoured approach of using Behaviour Driven Development (BDD) – a way of using natural language to express complex system requirements, allowing technical and non-technical stakeholders to agree how a system should behave if implemented correctly.
We then address how these objectives can be automatically and regularly tested as part of a Continuous Integration and Continuous Deployment (CICD) pipeline. These tests do not replace dedicated tools and cloud native services for monitoring and compliance reporting. Instead, they provide for a common specification and reporting layer, giving us transparency, traceability and confidence that these services have been configured correctly and are meeting the desired control outcomes. Continuous testing also gives us assurance that the CSP has not made service or platform changes which affect the compliance and security posture or control behaviour.
By combining these concepts, we can create a data model for end-to-end lineage from the underlying provenance of our controls, to control objectives, to behavioural specifications and finally the result of implementation tests and output of continuous compliance monitoring tools.
We present a practical example using Cucumber, a polyglot BDD testing framework, to specify and test controls of object storage services. The code for this example can be found on the Citihub GitHub account at github.com/citihub/compliance-as-code–whitepaper
Decentralising Controls in a Polycloud PaaS Model
Financial services organisations are beginning to adopt a “polycloud” model – integrating a heterogenous set of PaaS services from multiple providers into their IT ecosystem.
The approach of handling cloud provisioning through a homogenous abstraction layer – whilst attractive from the perspective of control – has been proven to hinder the progress of this shift in strategy, with the abstraction layer unable to keep pace with the demand for access to new cloud services or the feature velocity of the cloud services that have already been integrated.
The emerging approach towards controlling heterogenous polycloud environments is to decentralize the implementation of controls. By combining the controls provided by the CSP control plane with both a provisioning toolchain and monitoring tools to detect and handle non-conformance (an approach commonly referred to as control “guardrails”) firms are gaining confidence in their ability to control the risks of making the native APIs of the CSPs directly available to application developers.
Towards Automation & an SDLC for Controls
Given the requirement to embed hundreds of controls across several service providers – with traceability to policies and regulations – the only viable way to manage their deployment and management is via automation.
With a growing number of implementation teams and multiple control authors, there is a high risk of fragmentation, with different interpretations and implementations of the same set of requirements. The result is inconsistent control outcomes and a greater burden on control owners and the teams responsible for gating and auditing the controls landscape.
To derive greater consistent in control outcomes, pioneering organisations are looking towards best practices from software engineering to build, test, deploy, manage and report on the controls that have been implemented. Tracing the provenance of controls to their underlying regulatory and legal requirements is also extremely important in highly regulated financial services firms. These firms have a need to provide a structured, auditable evidence trail – both to avoid audit activity firedrills and to provide continuous assurance and transparency across polycloud infrastructure estates for internal operational risk teams.
In this white paper, we discuss:
- How the shared responsibility model is fragmenting with this shift in strategy
- A reference model for implementing cloud resources and controls
- Techniques for building and validating the implementation of controls
- How the reference model can be implemented in your organization using these techniques
Throughout this white paper, we build on the following terminology:
- Infrastructure-as-Code – referring to the use of software engineering practices to deploy and configure cloud resources
- Compliance-as-code – referring to the use software engineering practices for implementing and validating the efficacy of controls deployed in the cloud
- Continuous compliance-as-code – referring to the regular validation of controls
Unlock cloud-based developer productivity through modern, dynamic approaches towards compliance. Speak to us to find out more.
FT Names Citihub Digital as one of 2021’s Leading Management Consultants
“We’re thankful to be recognized for the 4th successive year for our leadership in financial ser...
Digital Transformations in the age of COVID-19
Joining forces with Synechron, our Enterprise Transformation SMEs offer their perspectives on why a ...
Meeting your Data Obligations in the Cloud After Brexit
Joining forces with Synechron, our RegTech SMEs – Bob Mudhar & Anand Chandra - talk about the the ...
How to set up a Test Coverage threshold in Go and Github
Senior Consultant Luis Carrazana enumerates the steps needed to implement a Test Coverage Threshold...
Cyber security and the growth of untrusted infrastructure and hybrid workforces
Joining forces with Synechron, our Dev & Sec SMEs talk about the increasingly important role of clou...
Increasing test coverage without slowing down development
Are you confident about refactoring your legacy project? What are you doing to ensure stability with...
15 Minutes with: Utsav Ratti on Smashing the silos between IT and business teams
Has the pandemic made the divide between IT and business teams worse or has it presented an opportun...
In the press
Secrets Management in the Financial Industry
Associate Partner Joshua Burns, CISSP has been invited by Financial Information Forum (FIF) to t...
In the press
FinTech: Continuous Verification & Declarative Delivery; Common Fallacies & Anti-Patterns in Continuous Delivery
In this webinar, Cithub’s Eddie Knight and Armory’s Lee Faus will look at defining consistent po...