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.
Read the full version of this whitepaper
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.
Stay current on your favourite topics
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