The Problem with Compliance

After a decade of doing compliance assessment work, I’m coming to terms with an uncomfortable truth: nobody likes compliance. It’s a miserable time-suck that slows down forward momentum.

How did this happen? Where did compliance go wrong? Why is compliance (as well as security) so disrespected?   

A meeting I attended a while ago gave me some insight into the problem with compliance.

Serious Meeting is Serious

This insightful meeting was with a client’s development team, as well as their lone security professional. This company was building a new application. The application handled payment card data, and the security person wanted some guidance from a QSA (Qualified Security Assessor, for PCI compliance.) I was ready to share my QSA expertise.  

While the developers discussed various topics, the security person sat quiet, occasionally breaking his stupor to jab at his phone. When the topic turned to data storage, the security person finally awoke to interrupt the lead developer: “No! You cannot store that data there! It is a PCI violation.” And he returned to his silence, smugly stroking his CISSP. I could sense something was wrong. So rather than speak up, I remained quiet and listened.  

The only thing louder than the lead developer’s sigh was the nauseating clicks of all the developers’ eyeballs rolling back in their sockets. “Okay, whatever,” the lead developer said, “compliance is not security anyways.”  

Hmmm, these devs have no respect for compliance… Or the security person for that matter, I thought.

The security person became visibly annoyed. I knew what he was thinking: “I’m right about this! They need to respect me!” Being correct is not the same as being right.

As the meeting wore on, the developers continued to discuss features, and the security person continued to ignore them until they happened upon some compliance issue. The security person would lecture them on what was and was not permitted. This continued to annoy the developers. I feared this was going to end poorly.

My suspicions were validated a few days later when that security person informed us that the developers had “removed him from the room.” He wanted a compliance assessment to force the developers to take him more seriously.

Those developers were never going to take him, or compliance, seriously.

Compliance Is Not Security

I loathe this phrase. It is cynical and dismissive. It is accepted as some wise gospel when it is merely a cop-out. The whole point of compliance frameworks, like PCI or FedRAMP, is to promote better security. If compliance is not synonymous with security, then why do it at all? 

However, as much as I loathe this phrase it is largely true. For most organizations, compliance has nothing to do with security. It’s busywork, delivering false assurance. Security teams will often distance themselves from compliance, preferring to focus on technology or hacking attribution.  

We accept this phrase as gospel to hide a more serious dysfunction about security and compliance: antagonism.

Antagonistic Compliance

For most organizations, both security and compliance have an antagonistic relationship with the rest of the company. The meeting I mentioned earlier was an example of this kind of relationship. Security stands apart from the rest of the company and is routinely arguing against actions deemed insecure or non-complaint.

Hence why security is often called the Department of No. This antagonism problem, like most organizational problems, it starts up in the leadership offices.

Security antagonism comes to life like this:

1. Leadership creates a security team that is separate from the rest of the organization. This team sees its charter as enforcing security (bad).
    
2. This team needs authority. It, therefore, uses security and compliance as a hammer to force respect. Security people lecture everybody on what they must do. 
   
   
3. This annoys people. The more security people lecture everybody about compliance, the more people become annoyed. 
   
   
4. This causes a loss in authority. Consequently, security pushes harder to enforce compliance, demanding outside assessments and more tools (like GRC portals, and AI fueled EDR, etc.) Compliance = hammer.  
   
   
5. This further isolates the security team. Security demands more time, resources, and of course tools. All of this is to make their hammering more effective. In time, they also demand direct access to leadership, so the hammering can be codified into the organizational culture. 
   
   
6. These behaviors cause the security team to become disliked, marginalized, and disrespected, which consequently makes compliance disliked, marginalized, and disrespected. 
   
   
7. Leadership grows frustrated with this stalemate. So bring on the checkbox assessments and over-reliance on technology in a futile attempt to fill the gap. 

This plunge into antagonism is disastrous. Compliance may be required, but the ends do not justify the means.

The problem ultimately boils down to two core issues:

• Security is treated as a separate practice, rather than integral part of development.
  
  
• Compliance is treated as an external force, rather than integral part of development.

There is a common problem there… Integration. When security stands apart from a team, compliance (in some form) becomes hammer force their way into the conversation. And who likes being hit with a hammer all day? 

Collaborative Security and Compliance

If security teams are devolving into antagonism, using compliance as a hammer, then what is the alternative? It may be an overused word, but collaboration.

Security and compliance cannot be the jerk in the back of the room telling everybody they cannot have fun because FedRAMP does not permit fun (it does, however, allow for FIPS-140 compliant FUN.) Security and compliance have to be an integral, supportive part of the whole team.

Easier said than done.

One way to do this: security by default and by design. We’ve actually got another blog on that. Security and compliance are integrated directly into the infrastructure and application code. They are not optional, they are not bolted on later, they are there from the very beginning.

Security as Code

Imagine the meeting I mentioned at the beginning of this article, but with a collaborative environment, where the security person was in the code. It might sound like this:

Dev_1: I got the new module ready to commit that processes payments.

InfoSec: How does it store the data?

Dev_1: Plaintext to a public S3 bucket, that the API picks up and…

Infosec: Whoa, hang on. We got PCI issues here. I have a code snip that will save the data using strong encryption and to a protected location. It’s in the GitHub repo. I’ll help you get it integrated. Let’s sync up after lunch. I will show you how it works.

Dev_1: Okay, thanks!

That is collaboration. The security person was contributing to the development effort, rather than merely telling the devs what they could and could not do. The security person was in the code, contributing to the product. The end result was an application where encryption was enforced by default and by design. 

This is Security as Code. Security is coding the environment to be compliant (and secure), rather than telling other people what they can and cannot do.

To state what should be obvious at this point, this means security needs to write code. This is going to terrify a lot of security people, who have no coding experience and have grown comfortable with saying no. Time to dust off that YAML book that has been sitting on your Kindle for 9 months.

It is no longer acceptable for security people to sit smugly on the sidelines, lecturing everybody. Nobody likes that person. And it does not matter how accurate you are, being a smug know-it-all makes you unlikable. Security has to come to the table with an answer.

Compliance Automation

Of course, we faced this conundrum at Anitian. After a decade of doing compliance work, I became disillusioned at how ineffectual our advice was. No matter how precise, accurate, and well-intentioned we were, nobody wanted to do compliance.

Our answer was to automate compliance and remove the antagonistic relationship entirely. Compliance Automation shifts compliance from a bolted on annoyance, to an integral part of the entire infrastructure. Rather than lecture developers on compliance, we hand them a pre-configured infrastructure that makes their applications security and compliant, by default and by design.

This is the future of security and compliance. Not gap assessments, lectures, and theories, but code. But code, that deploys, configures, enforces, and monitors security and compliance by default and by design. Security will cease to be an add-on component, but a fully integrated aspect of the infrastructure. There will not be any more non-compliant environments, because compliance will be an integral part of the infrastructure code. And audits will become a true checkbox exercise, because the code does all the hard work, generating compliance artifacts.

Mostly, security will no longer be the Department of No. Rather, security can become a fully collaborative part of the team. This allows security to contribute to the effort, rather than delay it. And that is something developers, and leaders can respect.

How You Can Build Collaborative Security

So how can you create a collaborative security team?

1. Show, Do Not Tell: It is not about being right, it’s about contributing something tangible of value.
2. DevOps: Security teams need to operate in the same iterative, high-speed practices of DevOps. That means you are willing to try new things and perfect them as you go.
3. Go cloud: On-premise environments are too inflexible and static… Like antagonistic security people. Automate everything. make the cloud do the grunt work, so you can be more helpful.
4. No More Toys: Stop throwing technology at every problem. Most of the tech you need you likely already have. Make it work.

Conclusion

I fully acknowledge writing code is scary for a lot of security professionals. Decades of twiddling with firewalls, pounding out compliance reports, and lecturing people on how TLS 1.0 is deprecated, become irrelevant in a collaborative environment. That’s because the firewalls are configured automatically, reports are easy to fill out, and who cares about TLS 1.0, the code does not allow it to be used anywhere. 

Antagonism is not the future. If you’re telling your company what they can and cannot do, you are an impediment. The future of security and compliance is code.

And when compliance becomes part of the infrastructure, then compliance *is* security. As it was always intended to be.