You are here

Josh Corman on security and DevOps: How shared team values can reduce threats

public://pictures/Marcel-Santilli-chief-content-officer-TechBeacon.jpeg
Marcel Santilli, Former Editor, TechBeacon

With line-of-business managers pressuring development teams to release applications as quickly as possible, it's hard to convince developers to spend their limited cycles patching security holes. Yet, 84 percent of all cyberattacks happen on the application layer, so organizations can't afford for their dev teams not to include security.

The rise of DevOps presents "a threat to security," says noted security strategist Josh Corman, CTO at Sonatype, "and it's an opportunity for security to get better." Corman is a staunch advocate of integrating security and DevOps practices to create "rugged DevOps." He believes that security and DevOps share basic values, and that the practices are mutually beneficial.

This article is based on an interview done with Corman in October.

[ Learn how value stream mapping can improve your DevOps workflow. Download this GigaOm Research Byte report today. ]

Instrumentation and testing: Core values

"A primary example is the tendency for DevOps teams to instrument everything that can be measured," says Corman. "Security is always looking for more intelligence and telemetry. You can take a lot of what DevOps teams are measuring and enter that info into your log management or your SIEM [security information and event management system]. An OODA loop [observe, orient, decide, act] is predicated on having enough pervasive eyes and ears to notice whispers and echoes. DevOps gives you pervasive instrumentation."

And Corman notes that there are other shared cultural attitudes as well. For example, the "be mean to your code" concept. "The software tool Chaos Monkey written by Netflix was a watershed moment for DevOps teams. Created to test the resiliency and recoverability of Amazon Web Services, Chaos Monkey made the Netflix teams stronger and more prepared for outages," says Corman.

"So there's now this notion that our systems need to be tested and, as such, James Wickett and I and others decided to make an evil, weaponized Chaos Monkey, which is where the GAUNTLT project came from. It's basically a barrage of security tests that can be used within DevOps cycle times and by DevOps tool chains. It's also very DevOps-friendly with APIs."

[ Learn what separates successful DevOps initiatives from unsuccessful ones in this new August 27 EMA research webinar. ]

Complexity as a common root problem

Corman feels that both security and development teams believe complexity is the enemy of all things. For example, "Security people and rugged DevOps folks can actually say, 'Look, we're using 11 logging frameworks in our project—maybe we don't need that many, and maybe that attack surface and complexity could hurt us, or hurt the quality or availability of the product.'

"Complexity tends to be the enemy of lots of things. Typically you don't have a hard time convincing DevOps teams to use better building materials in architectural levels: Use the most recent, least vulnerable versions, and use fewer of them."

How better building materials matter

"I'm the custodian of the largest open source repository in the world, so I see who's using which versions, which vulnerabilities are in them, when they don't take a fix for a vulnerability, and for how long. Certain logging frameworks, for example, fix none of their bugs, ever. Some of them fix most of their security bugs within 90 days."

Corman points out that people are getting breached repeatedly, simply because they're using a framework with no security capacity. "Having 11 different frameworks makes for a very clunky, buggy deliverable, with lots of extra work and complexity. Your exposure to vulnerabilities is much greater. How much development time do you want to spend fixing lots of little defects, as opposed to creating the next big disruptive thing?"

Corman believes that a key to rugged DevOps is software supply chain management, which incorporates three principles: "Use fewer and better suppliers; use the highest-quality parts from those suppliers; and track which parts went where, so that you can have a prompt and agile response when something goes wrong."

DevOps tools as a change management database

Corman describes the area of change management as another shared value. "What I've found is that when a company wants to perform security tests such as anomaly detection or net-flow analysis, they need to know what "normal" looks like. A lot of the basic things that trip people up have to do with inventory and patch management.

"I saw in the Verizon Data Breach Investigations Report that 97 percent of last year's successfully exploited vulnerabilities tracked to just ten CVEs [common vulnerabilities and exposures], and of those ten, eight have been fixed for over a decade. So, shame on us for talking about advanced espionage. We're not doing basic patching. Now, I'm not saying that if you fix those ten CVEs, you'll have no successful exploits, but they account for the lion's share of how people are actually failing.

"The nice thing about DevOps automation tools is that they've become an accidental change management database. It's a single version of the truth of who pushed which change where, and when. That's a huge win, because often the factors that have the greatest impact on security are out of your control. You inherit the downstream consequences of the choices made by the CIO and the CTO. As IT becomes more rigorous and repeatable through automation, you lessen the chance for human error and allow more traceability on which change happened where."

A shared sense of empathy

While DevOps involves processes and tool chains, Corman believes that the defining attribute is culture, and he specifically points to empathy as a cultural value. "DevOps works because dev and ops teams understand each other better and can make more informed decisions. Rather than solving problems in silos, they're solving for the stream of activity and the goal. If you show DevOps teams how security can make them better, then as a reciprocation they tend to ask, 'Well, are there any choices we make that would make your life easier?' Because often they don't know that the choice they've made to do X, Y, or Z made it impossible to include security.

"For security teams, one of the ways to drive value is to be helpful before we ask for help, and provide qualitative and quantitative value before we tell DevOps teams what to do. You've got to earn the trust of DevOps teams and earn the right to play, and then it will be reciprocated. It often happens a lot faster than you think."

See the original interview with Josh Corman, as well as the video "Who let security into DevOps?"

[ Webinar: Paving the Last Mile to Production: Putting the "O" in DevOps ]