Security change controls can slow down a DevOps program. Lets break up monolithic security systems instead of giving developers more security responsibility
InformationWeek, Sep 3, 2014
Here’s the latest misguided notion to come along in DevOps: Let’s operationalize security so developers can handle their own security changes.
Like most bad ideas, this one arrives with good intentions. We want to make it possible for developers to make changes more quickly, without getting into drawn-out change control processes.
So why not create automated security modules that let the dev team cut the security team out of the picture? As a recovering developer myself, I’ll tell you why not: because we’re jerks.
Developers open ports when we need to, without thinking about the implications for the broader business. We run roughshod over regulatory compliance. We don’t give a moment’s thought to the other developers we work with. We care only about making our own apps the best they can be.
That kind of attitude can be a tremendous asset because it can result in great software. But give developers the keys to security? I don’t think so.
If empowering developers isn’t the answer, what is? How can we speed up the policy-setting process and streamline change management while making sure that each change makes sense and doesn’t expose the business?
We already know that automation is part of the answer. You can push down pre-packaged rules to tell a firewall to open a series of ports, and if your syntax is correct, it’ll work.
However, that’s only the technical solution to the problem — you still need a human to ensure that doing so won’t expose vulnerabilities across a bunch of other apps.
Instead of trying to reduce or eliminate security’s role in change control, we need to simplify it. The reason it can take six weeks to implement a change in a firewall’s rules is that there may be hundreds of apps to reconcile against the change.
But with the rise of virtualized network infrastructure and SDN, we can now replace a handful of big firewalls at the edge with a lot of small, per-app firewalls with per-app policies. That way, you only have to look at a developer’s request in the context of that one app. The security team can approve changes much more quickly, then let automation tools take care of the brute-force stuff.
This approach isn’t limited to firewalls. As enterprise infrastructure has grown, it has become too complicated to consolidate and aggregate into just a few big chunks. We need to break it down into smaller, simpler pieces wherever we can.
That’s already happening with the VPN. I see organizations that now run many little VPNs because they’re easier to manage than a handful of big ones with a thousand rules no one can track. The same can apply to load balancers, proxy servers, IDS/IDP systems — the list goes on.
As you replace big with small, and complex with simple, you can reduce the number of people needed to manage change control across your infrastructure.
This isn’t a new way of thinking — it’s a lesson developers learned back in the 1970s. In his book A Quarter Century of UNIX, Peter Salus describes a key concept embraced by those early UNIX developers: to write one program that does one thing, then chain it together with other small, single-purpose programs to make a big program.
The premise of chaining individual programs is mirrored in the service chaining we see today in SDN — each service element does one thing well in an easily understood way, and multiple services can be chained together to build apps.
After two decades of focusing on cramming more and more into integrated boxes, infrastructure guys are finally coming around to the beauty of simplicity.
Developers may be jerks, but when they’re right, they’re right.
Author: Steve Shah is Senior Director of Product Management in the NetScaler Product Group, where he drives product direction and go-to-market strategy. Before returning to Citrix, he was Principal of RisingEdge Consulting, a boutique consulting firm that specialized in strategic … View Full Bio