The Tragedy of Security Dies on the Crucible of DevOps
Security ain’t what it used to be. Or perhaps it’s always been this way and it merely seems different due to the slow degradation of my youthful idealism.
Security is bifurcated. Down one path we strive to keep our organizations secure. To stop bad actors, protect data and assets, and defend users from threats and even their own mistakes. Down the other path lies compliance. Ensuring the organization meets regulatory, contractual, and other standards. Across both paths we manage risks; the risks of breaches and downtime, or the risks of regulatory fines.
The tragedy of security is a reflection of The tragedy of the commons. From Wikipedia:
The tragedy of the commons is a situation in a shared-resource system where individual users, acting independently according to their own self-interest, behave contrary to the common good of all users by depleting or spoiling the shared resource through their collective action.
Most of security compliance is designed to reduce security risk. At least on paper. But over time we’ve seen standard after standard, regulation after regulation, decouple risk from compliance. The very nature compliance standards prevents organizations from tailoring security measures to organizational risks. I’m not saying this is always true, but it is largely true, especially as you scale into larger organizations. There is no evidence that requiring password resets every 90 days for users with MFA or other conditional restrictions now in common use improves security. The person who invented password complexity requirements literally regrets it and says they don’t work. There is neither evidence nor a sound scientific basis for requiring non-default encryption of all storage volumes in a cloud provider.
Security is a shared, finite resource. We only have so much money, so many security professionals, and so much time non-security staff can dedicate to security at the expense of their other goals. The more we pull towards compliance the less of this pool we have for security. The less compliance aligns with security, the fewer efforts reduce security risks.
This is the tragedy of security. We decoupled risk from compliance, making lack of compliance the risk itself. The greater real risks are decoupled from compliance, the more rigid the compliance regime, the fewer security resources are available for defense, and the less support for security efforts from other teams.
A great example came up in a conversation with Chris Farris. To paraphrase,
Developers do care about security. It’s compliance that is an irritation. Help them secure their application and they’ll support it. Tell them to take a 4 hour outage on a weekend to re-build their database with encryption because a compliance wonk demands it and you’re just pissing them off.
I’m not saying all compliance is dumb rules, but some compliance rules are dumb, and the misapplication of good rules decoupled from risks is really dumb.
DevOps becomes the crucible for the future of security because in the world of cloud and DevOps individual application teams become responsible for the entire stack, including much of security. New servers, networks, and firewalls are a mere git commit and some API calls away. This also places a larger burden on those teams to manage their own security and compliance. We still have centralized security and shared security resources, but when it comes to the tip of the spear we absolutely rely more on the DevOps teams. We can’t create a big DMZ for the cloud. The lines between internal and external networks can no longer be categorized into cookie-cutter zones. Many applications build on native cloud services don’t even have a network anymore and rely on IAM rules and resource policies written in JSON pushed by application teams through infrastructure as code.
Thus a fair few of my recent cloud and DevOps-focused compliance projects are more about doing good security first, and then figuring out how to write a report that makes it looks like it meets the letter of compliance even though it doesn’t, even when it’s more secure.
There are two potential solutions.
The first is to revise security standards to better fit cloud and DevOps and reduce the number of dumb or inapplicable rules. Some of this work is happening, but I’ve come to believe this requires a generational shift we don’t have time to wait for. Let’s not give up, but we don’t have to wait.
The other is to use automation to remove as much of the security and compliance burden from individuals as possible, while still allowing them the freedom and control to build fast. I’m not suggesting the overall pool of security becomes smaller, but that we use automation and other technologies to reduce the individual requirement to burn cycles on the less valuable things.
It’s about time and focus of limited resources. And really, what’s more valuable… a good penetration test or a compliance audit? Now look at how much you spend on penetration testing and how much you pay for an audit.
