Sysdig: Container Threat Detection

With a majority of businesses reporting that a significant percentage of their workloads are hosted in containers, container threat detection has become a critical concern for organizations of all types.

Unfortunately, it’s also a challenging priority to address. Container security threats come in many forms – from runtime security threats, to networking threats, to container image threats and beyond – and detecting them requires assessing your containerized software stack at multiple layers.

This article walks through the different types of container security threats you should look for in order to stay ahead of the security risks that could impact containerized workloads no matter where they arise.

What Is Container Threat Detection?

Container threat detection is the process of identifying any type of security risk that could impact workloads hosted in containers. From privilege escalation threats, to malware, to insecure networking configurations and beyond, container threat detection provides broad protection against the various types of security threats that may exist within a containerized application environment.

Approaches to Container Threat Detection

Because container security threats come in many forms, detecting them requires assessing multiple categories of potential threats at different layers of your environment. The following are the chief areas of risk to consider.

Container Runtime Security

A container runtime security threat is any type of threat that affects a container once it is running.

There are two main vectors through which runtime threats can arise:

• Compromised container images: Malware inside container images could generate active threats once containers are deployed.
• Insecure runtime environment: Insecure configurations like allowing containers to run in privileged mode or granting them access to sensitive data could lead to breaches.

For a runtime threat to occur, at least one of these conditions typically needs to be present. In many cases, however, they’re both present: for example, a tainted container image may introduce malware into a runtime environment, and the malware’s impact could be exacerbated by insecure configurations that fail to isolate the compromised workload.

Runtime threats could arise in other ways, such as a security vulnerability in the container runtime (the software that executes containers) or an OS-level vulnerability on the server that hosts the container. However, these threats are relatively rare compared to risks that originate from within containers or the environment where they run.

Detecting Container Runtime Threats

Because most container runtime security threats originate from insecure images and/or environment configurations, the main strategy for detecting runtime threats is to scan images and environment settings.

Container image scanning is a straightforward process that can be performed by any mainstream container scanner. In most cases, you can scan any type of container with any widely used scanner.

Scanning environment configurations may be more complex because it depends on where you are running your containers. If they are orchestrated by Kubernetes, you’ll need a runtime threat detection tool that is capable of analyzing the various types of configurations that govern Kubernetes. If you’re using an alternative orchestration solution, like AWS ECS, you’ll need a tool designed to analyze that type of environment.

You should also continuously monitor logs, metrics, and (if they’re available from your runtime environment or orchestrator) audit trails to detect active runtime security threats. Monitoring tools like Falco can help you do this.

Container Network Security

Containers themselves only host applications. Networking resources are external to containers, and they are typically managed by an orchestrator or service mesh that is distinct from the containers themselves.

Nonetheless, insecure networking configurations can have major consequences for the workloads hosted inside containers. Network settings that don’t properly isolate containers from one another may allow a breach in one container to spread to others or make it easier for a compromised container to access sensitive data owned by a different container.

Thus, the network is a prime vector for both starting and escalating attacks against containers. Detecting threats that originate on the network, then, is an important component of overall container threat detection.

Detecting Container Networking Threats

There is no one-size-fits-all approach to the detection of network-based container threats. Container networks can be configured in a variety of ways, and your container network architecture may vary widely depending on factors like which orchestrator you use, whether you run your containers in the cloud or on-premises, and whether you use a service mesh.

That means that, to detect network threats effectively, you’ll need a container threat detection tool that can interpret the network configuration settings of whichever platform you use to run your containers.

At the same time, you should deploy a tool that can analyze networking data in real time to detect threats. Activity like malicious traffic from one container to another or attempts to flood the network with illegitimate requests (which could be part of a DDoS attack) can be detected by identifying anomalies within network behavior.

To work effectively, however, network threat detection tools need to be capable of identifying true anomalies within environments where networking configurations constantly change. In most cases, IP address assignments, load balancer configurations, and the total number of endpoints in a containerized environment are updated constantly as containers are created and destroyed in response to fluctuations in demand.

For this reason, it’s difficult to establish a static baseline of “normal” network activity and measure anomalies based on it. Tools must instead be able to determine baselines based on dynamic configurations and correlate network traffic patterns with other data sources (like audit logs) to make informed decisions about what constitutes a true container network threat and what is a normal traffic fluctuation.

Security threats against containerized applications can materialize in a variety of ways. Organizations must be prepared to detect them all by adopting a multi-pronged approach that is capable of surfacing threats no matter where they originate – whether they’re in container images, runtime configurations, networking configurations, or somewhere else.