A Universal Lemma For Compliance

2500 words, 9 1/2 minutes.

Matthew Hopkins, Witchfinder General. 1647 Engraving.

Here I describe a lemma¹ or helping theorem for technical compliance of IT with a focus on Information Security.

It’s an approach for all compliance regimes whether regulatory or corporate. It doesn’t date, nor is it predicated on a technology or platform. It isn’t a trick. It doesn’t provide cover for inadequate security or incompetent staff. If you’re looking to evade compliance, disguise incompetence, or shirk accountability then you’re in the wrong article. You’re probably in the wrong career. If on the other hand you want to deal with compliance in a swift, decisive, and confident way, set aside the next 12 minutes. If you’re in a hurry I can cover it in 6. I’ve just saved you 6 minutes right there. You owe me.

This isn’t the whole answer. There’s no magic spell. It’s a way of thinking and communicating which is persuasive. It requires work. You’ll do that work. You’ll want to do it because it allows you to meet compliance not with timidity or dread, but with overwhelming force. Finally, I believe this method may be a necessary step along the road to the complete automation of compliance. What would that be worth to you?

Introduction

This post began as advice for a client delivering contracts they had won with the top 5 investment banks. Those contracts required the exchange of Personally Identifiable Information belonging to the world’s wealthiest private banking clients and fund managers. The purpose of that exchange isn’t important. What’s important is that in order to conclude this business my client had to comply with the internal security policies of those banks.

The pile of neatly bound security policies sat on the desk, almost a foot high. They had been printed over 6 months ago and delivered by hand. I didn’t read them. I didn’t need to. I knew what was in them. I’d seen most of them before.

The CSO for my client, the person dealing with these policies, had quit. He’d made almost no progress satisfying the bank’s representatives in the months that preceded my arrival. His replacement, a more junior IT manager was energetic but lacked knowhow or clout. Clout was to come in the form of the COO who now assumed personal responsibility for this compliance project. I brought the expertise. The interim agreement which had allowed my client to begin work had expired the week of the CSO’s departure. They had no real experience of compliance within their company.

As a consultant sometimes it’s better to do the work oneself. Sometimes it makes sense to use the client’s people under supervision and with quality control. In this instance there was no option but to do the latter. There was no time. Everyone was going to have to take an oar and row. Yet an uncoordinated response would inflame an already delicate situation with the banks. The IT team would need guidance, that guidance became a lemma for compliance. Before getting to the detail I’d like to put some context around compliance for those who are less familiar with it.

Compliance In Context

Like a grudge purchase, compliance tends to be something only visited periodically (as if it were a renewal of car insurance). This reality runs counter to the purpose of compliance, which is to ensure continuous adherence to a standard. Audits or attestations are by definition a snapshot. We argue the case for continuous compliance. The fact remains that most organisations continue to think of it in terms of a hurdle that must be cleared every once in a while.

Different compliance regimes have different stipulations. Their goals are similar. Namely saving somebody from fines, lawsuits, and corresponding damage to business. This is done by incentivising good practices and penalising bad ones. Specifically, by the more accurate apportionment of the cost of preventing mishaps. The best compliance regimes move cost closer to the party most able to reduce the risk of a bad thing happening.

Often there’s a trickle-down benefit to those at the base of the pyramid, typically the consumers. However, there are also power struggles that occur around compliance when some parties in a transaction, value-chain, or ecosystem are much larger or have greater market power than their counter-parties. In these cases there are commercial incentives to roll the burden of compliance down from the big guy to the little guys. This happens through contractual obligation. This jars when financial penalties for failure don’t fit with opportunities for reward.

That’s the high level view. What about down at the human scale?

It’s people that make compliance happen. These people need satisfaction they’ve discharged their responsibility. They want comfort that they’ve protected their companies interests. They are cautious, but generally inclined to approve rather than to block. Compliance’s role is to enable business to take place safely, not to prevent business. Although sometimes it might not feel that way. These people can be an asset; they’ve seen it all before. Don’t activate their mental defences by deceiving or evading them or trying to confound their process. They like strong, clear, succinct answers. We can use this to our advantage.

Inconvenient Truths

• Firms are often non-compliant even with their own policies.
• Some departments, or applications can never be fully compliant.
• Almost nobody is fully compliant when first challenged.
• If you are compliant, weak attestation or inadequate documentation can lead to trouble.
• Nobody tells you this at the start.

Does compliance seem less frightening? I hope so, because you can’t think clearly when you’re frightened. Clear thinking is essential when tackling compliance matters. The sooner you start the process, the sooner you discover the extent of the work required. At its most basic, compliance is about being able to:

1. Meet a minimum standard, it may mean improving upon what you do today.
2. Communicating that you meet that standard.
3. Producing evidence that you meet that standard.
4. Survive scrutiny of the evidence with a minimum of fuss.

Fail at any one of these and the compliance process becomes painful. It’s often the case that a company is compliant, or largely compliant, but fails at the remaining 3 steps. This post can’t help you directly with 1, but can help with 2, 3, and 4. It can do so in a way that you can use for future compliance projects.

A Universal Lemma For Compliance

• The purpose of the lemma is to be a bridge. A bridge is needed because the gap between implementation (infrastructure, configuration, code) and compliance (obligations, assurances, law) is large.

• Compliance regulations should be as independent of products and configurations as possible. Infrastructure should be built from generic, interoperable, open technologies. The lemma must talk a meaningful language to both sides.

• The lemma should reduce the work required in attesting to an increasing number of compliance regulations. It should do this by eliminating duplication of work and by encouraging brevity.

• Elimination of duplication can be achieved in the same way that a compiler takes a single source code (analogous to your present IT implementation, the left side of the diagram above), and compiles it for different target hardware architectures (the compliance doctrines on the right). In a compiler this one-to-many process is achieved by using an intermediate language. Our lemma will take the form of an intermediate document.

• The wording of the lemma should be such that evidence (proof of compliance) should be explicit not implicit to people coming from the right hand side of the diagram.

• The lemma should be so robust and the evidence so incontrovertible that even the most case-hardened auditor will quickly conclude he is pushing against a solid edifice with deep foundations.

We’re going to create an information-dense, structured document that will be easy to read and understand. This document is going to do the job of translating from technical implementation (your infrastructure) into something of use for compliance purposes. It’s written in such a way that both the infrastructure side and compliance side can change (or grow) with the minimum of changes to the intermediate document. If you were already familiar with lemmas in mathematics or compiler design, then you’ve probably had enough clues to begin writing the lemma already. Now the work begins.

Building The Lemma

The lemma is built in sections using a structured format. In this format individual statements can be accurately referenced. Together this structure and numbering encourages brevity and definitiveness. There should be no unnecessary words. Giving a long and waffling answer to a succinct question will not win anyone’s confidence. On the contrary, they may even doubt you’re telling the truth.

Returning to the diagram above, individual systems and infrastructure on the left-hand side will have their own documentation regarding their setup and operation. These could be traditional documents, a more dynamic wiki, or “live” patterns and blueprints within an orchestration layer. Even if your organisation has no recorded information of this sort, you will have configuration files that can be retrieved, examined, and referenced. These are our source materials. The details they contain will determine if your status is compliant. This post is about documenting that status in the most persuasive way.

On the right-hand side of the diagram we have the compliance regimes we are challenged to meet. This could be an internal policy, a regulation, or other stipulation from a 3rd party such as a business partner. This compliance could be entirely prescriptive (common for internal policies) or entirely objective (common for legal regulations), or somewhere in-between.

The first step is to create sections in our lemma for each high-level topic relevant to the compliance regime we are addressing. Returning to the very beginning of this post, in our example the right side of the diagram would be the bank security policies. After having read these, one can generalise several common themes or threads. If you had different compliance regimes, your list of themes would be different. Across the dozen or so compliance regimes, and tens of corporate policies I’ve seen there is a high degree of commonality in themes if not individual stipulations. Here are a few common themes that run through different compliance regulations:

1. Securing Data At Rest.
2. Securing Data In Transit.
3. Network Access & Integrity.
4. Network Segmentation & Separation.
5. Host Access & Integrity.
6. Authentication & Authorisation.
7. Decommissioning & Erasure.
8. Monitoring & Alerting.
9. Maintenance & Management.
10. User Privacy & Obfuscation.

The fact that these themes are quite common is important. It is this that allows us to minimise the amount of work required in attestation and evidencing our claims of compliance for each of the many regulations. If we succinctly describe and evidence the way in which we provide say, “Privacy & Obfuscation” once, we can reference that text over and over as we attest to one compliance regulation after another.

Each theme becomes a chapter in our lemma. Each chapter has the same 4 sections.

1. Goal.
2. Systems.
3. Designs.
4. Evidential Statements.

The goal is a short description providing additional clarification with scope and context. Systems are the high-level systems (systems in the broadest sense of the word, not servers or computers) which allow us to achieve the goal. Designs are almost always best expressed in diagrammatic form, they are a simple pictorial representation of where and how each system is applied in relation to your infrastructure. Evidential statements are brief, accurate, statements of fact. They link the design and the regulation together with numbered references to both.

Let’s look at a simplified example. In it we are required to comply with 3 regulations. These could be within the same piece of legislation or 3 separate policies that have some common stipulations. We shall use the first of the 10 themes or chapters I list above.

• Let the 3 regulations be R1, R2, and R3.
• Let the theme and the goal be accomplished by systems, S1, S2, and S3.
• Let the design for each system be a single design, D1, D2, and D3.
• Let the evidence for compliance be E1, E2, and E3.

An Example Chapter

The Hidden Dividend

Why use this notation or even the word lemma? Why not just call it a document? After all I don’t like false sophistication. Much of my time as Consultant, Product Manager, and Investor was spent simplifying esoteric concepts. I’d need a good reason for using an obscure term now. Could it be that it emphasises a necessity for brevity? Or that thinking in algebraic and symbolic terms rather than literary terms discourages the repetition that plagues compliance attestation? Surely I’d need a better reason than just that?

Going through the process above by hand will save you a significant amount of time. Perhaps 25% or 50%, even 60% once you’d covered a few compliance regimes and had several chapters written. You still need to read the compliance regulation and add references to the evidential statements. There are limits to the amount of time we can save with this method.

• What if table D1 was populated automatically from infrastructure, by code?
• What if a regulation could be expressed as a structured list of stipulations?
• What if D1-3 could be compared automatically with those stipulations?
• How much time would that save?
• What if that code generated your final compliance attestation?

We can go further…

• What if we could produce compliant configuration snippets for live systems?
• What if we could express internal compliance policy in parsable form?
• What if we could automatically apply configurations and re-test?
• What if automatic attestation was cryptographically signed by both parties?
• What if this was so frictionless it could be done daily or on-demand?

Most of the low-level software tools and frameworks required to make this happen are already in existence. What’s missing is the programmatic equivalent of the lemma. The reason I used this esoteric term is because I believe that thinking about compliance and attestation in this way is the key to automating it away. Fully automated, provable, continuous compliance and attestation.

What would that be worth to you?