Security vs. Compliance: What’s the difference?

Following a recent and frustrating password experience, I was reminded of some of the ways we–as security professionals–can sometimes undermine the very culture of security we’ve worked so hard to imbue in our users. 

Through my experience, I’ll highlight the confusion and other pervasive problems it exposes, explaining the differences users and security professionals should be aware of surrounding the distinctions between compliance and security. Then, I’ll present some strategies that might help reframe our mindset and move forward. 

My tale of password creation woes

Creating a new password: we’ve all been there, just as we’ve all been faced with the issue of creating a password–only to find it doesn’t work with the system in some way or another (e.g., doesn’t follow the requirements). 

In this instance, I went to my password manager, generated a 30+ character random password with uppercase and lowercase letters, numbers, and symbols, and proceeded to use it in the website I needed to access. 

Upon hitting submit, I was surprised when the following message appeared:

PASSWORD DOES NOT MEET COMPLEXITY REQUIREMENTS 

I thought to myself, “Hmm, weird. What could the requirements possibly be that I’m not meeting?” So, I went back and checked the webpage:

Password must contain characters from three of the following categories:

• Uppercase letters
• Lowercase letters 
• Numbers
• Special characters

For an example, let’s take a randomly generated password for comparison. 

Sample password: 

NooV814^uOy5KFMrGSy3fHi*gcK8x5$3Nbvn

I would consider this password to be pretty good and–given the limits of current computing capabilities–would be a fairly difficult one to crack. But the site still refused to accept it. 

Frustrated, I tried other options: reducing the complexity, trying different special characters, removing those entirely, shortening it significantly, but the site wasn’t having it. Eventually, I thought, “Okay, what’s the simplest password I can use that meets this requirement?” 

• Password1
• Test1
• LetMeIn!
• Football!
• Passw0rd

Defeated, I tried a similar password to one of these above, based on a dictionary word, containing a number and an uppercase letter. Finally, the site accepted it, and I was able to log in and access the required security awareness training I needed to complete. 

Sometimes we’re our own worst enemy

As my example illustrates, I was simply a user trying to do the right thing by following the security recommendations for passwords (e.g., setting a secure password and having a password manager), but the system wasn’t allowing me to make the secure choice. 

The irony of such a system limitation–as the one in my password story–surrounding the very training designed to encourage good security behavior, is something that cannot be ignored. 

Some bad habits in security culture go beyond the user. If we’re reinforcing the behavior we’re also trying to eliminate, we become part of the problem. As security professionals, we have some improving to do, too. 

A few other bad security behavior examples that come to mind 

I’m sure many of you will be able to name security products that only work correctly with a specific version of Java or Flash Player installed or–dare I say it–Internet Explorer. I’ve even seen security decision-makers email employee/contractor PII instead of using a more secure method (which begs the question, why are we collecting that anyway instead of challenging those company policies–but that’s a post for another time). 

Why compliance =/= security ?

Think of compliance requirements as guidelines for establishing a better security posture. While they can improve the security of your environment, simply following the compliance requirements to the letter won’t often reflect the best security practice (I’m looking at you, PCI DSS 3.2).

Security best practices are often composed of recommendations from multiple compliance frameworks combined with new information learned from current research and industry trends. Security evolves as time goes on, however, and best practices often will evolve much quicker than the compliance frameworks are able to keep up.

Furthermore, a compliance framework will often focus on controls facing a specific industry or area of an environment. PCI, for example, is focused on the cardholder data environment (CDE). Even if you did everything perfectly in the CDE, but completely ignored any and all security best (or even recommended) practices elsewhere, your environment would remain unsecured. 

Recommendations for change 

So, I’ve ranted for a bit here. While I hope to have made the issue clear, it’s important that we also use this as an opportunity to make things better. Here are a few suggestions that come to mind:

For users

Here are a few ideas:

• If you find security requirements for an application or site confusing, raise this issue to someone who can help fix it. You’re almost certainly not the only one who is experiencing the issue.
• Find someone you can trust to provide advice on security issues. This makes it easier to ask for help when you need it. 
• If you see something that looks suspicious or unusual, report it or ask for a second opinion. 

For security pros 

Here are a few ideas:

• Don’t consider your yearly assessment the solution to all of your security problems. If your compliance framework is pushing you to make a change that will reduce the security of your environment, push back and try to seek change. 
• Foster a culture where users are encouraged to speak up about issues rather than discouraged if they make a mistake. 
• Encourage your security team members to keep each other honest and uphold the same standards you expect from your user. 
• Protect and prevent the disclosure of the personal information of your employees, customers, vendors, and contractors the same way that you would protect your own.

In conclusion 

It’s no secret that the best or most secure approach is rarely the easiest. With the constant demands for our attention and issues to resolve, it’s often easier to eschew best practices and move on to more pressing matters. But every time we do this, we erode the foundation of our security castle that we’re looking to build. 

The bottom line is we all need to work to create a positive security culture and hold ourselves to the same standards we expect of those we support and protect. Let’s start now.