Devops + Secops Part 2: Containerization & Involving Security Ops to Reduce

2Dec

Devops + Secops Part 2: Containerization & Involving Security Ops to Reduce

Let’s dig a little deeper into Devops’ untapped security potential. One of the big concepts in Devops is containerization—the segmentation of information or applications. And it’s here that involving your security ops is a game-changer.

Containers

A container is a completely self-contained operating systems and software stack that runs a service that can either stand alone or function as part of a larger system. It can be rebuilt from a script, copied, or changed incrementally—all through automations. Docker’s analogy is the shipping container: they can be moved from facility to truck to boat to truck to anywhere. But I like the analogy of a cell: a functioning unit with a defining relationship to larger organism.

Containerization does wonders for efficiency, but it can also be used effectively to enhance your security posture. Implementing containerization in your Devops strategy will allow you to replace procedures that open you up to risk.

  1. No more patching. Patching production systems is painful. But by building a new container with the latest patches, you can be confident everything is secure and up to date. And moving to and from production is and made much more effective.
  2. No one needs root access in production. No more blanket access for developers and IT staff working in production. Containerization allows you to let your team get to work with the appropriate level of access.

There’s no trick to this. This is simply practicing good Devops strategy, then integrating the security team at strategic points.

Involving SecOps

Since Devops drives efficiency by consolidating efforts (of development and IT ops), it shouldn’t surprise anyone that there’s room for more at the party. In practice, bringing SecOps into building container images and configuration helps to tie even more of your vital efforts into this streamlined process. I mean, why leave security in the dark? Why throw them late into a finished or nearly finished project?

Currently, your Devops strategy with Docker probably looks something like this: DevOps Blog 09.001

But by adding the SecOps team to your workflow, you can include SEIM configuration and critical system protection into your build automation process. Secops can use the same tools as the SysOps to modify the base image of a server. This way, their security settings get run through QA and prod workflow, and there is no manual intervention. Any new app built automatically gets those hardened security settings.

This minor change to the process looks like this: DevOps Blog 09.002

And that easily, you can strengthen your security & efficient workflow.

Read more devops + secops:

Part 1: How Devops Can Improve Your Security Strategy Part 3: Continuous Security In Action