Five keys to getting DevSecOps right

ornate-iron-fence

It’s amazing how successfully DevOps has spread through enterprises in recent years. Most enterprises are either completely embracing DevOps tools and practices, or they’re doing so within certain teams with plans to expand organization-wide in the near term.

But the move to DevOps isn’t evenly embraced by all enterprise constituents. In fact, the fast and continuous software release cycles, along with the tearing down of traditional enterprise silos that have existed between development and operations teams, tend to scare security teams. And while every reasonable description of good DevOps practices includes integrating security early and continuously throughout the entire lifecycle — actually doing so has proven more difficult.

Some call this melding of security and DevOps “DevSecOps” and a survey from last month shows that while 98 percent of enterprises are integrating security into DevOps, half aren’t quite there yet. How do those struggling with DevSecOps get there? In my interviews with CISOs, development teams, and others who have been part of DevOps transformations, I’ve found that there are a handful of recurring themes among those organization that have been successful.

1. A focus on building the right culture

The shift to DevOps doesn’t happen without a cultural shift. After all, at its foundation, DevOps is more than just embracing shiny new toolsets and agile practices. No. What really makes DevOps shine is the breaking down of silos between development teams and operations teams — and this requires a significant cultural shift.

Bringing security along for the ride is no different. Veracode’s John Zorabedian provides a good and snappy overview on how to build a DevOps culture, and he writes that it includes openness and ongoing learning, strong feedback loops, creating security “champions” who understand Dev and Ops, and encouraging team autonomy. I couldn’t agree more.

2. A dedication to security training, especially secure software training

As we recently covered, security software testing provider Veracode and DevOps site DevOps.com revealed just how little higher education prepares developers for the security needs of their future employers. In fact, 76 percent of developers indicated that the security and secure development education needed for today’s world of coding is missing from formal curricula.

Enterprises need to take the effort to train developers on secure coding practices, train security professionals on how to secure software built with modern continuous development pipelines, and keep everyone’s skills in security, development, operations, and management up to speed with modern cloud and data center practices.

3. No more chasing waterfalls

Moving to continuous delivery from waterfall development processes is an ideal way to speed time to market and improve agility and service quality. It also means application security cannot be treated as a big application security test at the end of development. There’s no time in DevOps for security teams to come back with reams of printouts detailing SQLi flaws, buffer overflows, poor authentication in apps, and other application mistakes that make hackers salivate. Security testing must occur in design, through development, and as software progresses down the pipeline into production.

4. Automate security functions that can be automated

Development and infrastructures are moving quickly today and the only way to keep up is automation. Security pros, developers and DevOps teams need to fully understand how to automate security testing, software coding security tests, while maintaining secure configurations and so on. If they don’t, there’s no way to keep up.

As Don MacVittie wrote in his post on DevOps.com enterprises need to “automate all of the things” and look for ways to automate beyond simple tool implementations. “The more repetitive work is built into the process, the more InfoSec is available to tackle bigger, less scriptable problem-solving,” he wrote. “Infrastructure monitoring tools make a lot of sense in a world of frequent infrastructure changes initiated by both auto-scaling and more frequent deployments.”

5. Improve management of what can’t be automated

If a security test can be automated, it should be automated. If you can’t automate it in-house, then you should strongly consider outsourcing if it can be done cost-effectively (less expensive for you than doing it manually in-house). If something can’t be automated as it is, consider redesigning or reforming a process so that it can. If all of that fails, manage what must be done manually as effectively as possible.

In his post, MacVittie advises enterprises to rank their remaining manual processes and then base work assignments on the severity of those rankings. “We do this stuff with risk management and threat assessment; this is no different, except you have to be willing to drop low-priority things—not to let them slide because you never get to them, but to publicly say, ‘This is a risk we are willing to take.’ Let the team know that they’re not the only ones adapting,” he writes — and he’s right.

This list isn’t all-encompassing when it comes to getting to DevSecOps, but it’s certainly a great way to start thinking if you’re not quite there.

 

RELATED LINKS

Survey: Formal education leaves software developers short on security

Cloud-based security services set to soar

Business leaders still disconnected from cyber risks

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: