Tips for Ensuring Better Security with Your DevOps Processes

In "5 Tips for Creating an Effective Agile Development Environment," I covered best practices for adopting and successfully implementing an agile environment. But, before you decide to jump in with both feet, ask yourself one simple question: Have you taken the time to fully develop a security strategy?

Here's a few more questions that might help you answer my initial question. Do you have a security person on staff at your company? If so, can that person write code efficiently?

Hopefully, you see where I'm going with this. These are important questions to ask if you're thinking about implementing DevOps practices, and I'll explain why.

Unfortunately, I think it's easy for companies to overlook security when looking to implement DevOps processes. Similar to the treatment of different IT and developer terms, such as cloud computing or big data, I think the terms agile and DevOps often open themselves up for abuse as a buzzword.

And please don't mistake me for calling either of those terms as buzzwords. I definitely don't regard either of those terms as mere buzzwords, but I think that type of treatment easily lends organizations to get easily swept up and hurriedly rush to get processes in place without really understanding the entire DevOps picture.

With that said, security is a significant piece of the DevOps pie. If you've done any reading on DevOps, then you'll know that a key tenet of DevOps is to bridge the gap between development and operations teams to collaboratively and rapidly deliver software and services on a regular basis.

As I've mentioned in previous articles, agile and DevOps processes are inherently iterative. You're developing small chunks of demonstrable functionality. As a development team continues to pile on functionality in short time spans, emphasis might be placed on stability and shipping those features on time. When those concerns rise, then what's the impact on security? Stated differently, I argue that security is treated as an afterthought because the business' first priority heavily feature-driven.

I had the chance to listen to a session on DevOps security led by David Campbell, co-founder of JumpCloud, and Will Morton, DevOps Engineer of Beats Music.

Will Morton emphasized the point that security is important, but it's typically not the first priority for businesses. Morton asked the audience, "Can anybody think of a company that has failed because their security was bad?" Quiet chuckles fills the room; no one lifts their hand. "I've never encountered one either, where we can all rattle off companies that have failed because they have no features, their product is crap, or they haven't shipped," Morton said.

Morton and Campbell provided a threat continuum to demonstrate different levels of attackers that might hurt an organization. Here's a breakdown of each level:

Morton notes that the main point to take away from the threat continuum is that it's much, much more difficult to successfully defend against the elites compared to the other two groups. However, there's a sharp decline in middle of the threat continuum, which Morton likes to call the sweet spot. Morton advises that finding your organization's sweet spot is crucial. Although it's a bit of a fatalistic notion, Morton urges organizations to accept the fact that they will be hacked. Because complete prevention is an unrealistic goal in terms of time and money spent, the main idea here is survivability. That's to say, what's your organization's plan for how you will recover in the event of an attack?

Morton and Campbell provides several different suggestions that help businesses find their sweet spot. More obvious recommendations include deploying patches automatically and having good password management. Code auditing can be a huge help in thwarting attacks to determine vulnerabilities. Although IDSs can have their drawbacks, they can be useful in identifying low-hanging fruit, such as failed logins or suspicious application crashes. Where IDSs are concerned, you should be going after very obvious issues rather than trying to go after every single thing that's identified by an IDS.

Implementing security processes might seem like a daunting task, and that might ring true for startup companies. However, Campbell stressed the need to rely on automation to improve security and attack recovery time. Campbell provided an example where an organization pushes code to production several times a day. "If I'm pushing ten to 100 times a day, is anybody auditing that? Manually? No. But say we find a critical security flaw. Instead of having to wait to a patch Tuesday…, we can push it out today. This is a huge leap forward if we accept that we're not going be able audit everything manually," Campbell explained.

Morton also recommends that organizations automate to speed up the time it takes to rebuild after an attack. This can includes automating updates to your configuration, critical services, network infrastructure, databases, and applications. Finally, Morton urges organizations to test those scenarios. This type of recovery process should be identical to your regular deployment process.

To reiterate Campbell and Morton's advice, it's important to find a sweet spot of risk versus reward for your business. Find time to integrate automated security into your DevOps, and test your recovery practices to ensure their reliability.

Like most development processes, implementing security procedures isn't a one-shot task. Monitor, log, and graphic anomalies in your application. Be proactive and determine the impact of those anomalies. And most importantly, feed those fixes back to your configuration management tools.

"Security is not a binary event. Security is something that happens continuously," Campbell explained.