DevOps Security at Scale

Part 1: Security Policy as Code

Published December 19th, 2017 by Brian Kelly

This is the first installment in a series of blog posts on this topic.

Years have passed since the software world first gasped at the high-velocity achievements of Netflix, Etsy, Flickr, and others, watching in awe as they shipped features in less time than other companies could even begin to start planning them. The secrets to their success were collectively characterized as “DevOps” – a new approach to delivering software that focused intensely on continuous integration, continuous delivery, and breaking down barriers between engineering and operations teams in order to ship faster, and with less risk.

DevOps has now moved into the mainstream, and is found in many verticals beyond its original Silicon Valley roots. It has been adopted by banks, insurance companies, governments, and plenty of organizations in highly regulated industries. DevOps is no longer a competitive advantage. Now, DevOps is table stakes.

But even though DevOps is well understood by most modern software teams, few teams adopting it have been able to do so and also maintain sophisticated security controls. Some very well-known DevOps darlings like Uber and eBay have experienced significant breaches, along with plenty of institutions who store masses of sensitive personal information.

Put simply, many companies adopting DevOps have figured out how to streamline development and operations, but in their aggressive push for feature velocity they have left security behind.

However, there are companies who have figured out how to “run fast” with DevOps while also maintaining very high standards of information security, and there are 6 bedrock principles that emerge among them when we look at how they operate, illustrated below.

DevOps principles

 

Security Policy As Code

By far, the most important factor among teams who successfully marry DevOps velocity to security is their use of code to specify their security policies.

A cornerstone of DevOps is the concept of “infrastructure as code”, also known as “immutable infrastructure”. This is where operators declare their infrastructure needs in code, replacing the old model of manually administering and configuring servers and software by hand. This approach prevents the proliferation of “unicorn” servers that have been manually configured to such an extent that nobody knows how to recreate them if they fail. More importantly, it also enables things like automatic scaling, and creates predictability as new features roll into different test environments and into production. The code that represents this infrastructure is checked into source control just as the application code is, and therefore it can be versioned, compared, and protected.

DevOps teams with sophisticated security practices have taken the Infrastructure As Code model and use it to manage their application’s security. This means that new applications or microservices would declare their security policy requirements within code. For example, here’s a small security policy for a microservice that offers currency conversion facilities, written using Conjur’s policy language:

  - !policy
    id: currency-converter
    body:
    - &variables
      - !variable
        id: currency-database/password
        annotations:
          description: Currency values DB password

    - !group secrets-users

    - !permit
      resource: *variables
      privileges: [ read, execute ]
      role: !group secrets-users

  - !grant
    role: !group currency-converter/secrets-users
    member: !host currency-app-host

The syntax is human-readable and simple to understand: the code grants the currency-converter service the right to access the password value for the database that stores currency values. The policy is completely self-contained, always reproducible, and depends on nothing external that might change how it is interpreted in the future. It gets checked into source control, and is just as much a part of the application’s code as its internal implementation.

It cannot be overstated how transformative this is to teams who maintain high velocity in a secure environment. The security staff responsible for managing permissions of thousands of applications can use this Security Policy as Code model to scale their team’s capacity to new levels, and in a way that brings much more predictability to their work. Compare this approach with having to configure security permissions for applications by hand as they move across dev, QA, staging, and production environments, and its benefits should be quickly evident.

Security Policy as Code is critical to creating a high-performing secure DevOps process. Without it, many of the following cornerstones of secure DevOps will not be achievable at scale.

In the next post in this series, we’ll cover how using a clear separation of duties helps DevOps teams focus their efforts to further enable secure velocity.

DevOps Security at Scale series