Have you already heard of Compliance-as-Code? Are you familiar with “compliance officers” in your organization? If not, you might be curious what ‘compliance’ means. Quite recently there have been some talks around this topic at conferences. Most of the talks highlighted the topics from a rather technical point of view; in this article I try to answer what Compliance-as-Code for your business means.
Definition & explanation
First of all, let’s try to explain compliance from the perspective of a developer team which builds software applications. The team frequently delivers new features and deploys their applications at regular intervals.
Jim Bird wrote the following in his book titled DevOpsSec:
In the same way that frequently exercising build and deployment steps reduces operational risks, exercising compliance on every change, following the same standardized process and automated steps, reduces the risks of compliance violations.
It’s about automating the enforcement of (IT) compliance regulations. From this point of view, the website of BMC provides an overarching definition of (IT) compliance:
In short, IT Compliance is the process of meeting a third party’s requirements for digital security with the aim of enabling business operations in a particular market or with a particular customer.
Compliance is not just about security, but it is a major aspect of it. To explain this a little bit more: developer teams need to strive for compliance (e.g. adhere to requirements and security regulations) in their day-to-day software delivery tasks. Compliance related requirements are most often non functional requirements.
In the end it’s all about being “in control” about what will be delivered to make sure your business keeps on running. If all requirements are fulfilled the software application is considered “compliant”. All of this helps your organization with your regular business processes, thus ensuring business continuity.
Compliance rules can be defined by different departments in your organization. Think of the legal department defining a rule like: “Applications for different (internal) customers are to be deployed on separate servers which do not share networks”. Or another one from the CISO department: intranet based application are never to be deployed with a public endpoint (e.g. internet facing). It is tedious, time consuming and error prone to check for these rules manually each time a software application is deployed.
Instead, it’s better to write compliance policies in code and enforce them automatically. Once a new version of a software application is deployed, it is evaluated automatically against these rules. As a result the rules should prevent any application from being deployed if the application violates the rules. This way, the process can be repeated for every deployment. The compliance rules are embedded into the DevOps way of working.
Compliance policies are written as code and stored in a source code version control system. One or more rules make up 1 compliance policy. Stakeholders or external regulators define the functional policies, developers implement them. There are special software tools on the market which help developers write the policies. Open source tools like Open Policy Agent and the closed source tool HashiCorp’s Sentinel help developers implement these rules into their daily workflow.
Above mentioned tools hook up in several stages of the software development life-cycle. In terms of feedback: the faster you know whether or not your software applications are compliant the faster you can fix it. Fixing compliance rules in an earlier stage is also much cheaper than fixing them in production.
How it works
Compliance rules usually come from non-technical people in the organization. Developers need to translate these rules from a human readable format (e.g. a Word file) into code. A key principle here is the decoupling the specification, implementation and enforcement of compliance rules.
Popular Compliance-as-Code tools run alongside of the application which is either being developed or already deployed. It constantly monitors code and running applications for changes. Any change is being evaluated and checked according to the compliance rules. As soon as it notices an application violates a compliance rule, it triggers another action.
An example would be: it can prevent the application from being redeployed or log an error and send a warning to a system operator.
Compliance violations can also be grouped and gathered and later on being reported to a centralized dashboard. Business managers can view those violations and determine what to do. Developers can fix the applications by fixing the violations in the code or the system can (if smart enough) fix problems automatically.
One of the most popular open source tools for Compliance-as-Code is Open Policy Agent (OPA). See the website of opensource.com for a number of good use cases in which OPA can be used. It provides an additional set of features which are difficult if not impossible to achieve with other tools.
Above picture shows the rules for a specific application to be deployed in production. The application has to be configured correctly in order to adhere to this rule. It requires compliant rule PCI level 3 and it should be deployed in a (cloud) data-center inside the EU region. If one of these rules fail, the application cannot be deployed.
Compliance-as-Code has several benefits over a manual approach towards compliance:
- Repeatable process: compliance is part of the software development life-cycle. The process is repeated with every release. This makes it easy for auditors to verify if you’re compliant. And compliance is more about having control over the process and where you’re not compliant, less about being completely compliant all the time.
- Compliance rules are written as code. The rules can be tested, versioned and it’s easier to add compliance checks to every software application.
- No manual compliance checks since all checks are automated. Above all, it also helps to avoid human errors.
- Meaningful information. When adding compliance related meta-data to an application, other systems can do something meaningful with it. A simple example. Generate a report for the top 10 applications which are not yet (100%) compliant. Prioritize them and start to bring the applications which are most critical for your business into compliance.
Most companies are not very eager to share their compliance rules. It’s because it reveals how their businesses are organized internally and highlights to which extend they have implemented security related aspects. Publishing compliance rules can create additional risks. Imagine that a potential hacker knows which security controls are implemented at production systems. They can exploit any weak spots to gain access to those systems and steal sensitive data.
Taken from the business perspective, these websites will help you getting started:
- The website of Blackstratus which highlights a great number of compliance regulations.
- Top 5 compliance challenges for the financial sector.
- A list of compliance and regulatory frameworks.
- GDPR compliance checklist for EU-based companies. This can be used to derive policies.
And from a technical perspective:
- Website of Open Policy Agent which outlines how to get started with policy as code (technical documentation).
- Examples of Sentinel policies which can be used in Hashicorp Terraform scripts (technical scripts).
Compliance-as-Code makes sure your business processes keep on running smooth. It helps your business to stay compliant and stay in business. Tools can help you write and enforce compliance rules. A great starting point to get started with Compliance-as-Code would be to look at existing rulesets in tools like OPA and Sentinel, for instance GDPR rules, which you need to implement anyway.
Linking the business with the technical this way will provide you the best way to get compliance (as code) done in your organization. Be sure to evaluate after a simple set of policies and cross check it to make sure these are useful to your business.