The year 2015 is off to a running start, with DeveloperWeek around the corner and an exciting lineup of tech meetups to follow. But before looking forward to the next big meeting, I think it’s important to reflect on one of my most valuable experiences of 2014.
As someone who has attended AWS re:Invent in Las Vegas for each of its three years, it was amazing to see just how quickly the conference (and the cloud) is growing. In the midst of information aplenty, I was reminded that my favorite part of the conference is the people. One of the highlights for me was hearing George Miranda of Chef speak.
Miranda described DevOps as a practitioner-led movement, not a tool. He also called it a way of interacting with an environment. While Ops and Dev were once separate, the silos are beginning to break down and the lines are blurring, a trend that indicates the new needs of organizations.
Chef is the declarative model for system configuration, turning infrastructure into code. Miranda noted that in this model, having an auditable trail of action is no longer a burdensome afterthought. Instead, we are suddenly (and ironically) working in the ways that security and risk management have wanted us to work for years.
Tools like Chef and Puppet are taking the place of manual configuration models: you can identify a target state and let the tools go to work.
Yet declarative models as a trend in the industry are only just beginning to take root.
Security gets its own declarative model
As people are starting to understand what declarative models really mean for system configuration, we are only scratching the service of what they can mean for security. In fact, IT security today is in danger of being marginalized—a truly scary statement when we see breach after breach of critical data centers reported in the news.
IT security today is in danger of being marginalized.
The problem emerges in the gap between developing security policies in the language of the business and the manual implementation of those policies. We are challenged by the growing mismatch between the needs of a dynamic data center and the reality of today’s static, slow, and error-prone implementation process.
We need a new way of thinking about security. One that keeps up with change and satisfies the DevSecOps community.
We need Security As Code.
What does Security As Code mean in practice?
As a security community, we need to seek out and develop security tools with the following properties:
- The language of the business. There are different languages for programming computer systems such as C, Java, .NET, Ruby and Erlang. Each of those languages has an ideal place in the ecosystem, and you need to pick the correct language tool to solve effectively and efficiently. While you might start with Erlang over C when building a fault-tolerant distributed system, in thinking of Security as Code, you should not need to start with a solution that requires you, as the security professional, to understand the minutia of each implementation detail. Instead, we require better abstractions that allow security practitioners to use the language they need (e.g., PCI Environment, High Value Asset, Development Stage) to describe the entities in the system and the relationships between them.
- The ability to behave like a time machine. Security thinking is not something that just worries about the “now,” it also needs a rich understanding of the past. Knowing who did what, and when, is core to understanding, addressing, and resolving actual and potential breaches. Security As Code means having a time machine. It’s a bit like GitHub for your security intelligence. It means you are always presenting data with a time dimension. You can pick a point in the past to understand what the state of your systems was, what changes were going on, and who was making those changes. And you can also look into the future by performing “what if?” scenarios for proposed changes.
- Intelligent systems that respond in real time. Security As Code means the system can be dynamic and told ahead of time how to correctly respond to changes in the environment. This eliminates the need for a human to be involved with every aspect and detail. Security As Code means adopting a declarative model for describing the security policy, rather than an imperative one. This means that security teams can specify the goals and properties of the ideal state, AND have an intelligent system that can apply new algorithms to “figure out how to do it.” These algorithms are fed by constant input, understand the environment details and state, and continuously compute the topology and instructions necessary to precisely and accurately fulfill and implement those goals.
With software empowered with the right language and model, and backed by algorithms that power the security engine, humans don’t have to be bogged down by all the minutia of implementation. This allows security professionals to focus on the goals of the business, change policy to adapt to new builds needs, and respond to changes in the infrastructure. And they can do all of this with the necessary understanding of what has happened and what is happening, with confidence in what will happen when change occurs.
By embracing these principles and working toward closing the gap between the old and the new, we can build security systems that can better protect us because they’re more accurate, simpler to reason about and understand, more dynamic, and more agile.