Compliance as Code for Financial Services

Compliance as Code for Financial Services


Compliance as Code for Financial Services

by Paul Jones
about the authors
Compliance as Code for Financial Services

Share this Blog with a friend.

About the Author

dark mode

Infrastructure as Code techniques have taken root amongst enterprises seeking to adopt the cloud at scale.

DevOps and full-stack engineering teams are realising the benefits of automating their cloud services using the likes of Terraform, Pulumi, Cloud Formation, Ansible and Chef. Infrastructure has become repeatable, testable and version controlled.

This increased agility has enabled rapid adoption of quickly evolving PaaS and serverless products from multiple cloud providers. In order to keep pace, security teams are seeking alternative, more sustainable approaches to assuring the security of their environments.

Applying Guardrails

The “cloud broker” model, a pattern in which all interaction with the cloud control plane must funnel through a central, governing controller, has become unfashionable. Early movers came to realise that keeping up with the rate of change of the cloud providers was an expensive task, even when consuming IaaS. As the number of services being consumed has increased, with little fungibility across providers, the level of investment required has become unsustainable.

Instead, application teams are being provided with environments that are secured by “guardrails”. Rather than cataloguing and then proxying the creation of allowed cloud services and patterns, security architects can, within the cloud platform, define a set of policies, rules and other controls that ensure compliance. If a user tries to provision services that violate these rules, the cloud platform will prevent it.

Compliance as Code

Like the infrastructure they govern, these controls can also be treated as code. Implementations of, for example, Azure Policies or Kubernetes Pod Policies can be managed in Git and deployed via a pipeline: Compliance-as-Code.

If version control and automation is in place, teams can turn their attention to another cornerstone of software engineering – testing. It is here where Citihub believe that there are other tools in the developer’s toolbox that can prove fruitful.

Applying Behaviour Driven Development

Behaviour Driven Development (BDD) is a practice that is particularly popular with front-end developers. A user’s actions – their behaviour – and the required reactions of the system under test are described in a kind of “plain English”.

The BDD style encourages test authors to define the features of the system using simple phrases such as “given”, “it should” and “expect that”. Some frameworks, such as the popular Gherkin/Cucumber combination, take things a step further and separate the definition of the feature (the behaviour) from the physical implementation of the test. This approach means that, provided some care is taken, the two artefacts can have different authors.

In the case of compliance as code, we think this can be particularly powerful. If we express the requirements of a policy or regulation as a BDD feature, we gain a concise, accurate representation of the rule that must be enforced. The feature:

  • Can be easily read by compliance experts (and, ideally, written by them too)
  • Is portable across clouds
  • Is agnostic of the underlying implementation (be it an Azure Policy or Kubernetes Pod Policy)
  • Can be run continuously via CI/CD

Using compliance as code , the Cloud Program gains the ability to see their control objectives, whether they have been implemented, and whether they have been met – in each of their environments. Auditors get to see a compliance dashboard, driven by test coverage – not a spreadsheet and accompanying policy JSON.

An example

To illustrate, let’s take a simple example. Suppose that we have an obligation to ensure that any object storage buckets we create are private – i.e. inaccessible from the internet. We could express this rule in BDD style as:

Given a control that cloud storage is private

When a public object storage bucket is created

Then creation fails

To implement, we break it down as follows:

Given a control that cloud storage is private

// Write code to define and assign an Azure Policy that denies Storage Accounts that do not have a suitable network access control list (typically defined as a JSON document, applied via SDK)

When a public object storage bucket is created

// Using the preferred infrastructure as code solution (e.g. Terraform, Pulumi or other SDK), attempt to create a publicly accessible Storage Account

Then creation fails

// Using the preferred test framework, assert that the Cloud Provider refuses to create the given resource

What’s Next?

The compliance-as-code approach we describe here hits a sweet spot for Citihub Digital; we’ve spent many years helping firms overcome regulatory and compliance challenges, particularly with Cloud. In the next post in this series, we’ll walk through the details of our implementation.

As adoption of public cloud in financial services accelerates, firms are looking for new, more agile ways to secure their environments. Associate Partner Paul Jones takes a look at the approach Citihub Digital are taking to Compliance as Code.

Related Insights

See technical discoveries and coding insights from our developers.

Find out more about life at Citihub

about us