Compliance and its uses

I spent the first xx years of a computer security career mostly avoiding compliance work. I recently flipped that and now work on high-scrutiny security+privacy compliance problems.

This is my view of what compliance can and cannot do for you.

What is compliance?

Compliance is meeting obligations.

Obligations? Obligations are laws, ftc compliance orders, compliance regimes (pci, iso27001) and “best practices” like CIS benchmarks or nist.

Generally the bigger the company the more obligations. The privacy ones revolve around data (ex: my gmail inbox) and what is done with data (ex: build an ai model from it). The security ones revolve around answering different forms of the question “are you doing thing X which helps with risk?” (ex: have a firewall in front of your credit card data). The legal subset of these obligations I think of as the aggregate will of the people towards a common good like “ensuring citizens data is safe”

Some obligations you probably have to do (COPPA, PCI) as the penalties for non-compliance are high and enforced (ftc order). Some obligations are optional (best practices, iso27001). Compliance work is both the work itself (ex: install a firewall) and the proof of work (ex: prove that the firewall is turned on to an external assessor every year).

Compliance cannot:

• Stop you from being hacked. Being compliant is not the same as being secure. You can be compliant with 20 obligations and still be hacked. See:

• However, a 2008 breach of Heartland Payment Systems (validated as PCI DSS-compliant) resulted in the compromising of one hundred million card numbers. Around that time, Hannaford Brothers and TJX Companies (also validated as PCI DSS-compliant) were similarly breached as a result of the allegedly-coordinated efforts of Albert Gonzalez and two unnamed Russian hackers

• Give you the optimal set of work to do. Compliance is one input of many to consider when deciding on the optimal set of security work to perform for your organization. Compliance != (optimal) security.
• Be cutting edge. It takes a long time to arrive at consensus on what security activities are useful or not. That consensus is sometimes formalized into a compliance standard. Bug bounties have been valuable for a decade and are only recently being written into compliance standards. Consensus is always lagging.
• Be actionable without interpretation. The average compliance document is high level and takes work to be legible to, or actionable by an engineer. Think statements like “you should take reasonable precautions around who has access to sensitive data” and not “change these 12 settings on your harddrive configuration”. This differs widely but if a goal is to be applicable to the largest set of customers then the incentive is to write generally and at a high level.

Optimal work

Assume the ultimate goal of a security team is to avoid bad events, like getting hacked. Avoid means reducing the probability, or impact of bad events. There are 1000s of projects you could do to move closer towards that goal (ex: setup 2fac for employees) but you can only afford to do 10 of them every year.

Which 10 do you choose?

There is an optimal set of 10 projects to choose.

Those 10 are specific to your organization due to its goals, history, maturity, etc.

You arrive at those 10 through considering many inputs and primarily by knowing your organization better than anyone else, certainly better than the author of a compliance regime. Those 10 probably overlap with the top 10 from any given compliance obligations, but its not a 100% overlap, see:

Doing compliance work mostly won’t make things worse, and its certainly better than doing no work. But doing 100 jumping jacks a day won’t prepare you to run a marathon.

Compliance is useful when

1. You have an appetite to do useful security work and don’t know where to start. Many options here (ex: starting up security) but working through getting compliant with something can also work.
2. A communication shortcut - “hey CEO we are compliant with X” is easier to say than we accomplished these 10 security projects. A thin presentation layer to make security work legible.
3. Social engineering to get useful security work done inside the org -  “We need to be compliant with X”. Because compliance is rarely specific you have leeway to tack on other useful security work at your discretion.
4. CYA - if your organization is under scrutiny, its helpful to say in some future courtroom “we followed best practices and were in compliance with $regime”.
5. Sales tool. If your orgs product is something you sell to customers, some # of additional sales might happen if you are compliance regime X approved.
6. Proof. Being PCI certified is a weak positive indicator of something, and sometimes that itself is useful.

Conclusion

Compliance is a tool, use wisely.

And don’t use it blindly.

I know less than the typical infosec person about crypto. I will read and follow NISTs crypto suggestions. I know an above-average amount about product security so I wouldn’t blindly implement BSIMM (I’m a fan!) but I will use it to spot-check things I may have missed.