Security versus Compliance

In this post, I talk about what drives a more secure organisation. Is it by doing all the right things, ticking all the boxes or a pragmatic blend of the two?

Introduction

In previous posts, I've talked about PCI-DSS and GDPR compliance amongst other things. I'm indeed walking you through my firm's journey towards compliance with the GDPR and have mentioned such things as ISO27001 and the like a number of times.

What I want to talk about in this post are what the motivations are for achieving compliance. Are they based on appeasing an auditor and getting that certificate on the wall, or are they founded in having a really good and therefore easily evidenced security posture? Or is it a bit of both?

Let's begin.

Breaking new business

I think it's fair to say that practically all firms like to do business with other firms they trust. Where does that trust come from? It comes from a number of things, such as a good reputation for quality of products or services, reliability, cost effectiveness, easiness by which to do business with and so on. Some, or all of these factors are important when you decide who you're going to invest in.

What about security? Well, what about it?

These days, many firms considering a new supplier will look at partnering with someone that takes information security seriously and that's really important. The thing is, how do they do that? Invariably, they look for compliance with the various topical or relevant industry standards, so we're talking:

• CAS(T)
• Cyber Essentials (Plus)
• ISO27001
• PCI-DSS

And so on.

It's obviously important for a firm to trade with a supplier that complies with some or all of the above standards, as again it gives them the confidence that said supplier is handling data responsibly and ensuring that processes are water tight, systems are in great shape and people are behaving correctly.

With the GDPR and PCI-DSS, it's a mandatory requirement.

Badges are shiny

So, based on the above, it seems perfectly logical that organisations do all the right things, meet the requirements for compliance of relevant standards, or legislation and so it's easy, right? Well, no.

Maintaining an effective security posture and complying with standards aren't necessarily the same thing.

The real world

Here's an example. You have a process that has been thoroughly defined, deployed and documented. That looks awesome to an auditor and may well get you a tick in a box. But hang on, what if that process isn't being properly followed by the human operating it, say for example they're in a rush and are able to skip steps? Or, they don't understand the real need to follow that process to the step and again, skip things? The process fails. If that process involves say personal data being removed, then you've failed and that personal data lands in the 'retained forever' bucket and you're in breach of local data protection legislation.

Look more closely though. Because you've got clear processes and so on, you appear to comply. However, because they're not being properly followed or executed, you aren't. And you've failed.

Let's take another example. Your company produces bespoke software solutions to satisfy discrete business requirements. That's pretty common. So, you craft a bunch of guidelines and whatnot for developers to read and adhere to. That looks great in an audit, because it demonstrates that you take secure coding seriously. But, imagine no one reads them and there's no one there to check that those guidelines are being implemented. Yep, developers just do whatever is needed to bang that vital feature out of the door.

Compliance > Security

"Yeah we do that".

That's another problem. When asked whether a process is being followed to the letter, the response is often affirmative. An audit of that process should tease out whether it is indeed being followed to the letter, but on many occasions, it doesn't and the auditor moves on. "OK then, show me" should be the stock reply as far as I'm concerned.

In fairness, auditors can only look at a small section or sample of a business's processes, so inevitably they can't establish the full picture. No, that only happens when something goes horribly wrong, then it's a root and branch assessment.

Culture

The forthcoming GDPR has been a watershed moment for many organisations. Some of that has been due to the way they've taken the responsibility of driving compliance and some of it has been through the sheer dread of failing and the monetary penalties it might bring. Some of it has been due to firms realising that individuals have a right to privacy. I think our firm is in the latter category.

Historically, firms have seen compliance as the goal, which is a missed opportunity to put great data security front and centre of their mission. There's a term for this:

A compliance based approach to security

As I've said in previous posts, you do all the right things, the compliance should take care of itself:

A security based approach to compliance

Is it that simple though? Of course it isn't. You can't secure all the things to an absolute degree. That's simply not possible and anyone that says otherwise is a snake oil peddler.

No, you take a risk based approach and you apply controls where they're needed the most. Then, you assess the risk again and accept or further mitigate it as appropriate. That's pragmatism. And also common sense.

Where's my head at?

As an information security professional, I often find I'm juggling vulnerabilities with the real world likelihood of them being exploited. Take 3DES encryption for example. It became insecure last year, as theoretically it could be exploited. But you know for the majority of the planet, the actual risk was minimal to none. So, I instigated a plan to remove support for it, but not as if it was a zero day nightmare scenario, such as SMBv1 support.

There are many similar examples, where you ideally should fix problems, but the chances of you falling foul of them are so remote, that you place them lower down the list of priority. Again, this is about blending security with compliance and being pragmatic.

Even today, the PCI Council has relaxed its hard line on support for TLS1.0 (and even SSL!) on POS machines. Why? Because they realise that rolling back support for those broken protocols is harder to implement in the real world than they originally thought. Some are seeing this as bad guidance. I see this as a pragmatic realisation that the world can't just suddenly not do something because it's no longer secure and that it needs time and support to get it right.

Final thoughts

It's nigh on impossible to get everything absolutely right, when it comes to information security. Hell, companies are now publishing responsible disclosure policies and launching bug bounty programmes and that's a direct reflection of this.

You become compliant because you're following the policies, processes and procedures that you prescribe and that fit your business. And of course if you're also applying the necessary controls to ensure they're not being abused or are failing in any way.

You're also compliant if you seem to be able to evidence those things, even if you're not doing them.

If you're doing the right things, you fully understand the material risks and can accept them, then you're taking a security based approach to compliance.

And I subscribe to that with all of my heart.

Thanks for reading.