Security Weekly Panel Discussion on DevOps

Security Weekly, recognized by their “Hack Naked” branding and weekly podcasts that thousands of people consume on many different aspects of Information/Cyber Security, is often a great resource for understanding problems. Are you looking for a new way to navigate a process like Agile? Need to understand how something works? Security Weekly touts itself “the security podcast network for the security community,” and it is. I have worked with several of the hosts and spent years in the community we all enjoy, it was great when Matt Alderman reached out with an invite.

I was lucky enough to be invited to the Security Weekly Holiday Extravaganza webcast, an event that would allow me to engage in some entertaining discussions with fellow security practitioners. Contrary to popular belief, security practitioners are not social misfits; indeed, they tend to be both animated about their domain as well as passionate about discussing their interests. I was looking forward to having some fun and learning a few things – a feeling confirmed on my connecting flight where I met a guy in a SECKC shirt and another guy in a Hackers for Charity shirt. Bill and Trent, I hope you found the seafood you were looking for!

Entering the Security Weekly studio, I was surrounded by a warm blanket made up of holiday spirit, cigar smoke, whiskey vapors accented by sound and video production equipment for the webcast. As the Security Weekly hosts made sure we were comfortable, it dawned on me that the culture of information security is one of sharing, learning and sometimes commiserating but always having fun when the work is done. If you were to ask me about the Culture of Security, I would describe it using words like sharing and learning.

Moving to the other reason I was attending the Security Weekly event – a panel discussion on DevOps with a group of AppSec pros, many of whom have created tools or programs directed at Application Security. As the discussion progressed the point was made that if you ask someone to describe DevOps in their context, they would probably start talking about tools and automation of tools workflows. Culturally DevOps is “we use these tools” and the most successful practitioners tend to speak about their environments not as a bunch of tools but rather a collection of goals and the teams that achieve them.

As organization scale their DevOps initiatives, it is often driven by their desire to achieve more rapid and efficient development and product release practices. The problem is the culture of most organizations isn’t one where failure is embraced as learning, where teams work together efficiently and feel they can contribute to another’s success. When organizations fail to achieve the desired efficiencies of DevOps, the most common reason is a lack of widespread support for the organized chaos that DevOps introduces.

Taking lessons from those that are achieving the greatest success, DevOps initiatives need to support the following requirements:

1. A failure safe environment. This means you can fail fast, possibly often, but and use it to learn.
2. A collaborative team-based culture. Everyone doesn’t have to get along, everyone needs to be willing to make someone else successful. If you are willing to adjust your code to a more stable platform, that is makes someone else successful. You were part of the team that increased stability.
3. Designate a team lead, or owner of a pillar: Development, Operations, Security, etc… They are the ones pushing for the next iteration.
4. Clearly articulate and agree on the reasons behind the move to DevOps (or other iterative development methodology). Unrealistic expectations are rarely met with any methodology so expecting 1,000 developers to suddenly work well with an operations team they’ve never met isn’t going to yield 7 more releases per year.

Obviously, this isn’t an inclusive list, this just leans on what a cultural shift will need to be made. Here at Cequence we just wrapped up an internal hackathon. We stopped work for a couple of days and pulled the development, engineering and ops teams together where we first discussed our product roadmap and associated goals for the next several months and saw partner presentations. Then the real fun began. We had a two day hackathon where we divided into small teams, each with varied skills and experience. Each team then choose from a long list of ideas/projects what they would work on for the next two days. The teams were given free rein to do what they needed, and the results were astounding. Most all of what the 8 or so teams did is product worthy. Even more valuable was the energy and excitement the team showed. They were disconnected from the everyday responsibilities, working with folks they may not interact with regularly. Rest assured, the next hackathon is already being planned.

If you are thinking about doing DevOps, a hackathon is a great way to see how it will work. Start on a small scale by picking a team that would be open to making the event successful, then expand from there. I think you’ll be amazed how creative and quick a team can be if they are uncoupled from the constraints of normalcy.

DevOps isn’t about a tool chain, DevOps is the Olympic Bobsled team. Everyone knows their inputs, no matter the size, are important and ultimately drive toward efficiency. The people at the heart of moving you toward DevOps is the focus, they’ll figure out how to make themselves efficient. DevOps is a culture that indicates teamwork, efficiency, and a goal of success.

Check out the panel discussion recording.