YOW! September 2021 Recap
Effy Elden
Effy Elden is a Senior Infrastructure Consultant with Thoughtworks, and as a result they have seen a lot of attempts at achieving compliance within companies over the years. A word more often associated with sighs of despair and moans of frustration, Effy believes compliance to be a genuinely important subject for organisations to nail. Done right, it helps protect customers, systems, and people alike. Done wrong…
“The process or culture around compliance is usually the problem, not compliance itself.”
The title of Effy’s talk is important here; rather than using compliance as a stick to beat developers with, it’s important that we instead view it as a set of safety rails with which to guide good delivery outcomes. We want to trust teams to do the right thing, but have the checks and balances in place to catch the odd mistake. In a callback to Gregor’s earlier talk, Effy states that a lot of the things we used to have to trade off against one another we can now have at the same time. Among those is developer satisfaction and compliance. These don’t have to be at opposite ends of the spectrum, as perhaps they traditionally were. This is where compliance as code comes in.
Compliance as code is - as the name suggests - a way of defining rules and controls in a way that computers understand. This allows for automation and most importantly shared ownership of compliance. Effy started with an example of the opposite end of the spectrum, a case study from one of their clients whose security team had overburdened the developers with so much extra work it was taking chunks out of their ability to deliver valuable outcomes for the business.
From here, Effy talks about how an alternative approach was obtained. First of all, controls needed to be clearly defined as per the security policies in question. With the controls in place, you now need to select tooling that will be able to measure and enforce the controls in question. Many cloud platforms already provide these tools baked in, but it’s important to keep a criteria in mind. Some suggestions on this front;
- Suitability for capturing the control in question
- Availability of prebuilt rules in the tooling for your controls
- Extensibility of the tool with custom rules
- Testability of the rules
- Observability of execution and reporting on results
Importantly, Effy stressed that it was not necessarily a bad thing to end up with many tools. In their mind, it was better to take a polyglot approach and cover the things important to your organisation than standardise on a single tool that didn’t really do the full job.
Next, it is important to not just write the rules in the tool to report on your compliance, but to continuously evaluate those rules. The easy win here is to make these rules part of your build pipelines, so we’re always aware of compliance breaches as early as possible. But you can take it a step further and even run some of this tooling in your local development environments - bringing compliance right to the individual developer on their machine.
As wonderful as all this sounds, there are potential pitfalls. Effy has seen compliance as code mis-used, with a number of anti-patterns emerging:
- Brittle preventative rules; where companies believe they know all possible ways to prevent a problem, rather than actively monitoring for it
- Black box compliance, where the compliance as code is in place and alerts sound, but teams have no real idea of why they’re going off or what they’ve done wrong
- The buried compliance dashboard - the single pane of glass that was built, forgotten, and buried in a peat bog never to be looked at again
- Limitation-driven development; constraining your delivery teams around inadequate tooling in the name of ‘better compliance’
- Sporadic compliance; defining a perhaps very good set of controls and rules, but then reporting on it only when it seems fashionable, and leaving large gaps of questionable status
Overall, compliance as code seems a very “dev-friendly” way of fixing a very “lawyer-friendly” problem, and it looks well worth organisations investing time in. Starting with something as simple as some ‘SlackOps’ for your delivery teams could save some headaches some ways down the track.