After a decade of doing compliance assessment work, I am coming to terms with an uncomfortable truth: nobody likes compliance. It is 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 am 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 a 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 is busy work, 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:
- Leadership creates a security team that is separate from the rest of the organization.
- This team wants authority. It therefore uses security and compliance as a hammer to force that respect. Thus begins the antagonism.
- This annoys people. The more security people lecture everybody about compliance, the more people become annoyed.
- 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.
- This further isolates the security team. Eventually, security demands direct access to leadership, so they can unilaterally enforce compliance on the organization, dialing the antagonism up to 11.
- These behaviors cause the security team to become more disliked, marginalized, and disrespected, which consequently makes compliance disliked, marginalized, and disrespected. (Incidentally, this also makes the compliance assessor, disliked. I know, I have been there many times, with many organizations.)
- Bring on the checkbox assessments and over-reliance on technology in a futile attempt to fill the gap. Now we have morons in meetings bleating out “compliance is not security” and feeling good about being irresponsible.
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, compliance becomes the tool to force their way into a conversation. And when compliance is the hammer, nobody wants the hammer.
Collaborative Compliance and Security
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: 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 in 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 is 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 (I got a blog about that too.)
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 truly 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?
- Show, Do Not Tell: It is not about being right, its about contributing something tangible of value.
- 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.
- Now, 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.
- Go ‘way, collaboratin’: Most technology vendors prefer antagonism. Keep those vendors at a distance.
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 are 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.
Andrew Plato is president and CEO of Anitian, a former VAR that transformed into an MSSP and now a cloud security and compliance automation company. Read more of his views here.
