DevOpsDays Chicago 2016: Dev, Ops, & the Role of Security

Last week I spent two great days at DevOpsDays Chicago. Usually, I attend conferences to listen to the talks, but in Chicago I was representing Threat Stack (one of the event’s Gold Sponsors), so my job was mostly listening to engineers discuss their organization’s security stance and requirements. I learned a lot from the conference — especially about the integration of Security into a DevOps world.

Operations Knows They Are Important to Security

First, an observation from DevOps Days Chicago. Before lunch on Day 1, I gave our vendor talk, starting with the elevator pitch I normally use: “Threat Stack is a continuous cloud security monitoring and alerting SaaS platform that’s focused on providing value through security, compliance, and operational efficiency.”

But when I got to that point I pivoted and asked the audience to participate:

“Who here is in InfoSec? Raise your hands.” 

Three or four hands went up out of close to 200 people.

“How many of you are responsible for security in some way? Maybe you have no security team. Or you have a shared responsibility model.” 

At least two thirds of the room had their hands up. I’m hoping a lot of folks simply weren’t paying attention to me because it seems like the number should have been higher.

What I’ve come to realize based on conference talk lineups and vendor sponsors — not just at DevOpsDays Chicago, but at other Ops and infrastructure-oriented conferences as well — is the fact that an entire area of responsibility is being neglected.

Sure we know Security is important, but why aren’t we addressing it directly in conference presentations? I see countless talks on automation, metrics, team communication, exciting technology X, and “What is DevOps?”, but rarely do I come across talks that center directly on Security. (Bucking that trend, of course, was The Road to DevSecOps, the keynote that Dan Glass delivered at DevOpsDays Austin in 2016.)

Based on the number of hands that went up and the conversations I engaged in afterwards, there is clearly a real need and desire for more teaching and understanding about Security in the Ops community. 

Breaking Down the Security Silo

The Ops community clearly wants greater security competence, but there is a real gap between the Ops and Security cultures. DevOps has helped break down the silos that separate Ops and Development, but the same cannot be said of the wall between Ops and Security. Overwhelmingly, I heard the following comment: “Your product looks great and would be really useful.” But mingled with it, I also heard the following two concerns from time to time:

  1. I love your product, but if we had it, Security would end up telling us how to do our jobs.
  2. I love your product, but Security makes the decisions about the tools we use.

Neither of these comments is technical in nature, and they don’t reflect negatively on our product or anyone else’s. Rather, they are human and/or organizational: as such, both can and should be addressed.

The first concern stems from an all too common misalignment of Ops and Security goals. Deeper investigation typically shows that both Ops and Security teams actually want to work toward the same outcomes, and neither really wants to meddle in the other’s affairs. While the alignment of goals can require a new way to collaborate along with the revision of some organizational lines, collaboration and alignment on common goals is the “right thing” to do. In the case of Threat Stack, we have built a security solution for Ops, Dev, and Security, and it actually helps disparate groups to align processes and objectives.

The second concern — that Security will interfere with or dictate to Ops — shows another facet of the disconnect between the Security and Ops teams. One engineer I spoke to was very excited about the possibility of using Threat Stack. However, he needs to obtain buy-in from a team that dictates requirements and tools but doesn’t have to do the work. (He mentioned that the tools he currently uses aren’t user friendly and don’t make as much sense to him — not being a security engineer.) This is an issue that stems from one group determining requirements or procedures without fully consulting the other. This probably sounds familiar to an operations engineer, and it should remind us of the bad old days when we imposed process requirements on developers to make our lives easier instead of theirs. As with the first objection, the disconnect between Ops and Security can and should be resolved through a joint effort to determine requirements, understand roles and responsibilities, and align objectives.

Chicago and Their Pizza

It’s different, and Giordano’s is better than Lou Malnati’s.

A Final Word or Two . . .

Being on the other side of a vendor booth was a new and valuable experience for me. And I’ve got to tell you, it’s given me a whole new respect for our Sales and Marketing Team and all the amazing work they do at these events.

I spent most of my time talking with other engineers, listening to their requirements, learning about their pain points, discussing the problems we solve at Threat Stack, and demo-ing our product. I believe I passed on a lot of valuable information — especially about the role that Security can play in a DevOps environment — and I definitely came away with important insights that I intend to share with my colleagues.

Overall, DevOpsDays Chicago was a fantastic event, and I can’t wait to go back next year — armed with a Security-related talk to share with all the eager conference attendees.