Designing Least Privilege Into Modern Infrastructure


October 7, 2014 | DevOps | Kevin O'Brien


The last week has been a doozy for security breach followers.

Since the beginning of the month, two high-profile data breaches have been announced: JPMorgan and Yahoo have both announced that their systems were compromised, the former as a result of a systematic escalation of privileges attack (née APT, or advanced persistent threat), and the latter fallout from the ShellShock breach.

What we can see and learn from both is that the areas where security fails is continuing to break along the traditional lines of visibility, least privilege, and trust. In the case of JPM, there was likely an accrual of security debt from years of application acquisition, point-in-time decisions about who and what could use those software packages, and a lack of comprehensive visibility and control over that wide range of software, services, and the permissions that applied to each. Designing least privilege into modern infrastructure is likely the only thing that could have helped prevent these breaches, and over time we hope to see this become standard practice.

10_07_14As Ericka Chickowski over at Dark Reading points out, “investigations found that the attackers made their way deep into internal systems, gaining full administrative privileges on more than 90 servers.” In many ways, this reflects the same risk vector we at Conjur often repeat, originally made by Gus Hunt (former director of security at the CIA): you are only as strong as your weakest link.

In this sense, both Yahoo and JPM reveal not only that security is a wide-ranging problem that needs to be addressed across the entire technology stack, but also that we need to define and enforce new best practices as infrastructure is rebuilt and modernized. With respect to the big security vendors, there probably isn’t a commercial solution that would have prevented the kind of breach that JPM experienced — the scope was likely too broad, and the threat surface too wide to manage post-hoc.

The real solution is in solving for security from the ground up. The natural inflection point for this is when new infrastructure is being built: servers moved into AWS or Rackspace or Azure, automation tools like Jenkins (and Puppet, and Chef) spun up, and new virtualization and containerization platforms such as VMWare and Docker engaged. While there are no guarantees in the security arena, there is truth in the idea that good practices beget good practices. If you’re embarking on DevOps and cloud, take the time now to create a robust security stance and ensure that it doesn’t fall prey to the kinds of systemic weaknesses that most organizations have inherited from previous generations of technology and system design.

Keep an eye on this space over the coming months, as we’ll be describing some of these best practices in more detail, and helping design and architect security into Jenkins, Puppet, SaltStack, Docker, VMWare, and more.




Share This