Translating “Rugged DevOps” into practical use


I was thrilled to see DevOps and security intersect at RSA’s 2nd Annual Rugged DevOps Conference. It was great to see the growing intrigue and the varying “best-practices” for the ideal implementation of DevOps as more than 600 attendees from varying backgrounds packed the room. It was enlightening to hear about the various functions that should play a role in rapidly delivering applications and services to both internal and external users. Taking a step back, this “still-evolving” concept has even the most mature organizations putting pressure on themselves to get DevOps right the first time. Perhaps that’s why most companies are still experimenting with containers and the presenters placing significant emphasis on a distinct culture or role, termed, “DevSecOps”.

Here are some of my takeaways. DevOps and security go hand-in-hand and must collaborate to deliver against business and customer objectives. Kim Zetter gave us a great roundup of the notable hacks from 2015, ranging from a teenager hacking the CIA Director’s emails, the OPM hack, and the Ashley Madison case. You’d think companies would have processes in place to ensure the least amount of security vulnerabilities, but as technology pushes innovation to its limits, it also creates room for that same innovation to be tested.

There is no prescribed path for DevOps success. The list of panelists who moderated the “DevOps Engagement: Politics, People and Process” shared interesting insights as many of their customers raised similar concerns to what we hear from our own customer-base. How do they begin such a long journey? How long is the journey? Where does the buy-in come from? At ElasticBox, we notice that the companies with the most successful DevOps initiatives are the ones that take a “rugged” approach. Having security folks inject their input early on in the process tackles a large amount of the fear and vulnerabilities that comes with the journey.

An exec champion is a must, and the team buy-in is also critical. As you’d imagine, having a senior executive or leadership sponsor as a champion is an absolute must, but more than that, having a buy-in from all levels of the organization is just as critical. When it comes to DevOps, we notice lots of different objectives and goals across the board. Development teams may see the value around accelerating application deployments, while IT may see the true value around creating a self-service catalog that falls within their policies. CIOs may see the value in reducing failed builds while leveraging multiple clouds.

Win the day. Find short, quick wins. With varying perspectives on the underlying value of DevOps, it’s easy to get lost in the numerous ways companies can get started – think, short, quick wins. We’ve seen that instead of trying to change large enterprises, finding a single application within a specific team yields the best result.

Security must be considered as part of the a DevOps initiative. As business demand for DevOps and public cloud services increase, we constantly hear how this new agile approach creates conflict with security practices and processes that already in place. For example, you’ve created a vehicle that’s as fast as a sports car and resourceful as an electric car, however, it does not pass the safety tests. To successfully have this car in production, making sure the airbags are a listed as a requirement in the beginning will have a higher chance at avoiding going back to the drawing board to re-engineer the entire car. Simply put, taking a Rugged DevOps approach would mean making sure that the airbags we’ve tested and trusted for so many years are still a necessary component in the final ride.

I think Shannon Lietz summed up the state of DevSecOps, “DevOps tend to push code several times a day, hackers tend to find issues several times a day, and security professionals tend not to make very many security decisions, and especially only when asked… it means that right now the security for your organization is being decided by somebody who doesn’t necessarily know what’s happening or what’s going on in your environment.”

Hacker News

Categories: Uncategorized