Rugged DevOps at RSA: 6 takeaways for security, ops teams
More than 850 security and DevOps practitioners got together once again last week for the DevOps Connect track at the annual RSA Security Conference in San Francisco. Now in its third year, and with almost double the attendance of last year, the event puts security professionals in the same room as DevOps practitioners for a day to explore security's role in the DevOps movement, examine how to integrate software supply chains with continuous delivery pipelines, to make sense of what Rugged DevOps means in practice, and to answer that all important question: Should they call what they're doing DevSecOps? Or SecDevOps? Or maybe it's DevOpsSec?
The track featured 14 speakers from both ends of the DevOps and security spectrum who discussed everything from implementation strategies and technology/tools to how to bring it all together into a coherent culture that encompasses security, software development and operations.
For the DevOps crowd, it was a fascinating look into the state of the art in security. Security practitioners—the majority of attendees—were exposed to the current best thinking on bringing DevOps to the enterprise, an ecosystem within which many of them reside.
Here are the six biggest takeaways from this year's event.
Integrating security and DevOps requires changing the game
DevOps stalwart John Willis kicked off the event with a keynote on a topic that may not sound particularly relevant: Pareto Efficient Nash Equilibriums. But it turns out that if you work in an environment where it's hard to integrate the work your security engineers are doing with the work everyone else is doing, the problem may, in fact, be due to an effect economists have studied for years.
The relevance lies in the fact that organizations often create systems where the expected payouts are such that people are given incentives not only not to cooperate, but more perniciously: to not even consider cooperating because there's no rational reason to do so. Solving this not only requires changing the game your teams play as they ship software, but understanding that just thinking of the game as zero-sum makes it more difficult for anyone in your company, much less everyone, to win.
Your organizational challenges aren't as unique as you might think
A potentially harsh message from Jez Humble and Dr. Nicole Forsgren, both longtime DevOps researchers, was that there's ample evidence that no matter what the makeup of your organization—startup or enterprise, public or private, regulated or not—the problems you're facing in software development, delivery, and security are no different from the organizations they've researched that have successfully addressed those problems.
No matter what your constraints might be, they have a body of scientifically vetted evidence from teams and companies with similar ones who, despite them, have made huge strides in a positive direction. As Humble put it: "You are not a snowflake... at least, no more than we're all snowflakes."
Security is a big data problem
With all the hype surrounding big data, Intuit's Shannon Leitz observed that many security practices are reducible to a big data problem. As you move more infrastructure into the cloud and give engineers more direct control over the environments they create (and, in some cases, make responsible for managing), the number of compute instances and the people with direct access to infrastructure increases. That, in turn, causes the attack surface to balloon.
Answering simple questions such as, "How many instances in my infrastructure are vulnerable to this OpenSSL exploit?" or "Who, exactly, has the ability to access what?" fit the description of a big data problem, which means addressing these questions with data science can be an extremely effective security practice.
Containers are useful, but often misused
While containerization and similar isolation techniques are important, the ways in which you use container technology may inhibit security, Leitz said. As an example, many organizations ship containers with entire operating system images in them, negating the isolation benefits that containers provide. Containers, too, contribute to an increased attack surface.
Many container management platforms have tools that can address these problems, but the industry has adopted containers at such a rapid pace that developers haven't caught up with best practices yet.
The security debt tsunami is coming
Josh Corman rattled the audience with a deep-dive into the Hollywood Presbyterian ransomware case, where a hospital was forced to pay attackers to release their IT systems in order to provide medical care to patients. Simply put "A tsunami of both technical and security debt is coming to crush us," Corman said, a point he accentuated with details on recent Internet-of-Things attacks, as well as attacks on industrial infrastructure, such as dams and power plants.
The takeaway: That unseen and underrated technical debt that people talk about is going to cause real damage in the coming decade. You'll do well to start thinking of the consequences today. This growing, but often hidden risk is the precise reason why integrating security into software delivery using DevOps practices is both critically important and compelling.
Security is still about empathy
After providing a reality check for the audience, Corman also noted that one of the core tenets of the DevOps community—empathy—is often in short supply when it comes to security. The conscious practice of empathy is one virus he hopes will infect security communities. The way that healthy organizations practicing DevOps have fostered empathy between development and operations teams that had been at each others' throats is a model for the security community.
At the end of the day, it was clearer than ever that security is another critical component of any organization's successful DevOps practice. The DevOps community is ecstatic about the force-multiplying potential of having security engineers hop on board software delivery pipelines, and the subsequent potential value for customers that brings.
As to the burning question of what the combination of security and DevOps should officially be labeled? The prevailing opinion: just keep calling it DevOps.
Image credit: Flickr