Automate Compliance with BDD Tools
| DevOps |
Ever heard of Cucumber? I don’t mean the fruit which, when placed in vinegar, turns into a pickle.
Implementing secure policies and safeguards into a development process — keeping passwords and credentials out of code, for example — is a critical first step towards meeting compliance guidelines and regulations. Doing so is only half of the battle, however; you also need to be able to document and prove that these systems are in place and effective.
Doing so can be tedious, expensive, and time-consuming. The decision to invest in automation for software development and delivery capabilities is typically made to eliminate bottlenecks like this; wouldn’t it be great if you could leverage DevOps technologies to automate compliance related documentation?
In fact, you can, by implementing Behavior-Driven Development (BDD).
BDD is a technique of software development which combines the base of test-driven development with aspects of evolving models. BDD technologies facilitate meeting technical documentation objectives for regulatory compliance purposes. BDD was originally developedto aid in the communication between stakeholders and software developers through a shared tool and process, understandable by both.
In this example, we will use Cucumber, an open-source software validation system which translates requirements written in plain English into working test cases. It’s easy for non-technical audiences to understand and it’s structured enough to be a solid framework for engineers to use. Consequently, Cucumber is increasingly being applied to operations as well, often for doing things like verifying SSH installations and firewall settings on servers in the infrastructure stack.
Part of the value of using “cukes” is the increased visibility into the value and reasoning behind each script in an environment, which can then be easily communicated to all stakeholders, auditors, and operations personnel on demand.
In much the same way as software requirements are written and communicated within Engineering, Cucumber makes it easy to author and expose compliance controls in plain English across an organization. Each such control is written a condition which an organization must fulfill in order to be “in compliance”. These can be directly translated into a series of Cucumber “Scenarios”, written in an English-like syntax (called Gherkin).
An execution engine evaluates whether each scenario is working in the intended way using clearly worded statements of the desired outcome.
Let’s walk through an example using Cucumber to verify an example system’s SSH configuration. This example is applicable to IT environments such as those falling under HIPAA, SOX, and numerous other regulatory frameworks. For this example we will be using the NIST control PR.AC-4: Access permissions are managed, incorporating the principles of least privilege and separation of duties.
Start by describing the compliance objective statement in plain text. The compliance control should be understandable by both developers/operations personnel, business, and regulatory stakeholders alike.
<code>Feature: In order to comply with NIST PR.AC-4 [<---insert your compliance reg here] As an IT systems administrator I want to demonstrate that only authorized users have SSH access to virtual machines in a controlled cloud IT environment</code>
Then set up the scene, what you already have in place or plan to have in place.
<code>Background: Given a “Compliant” server [<-------insert your regulatory framework here, for example, a server that’s using Conjur] And a “developers” user group And an “ops” user group</code>
Lastly, describing passing scenarios.
<code>Scenario: Developers do not have ssh access to the controlled IT area Given I belong to the “developers” group And I ssh to the server Then access is denied (or restricted such that the developer does not have sudo access) And the login attempt is recorded Scenario: Ops personnel have ssh access to the controlled IT area Given I belong to the “ops” group And I ssh to the server Then access is granted And the login is recorded</code>
From here, a developer could write a test definition in Ruby and run it, receiving a fail error. In response, she could write code that would lead to a pass state, and repeat until all necessary steps are written and green. (Additional tests might be required to fully comply with the NIST framework as written, but are out of scope for this example.)
With a BDD tool and Conjur working together, organizations can both define and demonstrate enforcement of compliance-related policies and easily share the objective evidence of having both in place and being adhered to.
Want to learn more about how Conjur can support formal compliance requirements, provide access intelligence, and help organizations manage authorization at scale? Get started today with a free trial, and we will be happy to walk you through the process!