Happy Friday Everyone!

Yep, I’ve used the words “fun”, “security” and “compliance” in the same sentence, and I’m not trying to sell you anything!

In line with cybersecurity awareness month, I want to talk about functional security vs security ‘compliance’.

Simply put, security compliance is about achieving the correct tickboxes on a form, to say you’ve done something, rather than functional security, which is about strengthening a security weakness.

Like a few of these, this is inspired by some tech battle scars… Here’s my example:

The client wants to comply with a security standard. The timescale: Yesterday.

I’m sure by now, most of us have had a client like this, they want the piece of security conformance paperwork for their bosses to be happy, but they don’t want to put in any work for this.

I was asked to consult for a client requiring a firewall and some professional services to be utilised, easy enough! But oh boy, was it an interesting scenario when I got there.

The client wanted to achieve a specific piece of security conformance related to payment processing, as you can imagine, this required a huge amount of security standards to be met.

My very first task was certainly a box ticking exercise. The security standards required dual firewalls. Realistically, this is intended to prevent issues via a single vendor having a known vulnerability from hijacking the entire network via this. Instead what did the customer do? They bought a second, lower spec firewall and wanted me to put it in front of the other! I tried to explain this actually made their security posture worse, as any attacks would overcome the processing capacity of the weaker firewall before it even got to the faster one, but alas, they didn’t budge on this.

Then came to a reverse proxy. And when I say reverse proxy, I mean a Windows client PC with a few NICs in running IIS with Application Request Routing installed. Again, I highlighted that PCs shouldn’t be doing server work (especially the Windows licensing), but this was their investment, and I had to implement it. I configured it, but it wouldn’t work. Why? Because of a refusal to purchase a trusted SSL certificate, instead the reverse proxy was rejecting their 7 year expired, self-signed certificate (at least it meant I’d done this right!). I managed to convince them that this had to be sorted, and stepping down to HTTP was not an option.

Now, none of this actually provided any real security benefit to their organisation, if anything it had made their security posture weaker, but they’d contorted their solution to vaguely meet the guidance of the security standards, undermining the whole point!

I recall not long after implementing this, I got a call from them, they’d missed a key step, all outbound traffic must be rejected by default. Their audit was the following day, what could they do? I suggested taking captures on their firewall to identify the current traffic, identifying & categorising it and then permitting what is acceptable. But also to perform this over a multi-week period to capture less frequent business tasks. They had no interest in this, put in every deny rule they could, broke their email platform and site-to-site VPN and called me asking if I could rush down there and fix it. I was on holiday at this point and told them they need to restore a config backup from before this change, they didn’t have one!

Someone else tried to help them get back to a functional state, and after a few days of being unsure what they’d broken, the solution was to rebuild their firewalls from scratch.

Moral of the story / TL;DR: Ticking a security compliance box is pointless without understanding WHY it is there, and adopting a stance that protects you from the risks they are aiming to mitigate with their requirements. Security isn’t an overnight exercise, it’s a learning & improvement cycle that we are all undertaking a constant journey, and trying to rush through it will more than likely just hurt you!

Now, anyone else care to share?