4 Steps to Integrate DevOps Workflows With Cloud Security Practices

By Pete Cheslock Senior Director, Ops and Support at Threat Stack

Introductions

Pete CheslockSenior Director, Ops and Support

As the head of Threat Stack’s operations and support teams, Pete is focused on delivering the highest level of service, reliability, and customer satisfaction to Threat Stack’s growing user base. An industry veteran with over 15 years’ experience in DevOps, Pete understands the challenges and issues faced by security, development and operations professionals everyday and how Threat Stack can help.

You can find Pete on Twitter @PeteCheslock.

One of the biggest themes I’ve observed throughout my career is:

Companies value speed over security.

…yet this approach has traditionally been a blocker in delivering software.

Recently, however, with more and more breaches and vulnerabilities reported (i.e. Shellshock and Heartbleed), it’s important now more than ever that security gets integrated INTO the operations process.

Here are the 4 Ways to Balance DevOps

Workflows With Pragmatic Security:

1. Recognize that tools enabling DevOps also introduce new threats and attack surfaces!

• Vagrant • Packer • Docker • Chef • Puppet • Salt • Ansible • etc., etc.

Many apps have entered the modern-day Ops toolbelt:

The problem that many of these tools solve is the ability for engineers to:

• Manage more systems • With more control • And consistency

…than ever before!

With Ops Engineers now representing their infrastructure as code, they can deploy changes with much higher velocity and much less risk than ever before.

And since their infrastructure is now represented in source control, they can use software engineering methodologies to test their code, and can do so much earlier in the Dev process.

With Docker and OSv, and the maturity around orchestrating containers and processes with tools like Kubernetes, Mesos and others…

Ops Engineers can maintain a platform that enables Software Engineers to ship changes quickly and effectively.

The wall that existed between Engineering and Operations is now broken down!

Both sides are embracing change and pushing updates frequently.

However, we’re now faced with a new wall.

It exists between Security and the rest of the technical organization.

Fortunately, there are collaborative ways to overcome this wall…

2. Mitigate risk while still moving fast

This is the classic “DevOps” conversation all over again…

Developers want frequent change and/or are being pushed forward for change by the Product team…

…yet Operations teams want stability and changes to their system could introduce instability.

Now, both Dev and Ops teams are enabling each other to ship effectively using many of these new tools to assist them.

Unfortunately, Security teams have been left behind…

The ideal state is:

Security teams using and creating new tools that enable them to insert security and risk control in the same pipelines that Engineering and Operations are using to deploy their changes.

(FYI: This is a BIG problem I’m excited Threat Stack is solving

for Dev, Ops and Security teams)

For example…

If Ops teams use Chef to continually update their systems at scale, Security teams should be writing cookbooks that setup and enforce security policies.

Or…

If Engineering is using Jenkins to continuously integrate their code, Security teams should add additional tooling into the build pipeline to monitor for risk and threats.

3. Let developers and others have safe access to production

A practice I’ve seen work well is to put the engineers on call for the specific

applications they own.

For example…

The Web team has a pager rotation and gets alerts when there are issues with the web servers.

The Search team gets alerts when search clusters are OOMing.

But this can present a frightening reality to Security teams who now have to deal with both frequent changes to the code AND an endless group of people who have access to systems.

Trust but Verify I’ve taken this approach when it comes to access control and

have implemented tools including:

• auditd • OSSEC • centralized logging

This helps ensure compliance, BUT:

• These tools are cumbersome to setup and configure. • You don’t want them to come in the way of progress OR

performance.

This is why carefully increasing ownership works well among teams.

4. Build a system that will allow you to regularly push to production with security checks in place

The same CI tools (i.e. Jenkins) that Engineering has been using to continuously integrate their feature branches are the same tools Operations can use to manage and deploy code (whether or not this is the ideal solution).

Security teams should work to integrate security tooling direction into the automation pipelines to allow for quick feedback loops that Engineering and Operations have become used to.

Building in automation

+ Taking advantage of virtualized

cloud infrastructure +

A workflow that empowers developers to push code continuously

= Companies can move fast when deploying and

managing apps with less overhead.

In a wrap…

As DevOps has evolved into a mainstream philosophy, we’ve heard more DevOps conversations on security-related topics than ever before.

This process is the next logical step.

That means it’s more important than ever that there is a unified understanding of the ways to balance new DevOps workflows with evolving cloud security practices.

To see how we’re enabling teams to integrate these workflows:

Sign up: http://threatstack.com/signup

Stay in touch: @ThreatStack