The other day, I walked past a meeting where a couple of engineers were debating whether an added security feature was necessary or not for SOX compliance.
So, which matters most when deciding what to do – should you be more engaged in practices that add security to your organisation, or should you attempt instead to keep up with regulatory, contractual or standards compliance?
As usual in the field of information security, your end customers aren’t actually going to care, as long as nothing happens. When a breach happens, they will care that you didn’t secure that breach, and they will care doubly if the security lapse you had was something that left you out of compliance. While “we were compliant” will not win you any friends in the event of a breach, “they weren’t even compliant” will definitely make the situation seem far worse – especially if the standard to which you didn’t comply is specific about technological measures that you should have taken, but didn’t.
Your chain of command will be significantly impacted by a breach, too – and again, while their careers may suffer from a breach (it shouldn’t, if they’ve handled themselves correctly and you have sane management), if you are found to be out of compliance, you may have cost your superiors money, or in some cases, their own personal freedom!
But as with all questions of compliance or regulation, there’s a get-out clause. If you achieve – or beat – the level of security that the compliance regulations were supposed to ensure, you can claim compliance by virtue of compensatory controls.
A good example is that of wireless security and PCI.
PCI says to use wireless encryption.
If you can’t use wireless encryption, you can compensate – either by making sure that no credit card data travels across the wireless network, or by using network encryption – IPsec or SSL, say – to achieve the same purpose, of protecting the credit card data from being intercepted.
Clearly, you can’t ignore compliance for security’s sake, and just as clearly you can’t ignore security for compliance’s sake.
But if you ever find yourself arguing whether a security feature is required for compliance, consider whether it’s just a plain good idea, compliance or no. That may be a quicker argument for its inclusion.