Building security into DevOps versus bolting it on

In this podcast, Hari Srinivasan, Director of Product Management for Qualys, talks about building security into DevOps versus bolting it on, specifically for containers.

Here’s a transcript of the podcast for your convenience.

Hello! My name is Hari Srinivasan, Director of Product Management for Qualys, cloud and virtualization security. Welcome to this Help Net Security podcast. Today we’re going to talk about building security into DevOps versus bolting it on, specifically for containers.

Containers are evolving to be a core element of the IT fabric powering digital transformation. They offer a new level of abstraction to efficiently develop applications that can be moved across distributed environments.

They can be easily paired with cloud and open source tools, enabling organizations to iterate at a higher level for more rapid and flexible software development. Containerized applications are most often developed and deployed in security, as developers race to build requiring a radical rethink of how security gets embedded into the process. Security needs to be agile and automated, so it doesn’t impede the development process. Security needs to be integrated at the time of the image being built, and also through the entire container lifecycle.

This concept of embedding security early in the development cycle is commonly referred to as shifting security to the left. Container security introduces new types of threats, and security teams typically encounter the following.

1. Unvalidated external software. Container images are often downloaded from untrusted sources are open public repositories directly from the vendor, bringing in vulnerabilities as they come into your system.

2. Non-standard configuration. A mix of configuration with their own security bugs and risks exposes IT environments to a higher risk of breaches and potential loss of sensitive information. And also following non-hygienic deployment practices by the developers for building applications quick and fast, embedding things like passwords and secrets as a part of their development kit.

3. Insecure East-West communication. Containers, rather than the host, can communicate among each other. You need to think about a new form of container context or container-native strategy to protect against this East-West communication.

4. Ephemeral nature of the containers. Containers are intended to constantly be spun and disappear in keeping up with the business demand. They are lightweight, portable, elastic and efficient. This makes it even more difficult to track things as they spin up and spin down so quickly, and so fast. So, security needs to be aware of every single action that is happening in the container environment.

Today more security teams are challenged by tools that offer siloed views instead of a single pen view that spans their traditional infrastructure and the containerized environment. This would enable teams to be more efficient doing pin pointing and addressing threats. Given the dynamic nature and the massive sprawl of containers, security tools need to integrate into orchestration tools for automated deployment, and tracking and monitoring of containers at this scale.

I would recommend the following capabilities.

1. Discovery and tracking at scale. It is important for security teams to know a detailed list of inventory of all their container projects. Understanding how the containers came by, which image they came from, which repository these images were present, identifying the complete topographic information, in addition with the rich meta data of the inventory, helps security teams to keep tabs off ongoing development into containers, and also keeping tab off the sprawl.

2. Continuous vulnerability and compliance management. Security needs to integrate vulnerability management and compliance checks across the complete pipeline. It needs to start all the way from the built environment moving further as the environment grows into registries and also into running containers. And don’t forget you also need to identify vulnerabilities and compliance for the host, so you need a solution which tracks the complete stack across the pipeline. The vulnerability management and compliance solution needs to be integratable into your CI/CD tool. Look for plug-ins or APIs to do the work for you.

3. Runtime security and defense. It is critical to protect containers during the runtime. Given an exceptionally dynamic environment compared to that of the virtual machines, an automated methodology to identify events happening in runtime and distilling out the anomalies is important to protect containers during the runtime. You can start off at the basic level of having an automated enforcement to deny containers from being spun up for a vulnerable image, or a non-compliant image. As you grow forward, and as your maturity increases, you can pick up a container native IDS and IPS solution. These need not be the traditional IDS and IPS, but an anomaly-based behavior analytics-driven IDS and IPS solution which identifies that behavior of how the containers are supposed to perform. And if there are any deviations from that, it helps you to block it, protect it, or secure it by moving it to a different node for introspection.

4. Operational monitoring and incident management. There’s no more patching for containers. The data which you need to identify issues are a little different. The logs you collect might be a little different in containers, and thus specific to the environment that they’re deployed on. You need to have Kubernetes-specific knowledge for Kubernetes-based deployments, Mesos-specific knowledge for a Mesos deployment. So, you need to overhaul your operational monitoring following an incident management. Since there is no patching, since all the activity of patching happens on the Docker image, you need to have the operational information needed to update the container environment at the build stage.

You need information to update containers back at the build stage. You also need tools that offer native container support for collecting these specific logs and providing this information as a part of your process chain. The solution needs to be integrated with your SIEM and ticketing systems, bridging the operational silos and enabling monitoring at scale.

Let’s now see what Qualys has to offer. Qualys solves four key use cases for your container security. Qualys extends the security platform to include containers, providing you a single pane of view off your regular environments, be it on your data centers or cloud, along with that of containers. These container deployments can be based on any orchestration environment, can be Kubernetes, Mesos, be it running on Amazon, be it running on your open shift environment or your own Docker-based swarm environments. Qualys Container Security solves these four key use cases in its first version.

1. Visibility into container projects. Inventory of images and containers across your environment providing you with the capability to search based on vulnerabilities, labels, tags, packages and other attributes for an image. You can use an out of the box dashboard or quickly customize the dashboard and add your own widgets to track and view security of your deployments.

2. The second key use case which you are solving with container security from Qualys is the ability to do vulnerability management at the source, securing security images in the CI/CD pipeline. Identifying vulnerabilities as they are being built. Qualys introduces plugins for Jenkins and soon to be added for Bamboo, TeamCity and CircleCI. They help you to block images which are not passing the threshold of vulnerabilities being set by the security team entering into your repositories. It also provides you with information for the developers within the plugin itself, enabling them to continuously remediate vulnerabilities they identify.

3. With the information being collected, you are able to identify threats and impact across environments. Find out if all the images are still active, know which containers are exposing a specific vulnerable port or communicating to an external IP which is malicious. Identify for a particular malicious or are vulnerable image what’s the impact, or what’s a surface area of all the code by understanding all the containers which are deployed for it across your environment. Giving you this information helps you to identify the track quickly, and the ability to identify the impact of that particular threat across your environment.

4. An important use case of detecting runtimes which are drifting based on security and configuration from that of their parent image. As we analyzed running containers, you identify and distil containers which show anomalous behavior wherein the vulnerability posture, the security package information on the configuration of those containers vary from that of the image. Identifying those containers as rogue containers enable it for you to drill down to understand which event triggered that activity.

If a user ran a curl or wget to change the composition of the containers, or any other scripts that execute as a part of the instantiation of the containers, which aren’t supposed to happen, those containers are identified as rogue. With these four use cases being solved with Qualys Container Security you will be able to provide security for your content environment in a continuous fashion alongside with the rest of your environment within a single-pane-of-glass view.