Is your compliance hurting your security?
Compliance v’s security, an equal match? Let me state first that compliance isn’t the same as security and measures to bring about compliance could harm your security, and I’m not the only one saying this.
“Compliance is all about reducing risk but compliance often has very little to do with reducing risk.”
Roger A Grimes, (Former) Principal Security Architect, Microsoft.
If you operate within Europe then you’re almost certainly going to have to comply with certain regulations. The Regulation that springs to mind would be GDPR but there are others as well such as PCI-DSS or PECR that you may have to give credence to as part of your day-to-day activities.
The challenge is that compliance requires an audit mentality, as opposed to security, which requires a tactical mentality. Security is risk-focused whereas compliance rarely is, despite a lot of people thinking that it is. We recently wrote a blog post on this topic, if you want to learn more about the importance of cyber security within the UK GDPR.
Compliance v’s Security: and the winner is…
Sadly, when compliance conflicts with security, compliance always wins. The C-Suite will always be far more concerned about meeting a compliance requirement, for fear, in the case of GDPR, of being levied with a fine of 4% of their annual turnover and potentially losing their job.
It is therefore unsurprising that an experienced CISO wanting to get something passed will tie their security requirement to a compliance requirement for resources to be allocated. Regulations must always be complied with regardless of the impact (positive or negative) that compliance may have on your security posture.
Compliance v’s Security: Let’s talk password policy
A pertinent example would be to look at the ‘Account Lockout Policy’ that most enterprises will have. Most of these policies will specify that a user must wait a set period of time or have their account unlocked by Admin if an incorrect entry is submitted more than (typically) three to six times.
However, if you have strong passwords and everybody should already have strong passwords that can’t be easily hacked (read our blog on password security tips), you mitigate almost all of the need for account lockout policies. The only reason to have such a policy is to get a warning that somebody’s doing some sort of guessing against your passwords. Otherwise, you really don’t need it. Not only that but lockout policies can and have allowed hackers to create denial of service events. By using a password manager of some sort – you further mitigate the risks of a breach due to human error such as being lax with password hygiene.
This happened enough that Microsoft decided they were no longer going to recommend a default account lockout policy or recommended you set it over 100 so that you at least wouldn’t be locked out by password-guessing worms because for whatever reason they tend to guess 100 weak passwords or less. So again, the way to fix this sort of thing is to — tell compliance, “we really don’t need account lockout. We’ve got good passwords”.
In a perfect world, you would be able to go to people and say; “Hey, we want an exception to this policy. We think that it hurts us more than helps us. And here’s the difference or the deviation. We’re turning it off or setting it to 200 so that we get both security that the account lockout policy is trying to provide, and we don’t create self-denial services type of events.”
Another challenge with compliance is that it’s binary by nature, Yes or No, did you meet the control or not? Compliance won’t care if you exceeded some control areas and had better security, whereas minor exceptions are seen as total failures. In real life, security is rarely binary but rather a grey scale with white as total security and black as none.
A risk-based approach to compliance
We believe that compliance should be assessed differently and should be risk based, as opposed to checklist based. Companies should be assessing their controls based on whether they reduced risk. Proposing the removal of account lockout because we have strong passwords or a policy set to 200 instead of three to six, shouldn’t be classed as a failure because by doing so we’re significantly decreasing cyber-security risk, that should be a pass.
Here’s another good example that all of us will be familiar with. Many of us will have seen a password policy that must be eight characters long, contain complexities so several different types of characters, letters, numbers, symbols and they must be frequently changed like every 90 days or something like that.
The problem is that if you were to try to use a 16-character non-complex password, which would be far more secure than an 8-character password and far easier to create and use, the policy would not care. If you do not have complexity, it fails. You could have a 50-character non-complex password and it would tell you it fails.
It seems silly that you cannot create a more secure password which is easier for people to remember like a passphrase. A longer non-complex password is more secure than a shorter complex password. Part of the reason is that you can never guarantee complexity. Research by Microsoft revealed that approximately 90% of all passwords share the same characters. Complexity would be great if you could truly choose random passwords but then nobody would remember them.
Whenever given the choice, long passwords, without complexity, are more secure and easier for the user to use but it may not be an option. There’s not a regulatory compliance guide that allows that right now. Which is strange because the National Institute of Standards and Technology in their new digital guidelines that came out in 2017 said that you should not force users to use complex passwords, you should not have to require length and not have mandatory forced changes. So NIST said, if you use complex frequently changing passwords, your company or organisation is more likely to be hacked than if you don’t.
Since 2017 when the NIST guidance was formalised none of the compliance guidelines have been updated to reflect this. Except for maybe Microsoft and that’s recently. Of course, you don’t have to follow NIST, other standards (such as ISO) are available, but if you must follow PCI, they still require that old password policy; a policy that the U.S. government says is more likely to make you a victim of hacking.
Again, compliance is binary, not risk based. They don’t care if it’s a more secure password. They care that it’s a complex password.
Compliance v’s Security: What’s the solution?
In relation to password policy, a very simple solution in our opinion would be for compliance policy to include the words ‘equivalent’ or ‘stronger’. For example, use an 8-character password with complexity that’s frequently changed or equivalent or stronger. That way if somebody wanted a 16-character non-complex password that is for sure stronger than an 8-character complex password, it would still meet the compliance requirements.
Need help?
If you’d like to find out more about a risk-based approach to cyber-security compliance, please contact.
