BLOG POST

On the Future of IT, Part III: Securing DevOps Infrastructure

 

October 22, 2014 | DevOps | Kevin O'Brien

 

Securing Modern Infrastructure

In the first two parts of this series, we’ve looked at the ideas that significant organizational change improves companies, and that the growing DevOps movement is an example of change in how infrastructure, development, and operations are blending together.

Today, in the third and final part of this series, I want to explore the security implications of this change, and offer some best practices and ideas for addressing them.

Over the course of my career in security, I’ve learned a few ground rules for designing an effective security program:

  • Strategically, security (and by extension, incident response) has three components: prevention, detection, and response. Tactically, each of these involves some mix people, process, and technology.
  • For prevention and detection, minimize the “people” component and maximize “process and technology”. Standardization and specialization are force multipliers. (For response, technology isn’t yet — and perhaps will never be — capable of replacing people.)
  • As a corollary, the more you invest on defining, supporting, standardizing, and automating prevention and detection, the less difficult response will be.
  • In a crisis, when time is of the essence, difficulty equates to cost. (Think of the iron triangle: if you don’t have time, and you need quality, you’re going to pay for it.)
  • Resist the temptation to “do it yourself” when it comes to process and technology. In almost every circumstance, you’re reducing standardization, adding complexity, and reinventing the wheel. Any money saved by doing it in-house will be significantly offset when a crisis emerges.

Making Friends, Influencing DevOps

With these ideas in mind, what will a good security program for a DevOps culture look like?

Fundamentally, it will be aligned with the same business-enabling values that DevOps itself brings: automation, continuous integration (or in this case, continuous monitoring), and avoidance of one-off solutions in favor of systematic good decision making and security.

10_22_14

What this will look like from a market perspective, from an infrastructure perspective, is a replacement for outdated methodologies of implementing identity, permissions, and secrets/key storage. Why these? Because they represent the areas where (1) infrastructure access is both defined (permissions) and controlled (secrets/keys), (2) they are the functional areas where moving to a more robust design (RBAC vs. hierarchical groups, for example) will improve the prevent and detection phases of the security model, and (3) these updates are ripe for standardization from vendor-developed software.

Putting it in Practice

Obviously, we have a bias for implementing this “automation of security for DevOps” idea, but putting that aside for a moment, let’s consider what it means to adopt any kind of security model here.

Security, traditionally, has been looked at through a lens of blocking business initiatives. At best, it’s a hot potato; nobody wants to be the one to be pointed at if something goes awry and data is lost, and it’s typically seen as a distraction by non-security professionals.

The difference in implementing the model from a DevOps perspective, however, is that we’re looking at embedding permissions and key management into the infrastructure from the ground up. What that means is that prevention and detection are intrinsic to, say, the rollout of Puppet, or VMWare, or whatever other tools might come into your infrastructure in the future. Instead of hand-cranking secrets storage, you’ll have a purpose-built and well defended secrets repository, along with a role-based access control model that determines who, what, where, when, and how those secrets should be accessed.

The value to a DevOps team is that by handling security in this way, they can focus on the more interesting problems (“how can we automate our build processes more effectively? What can we do to reduce our work-in-progress queue and release more quickly?”, and so on) than “how do we keep our audit guys from bugging us?”

In the same way that security melded with IT when users changed the model for application and device selection, we believe that it needs to do the same for DevOps, both because it’s good practice (per the “ground rules” above) as well as an essential part of building and securing DevOps infrastructure moving forwards.

 

 

Share This