Building Alliances – or, Why Security is Awesome

Time to Go Fast

We work with a lot of people who are implementing Continuous Delivery. We see that when various bumps and boulders get out of the way of delivering software stably and rapidly, there’s a strong push to go very very fast. When this happens, there are often barricades put up in the name of security – because traditionally speed and security have been considered enemies. Traditional enterprise IT security would say, you can’t possibly go fast in a safe way, 

However…that isn’t actually true. And despite the storied past of speed and stability being enemies, enterprise IT is starting to understand:

…speed depends on stability, so good IT practices give you both.
– Martin Fowler, foreward to Accelerate

Speed and Security are Allies

We recently gave a talk about Kubernetes security, and the section our audience found most interesting – and the section that we found most interesting, after arguing about it a little bit – was a section addressing this very thing. We thought it would be good to distill that section into a blog post explaining our thinking about AppDev speed, agility, and security.

Possible Responses to Threats

Security threats to enterprises via their applications are real, and there are a few likely enterprise responses. Ideally, they respond to threats in ways that help everyone see that not only is security is helpful and not the enemy of innovation and delivery speed – but actually, security helps to enable innovation and delivery speed.

Possible Response #1: Cover Your Eyes, Pretend it’s Not There

“We’ll just ignore that there are security threats.”

Speed in the moment: highest
Likelihood of catastrophes: very high 
Pain/interruption of daily process: medium, varies with awareness of reality
Overall speed: slow

This approach is all too common, especially in overloaded teams with no room to think or even breathe. They can’t get their heads up above the water level long enough to see what’s coming at them – so they have to prioritize and that means ignoring security threats. 

Hopefully these teams can prioritize the actual worst threats – but it’s hard to prioritize if you don’t have time to think.

Possible Response #2: Everything is a Threat

“We’re afraid of everything – too afraid to make a plan. So…can you go through all of your code, line by line, and report back that there are no security issues (or other illogical, unhelpful things)?”

Speed in the moment: lowest
Likelihood of catastrophes: highest – not only ineffective, but gives a false sense of “security”
Pain/interruption of daily process: highest
Overall: slowest and most painful

This is the other side of ignoring threats – assuming that everything is a threat, and therefore trying to pay attention to…everything. Again, this tends to come from a complete lack of the ability to prioritize, which is how everything becomes the most important problem. When everything is important, nothing is important – except you have much higher mental and emotional load from the panic.

When everything is important, nothing is important – except you have much higher mental and emotional load from the panic.

(And…as much as we wish it were an exaggeration, yes – some companies do have multiple experts analyze every line of code for possible security issues. It’s massively expensive and no guarantee of safety – but they have to decide if it makes sense for them. Also that’s far from the goofiest security thing that’s been discussed on the internet – here are some examples, and some more examples.)

Possible Response #3: Open-Eyes, Reasonable Priorities, Brain Space to Address Things, and Trust that Recovery is Possible

“We acknowledge that threats exist, and we’ve made the best plan we can for proactively addressing them – and we trust that we can adapt that plan if we need to. We just… do security, built into our processes.”

Speed in the moment: medium to high, especially with automation
Likelihood of catastrophes: lowest
Pain/interruption of daily process: low
Overall: fastest!

And then there’s this option – security woven into all aspects of the application development and deployment life cycle, and done with reasonable asks and enough trust that if a catastrophe occurs, it’ll be okay. 

…we like this one the best. Probably you guessed that.

The Importance of Clarity: Application Development/Infrastructure/Security Communication

Like so many other things in transforming organizations, successfully building an agile, high-trust environment requires clear communication – of advantages and goals, and also of risks and challenges.

App Dev and Architecture teams often have their own history, vocab, and understanding about the process of producing quality software. IT Security/Data Security teams often also have their own history, vocab, and understanding about the process of creating and running secure software. Bridging these gaps and working together – usually with a lot of up-front clarity, and hopefully with shared goals from leadership – goes a long way toward building the successful, trusting, agile culture that fast application delivery requires.