Compliance Is Who You Are Not What You Do

There are some famous lines in the security industry — “security is something you do, not something you are” and “being compliant doesn’t mean you’re secure and being secure doesn’t mean you’re compliant.” We should add another one — “Compliance is something you are, not something you do.”

The Challenge

Most organizations treat compliance as a burden. They do this because it is a burden. Any type of compliance activity, not just information security compliance, is a drag on the operations of an organization and it is hard to see the value — especially when you know you’re doing all of the right things. But demonstrating compliance to customers, industry groups, or governments is a cost of doing business now. We can make it less painful and less expensive. First, let’s explore the issues.

What is compliance?

In the information security context the definition of compliance could be infinitely debated. But we should be defining compliance as demonstrating that an organization meets an acceptable minimum standard (or baseline) as defined by the “regulator” which might be a customer, an industry body, or a government.

An organization can appear compliant, have the signed report, the logos, and their name in a database. That’s great for marketing and staying in business (pre-breach). But is isn’t actually being compliant. Compliance is not deceiving an auditor in to signing off. Compliance is not checking “yes” 12 times on a self-assessment questionnaire. Compliance is actually meeting the objectives of the standard, 365 days a year, and being able to prove it.

Where does it hurt?

Demonstrating compliance with a standard can be painful for an organization. Maybe the standard is too rigid, making it difficult to show that a new technology meets the requirements. Maybe the standard isn’t rigid enough, leaving the organization and auditors with little guidance and too much leeway. Being compliant is easier than showing compliance.

Blame the auditors!

Auditors are people (I know, I was shocked too.) Like people in all professions they come with varying qualities and abilities. Some auditors are real sticklers for the letter of the law (or standard). “PCI DSS says you must have a firewall. AWS security groups are not a firewall. Therefore you are not compliant and must install firewalls.” Meanwhile, some other auditors just phone it in and collect their check. In the middle we have auditors who understand the objective of the standard and work with an organization make sure that the objective is what is met, not some nonsense guidance that hasn’t been updated in years.

If your auditors aren’t challenging you, your organization needs new auditors. If your auditors aren’t working with you, you need new auditors. The auditor/auditee relationship should be healthily adversarial — challenges coming from both sides. If you’re hiding things from your auditor, it is time to take a good hard look at yourselves. If your auditor just nods their head and accepts everything you say, it is time to take a good hard look at their competition.

Blame the standards!

Standards are are hard thing to get right. Technology and the threat landscape change rapidly. But standards last for years. That’s not an argument against standards. We need them, badly. We need to find a careful balance in our standards that are accepting of and adaptable to new technologies and threats, but without being so vague that they are impossible to audit consistently.

Let’s look at PCI DSS requirement 5.1:

Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).

Anti-virus software is an outdated term, but a good auditor and a good security practitioner aren’t going to get hung up on the term. What is good about this requirement is that it accepts that not all systems are commonly affected by malware. And in those cases, anti-malware software isn’t necessary.

Now let’s look at PCI DSS requirement 8.2.4:

Change user passwords/passphrases at least once every 90 days.

This violates current guidance that changing uncompromised passwords does more harm than good. A better wording would be:

Change user passwords/passphrases at least once every 90 days, or implement other controls (such as one-time passwords) to mitigate the effects of compromised passwords.

Standards, like auditors and security practitioners, are not and never will be perfect.

Let’s Do Better!

Demonstrating compliance is part engineering and part sales. You will always need to frame organization specific details in a way that outsiders can understand. Start with deeply understanding the standards your organization needs (or wants) to comply with.

This means analyzing each requirement to understand not just what it says, but what the objective is and what are the flaws in its writing. Unless it is obvious, form and document your organizations position on each requirement. If necessary, use sources to support why the standard guidance is broken and how what you’re doing meets the objective based on current industry guidance.

Next, engineer relevant systems and processes so that they are generating what you need to demonstrate compliance at any time. Gathering evidence should not be a resource intensive chore. It is a process that is never going away, so it’s best to optimize it.

Select auditors that work with you to make your program better! Bonus points if you switch auditors occasionally to get new perspectives. At the end of the day, your organization is responsible for actually being compliant. If an auditor deems you to be compliant when you aren’t, they’re in their own hot water but that does not absolve you of responsibility.

On my company’s attestation of compliance I sign right above the QSA — we both have skin in this game.

Learn from every audit. If you can’t find something to learn from each audit, you’ve gone wrong somewhere. Whether there is a control that can be improved, a process that can be better engineering, or documentation to that can be updated. There is always something to learn to better security or better the process.

Compliance isn’t the enemy

The need to comply with customer, industry, or government requirements is not going away. The standards probably won’t ever be crystal clear. Auditors will always be people with opinions, skepticism, and sometimes laziness. Compliance is a cost of doing business for most organizations. It is up to each to determine how to optimize that cost.

For some organizations, bending the rules or outright cheating will be the path they take — and if it doesn’t work out for them, they’ll pay the current price (which sometimes isn’t enough).

Other organizations will focus on compliance as the driver of their security program. They’ll spend truck loads of money and resources on achieving compliance, but will miss other gaping holes in their security program.

We should strive to be in between these two types of programs. Build a security program that is strong enough for your organization’s threat model, keeping in mind the need to demonstrate compliance, and recognizing that it won’t always be obvious how “security control A” meets “object Z” and that it is on you to frame it for your stakeholders.

Taking the time to engineer the processes and build the narrative is an investment that will pay off with each successful audit.

Author: Bryan Brannigan
Image by Michiel Kloppenburg