Insights

Blogs

Compliance as Code for Financial Services

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”.

Stay current on your favourite topics

Subscribe

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 Consulting; 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.


Would you like to know more about our work?


Author

Paul Jones

Paul Jones

Associate Partner, London

Paul is an AWS and Cloudera-certified IT consultant focused on topics such as software architecture, DevOps & CI/CD, Cloud and Big Data. He has a strong software project delivery expertise including Agile methodologies and product management. Recently, he led a multi-disciplinary team that delivered a bank-wide Data Lake platform serving regulatory and analytical requirements. Paul has 5 years experience of running an international eTrading platform delivery, integration and support team resulting in a deep understanding of the FX trade lifecycle and accompanying technologies.

paul.jones@citihub.com