Take a DevOps-first Approach to Security that Leverages Containers
Implementing a DevOps-first approach can drive competitiveness while creating a more secure environment
As famous cryptographer Bruce Schneier once said, “Security is a process, not a state or a product.” It is a journey and not a destination. Today, technology offers us a great set of security parameters and configuration permutations. Compliance ensures that such parameters are configured optimally to balance security and functionality. Security is about minimizing the risk, and compliance ensures that such risk minimization controls are in place. Compliance and security relate to each other, but compliance doesn’t ensure the security of a network or workload.
On a side note, too often the focus is on “security theater” (also coined by Schneier), which focuses efforts on what looks good externally, placating upper management or the auditors, but that may not have a real impact internally. One reason for this is that it is simpler to quantify and budget for compliance, easier to put on a checklist and easier to explain to the CISO than a more open-ended question such as, “Are we secure?” or, “Are you sure we’re secure?”
Security as a Continuous Process
Compliance audits ensure that the necessary controls are in place and your risk is mitigated. When proper controls are confirmed to be in place, it is much harder to break in. So, compliance provides the security assurance. But the world has changed, and a growing disconnect relates to the speed of change within the private or public cloud.
Consider a set of AWS instances scanned for PCI compliance. In a matter of hours, these could be open to attack due to new vulnerabilities or some unanticipated configuration change. By the letter of PCI, the workloads are still compliant, but they are no longer secure. We need to think about security as a continuous process, an approach that’s more proactive than reactive, and we need to evaluate how workloads are implemented.
Taking a ‘DevOps-first’ Approach
Rather than repeating the past in the cloud, or even in a new on-premises deployment that relies on creating and patching instances, a DevOps-first approach is to adopt an immutable architecture approach that leverages containers. The security of a given workload, VM or container is validated during the development cycle, and “fresh” systems are deployed to production. If any new vulnerability is discovered, rather than patch the live system, a new image is created and deployed.
The idea of immutability is that no changes are made to live systems. If there’s a problem, you just kill the old instance and deploy a new one. Toolsets constantly monitor vulnerabilities and such, and can trigger the creation of a new image/instance.
Some organizations go as far as to set an SLA for container replacement on a periodic basis, not even waiting for issues to be found. Note that this is a natural evolution of the pets and cattle analogy.
Adopting a DevOps-first approach is not as complicated as it may seem, with Docker image scanning, DevOps tools such as Chef and Ansible, and container orchestration including Kubernetes all part of the solution. In the diagram below, the developer first pulls the image from a registry, and it is immediately scanned for vulnerabilities. She commits the code, and the image is uploaded back to the appropriate registry. It is “clean.”
A container is now created from one or more images using the Docker engine, for example, but the important step here is that the container is also ‘hardened’ against any OS vulnerabilities. These are the same types of benchmarks and frameworks applied to on-premises and VM workloads, now applied to containers. A verified good container workload is now pushed to production. Along all of this, an orchestration layer such as Kubernetes is also hardened against threats.
Concept from https://thenewstack.io/assessing-the-state-current-container-security/
But Is It for Me?
The approach above, relating to DevOps and containers, is sometimes associated with organizations that have large IT staffs and develop their own applications—the Fortune 1000. But this isn’t the case. Within the United States alone, 200,000 midsize enterprises, defined by those with revenue between $10 million and $1 billion annually, face the same challenges.
They have on-premises workloads, are migrating applications to the cloud and are evaluating containers. They are building internally a better awareness of how compliance and security impact their businesses, and wish to implement business processes that mimic the efficiencies of their larger peers. And, they span every vertical. Separately, midsize SaaS companies (and even the largest started off small at some point) have adopted a DevOps culture from the get-go.
Implementing a DevOps-first approach to their workloads can drive additional competitiveness and create a more secure environment. With the tools and automation available, the midmarket should be among the most eager to evolve based on more limited budgets and expertise.
Compliance doesn’t imply security, but with new DevOps approaches, the two domains can become closer aligned in action, and not just on paper.
About the Author / Pravin Goyal
Pravin Goyal is Director of Information Security and Compliance Engineering at Cavirin Systems, a vendor of continuous security assessment and remediation for hybrid clouds, containers, and data centers. Reach him at [email protected].