The Case for Continuous Security

This was originally posted on the Threat Stack blog - added here for continuity.

DevOps is a term that has absolutely blown up in the last 5 years. As someone who’s been involved with that community from the earlier days, it’s been interesting to watch the conversations around DevOps evolve over time. For many people, they had an immediate adverse reaction towards Yet Another Buzzword – especially when the core concepts that people described as being “DevOps” were things that many people had already been doing for years. (I’m not going to bother getting into the specifics of “what is DevOps” since there is already a plethora of blog posts that you can easily find on it.)

One of the core tenets of what people consider to be “DevOps” is to shorten the feedback loop in your development cycles. By reducing the amount of time for those feedback loops, your teams can iterate more quickly on changes and ship those features to your customers sooner. This tenet ties in directly with Agile methodologies utilized by software engineering teams. With the advent of easily accessible cloud infrastructure, and with the various operational tooling around those new infrastructure providers reaching a new level of maturity, we are now seeing a world where “DevOps” is mainstream. For companies starting new product development initiatives, using some form of Configuration Management is now table stakes to iterate quickly. Additionally, we see more and more companies shed their physical data center presence in order to leverage the flexibility and accessibility of public compute resources provided by companies like Amazon, Microsoft and Google.

The inherent nature of these IaaS providers is to make it as easy as possible to provision systems to meet your infrastructure needs – and to do so very quickly. Speed to market is a major competitive advantage that many companies are leveraging through the concept of Infrastructure as Code. Provisioning hundreds or thousands of compute instances in mere minutes is now considered an everyday activity. Everyone wants to move fast.

Continuous Integration. Continuous Deployment. But who (or what) is continually monitoring the state of your operational security?

To make error is human. To propagate error to all server in automatic way is #devops.

— DevOps Borat (@DEVOPS_BORAT) February 26, 2011

We now have a world where your junior system administrator is able to make a small change to a Chef Recipe, Puppet Manifest, or maybe an Ansible Playbook, and deploy it to production within minutes. But what is the scope of that change? System Administrators don’t want to be slowed down by the security team. They don’t want their configuration management changes to be passed through a Change Control Board. They want to change a variable, open a pull request, and once merged, they want their operational tooling to do the rest. They want their change to hit production servers as soon as possible.

If one of the primary tenets of DevOps seeks to value empathy between teams that traditionally had different incentives for their positions (Devs valuing constant change, Ops valuing stability), We need to evoke the same outcome with your Security teams and the rest of the business.

When you are in a world where you are continually deploying change, you need to move towards a world where you are continually monitoring the security implications for those operational changes. Often times, there is no single person at your company that is able to say with absolute certainty which changes to your infrastructure have additional risks towards your security posture. And if you have a traditional network security organization that is manually reviewing and approving changes to production, you’ve now introduced the newest bottleneck in your organization.

It’s this conversation that excites me the most about joining Threat Stack. As a technical operations veteran of the last 15 years, this is the most important (and exciting) problem to solve in many organizations. Having the opportunity to help build a product that will enable companies to continue to break down operational silos while improving the speed in which they are able to track and respond to security incidents is an absolute dream job for me.

How do you improve your security monitoring and response times, while maintaining your ability to continually deploy changes? These are hard problems to solve, and we are all excited to be in this unique position where can actively help companies solve this problem.