Many security teams are familiar with an EDR-based approach to security. However, container protection within their cloud ecosystem can seem much more challenging and complex.
Protecting containers requires an understanding of the complete attack surface that containers expose--whether you are running them using an orchestrator like Kubernetes or locally using Docker.
In this article, we will describe the attack surface, how it compares and aligns with the security technologies you might already have, and then make the case for a stronger focus on pre-deployment protections, adding to standard EDR post-deployment detections.
Let’s start by looking at the container-based CI/CD deployment process that we will use in the article. We will discuss security controls (preferring Cloud Native) that you may need at each phase.
Note: This is a simplistic pipeline that you can customize. The idea here is to focus more on the foundational concepts related to container driven development/deployment.
Fig. Container driven development and deployment pipeline
How Does Container Security Compare to Modern Work Security?
In general, we look to EDR to provide threat and anomaly detections and to take actions such as automated attack disruption. (Automatic attack disruption in Microsoft Defender for Business - Microsoft Defender for Business | M...)
We can also consider, earlier in the attack lifecycle, how to reduce attack surface on physical/virtual assets, (including mobile devices, laptops, workstations, and servers) with AV components such as Attack Surface Reduction (ASR) rules (Use attack surface reduction rules to prevent malware infection - Microsoft Defender for Endpoint | ...), which prevent attacks by blocking common entry points. Additionally, Microsoft Edge and Defender AV can detect and block “potentially unwanted applications.” (PUA) (Block potentially unwanted applications with Microsoft Defender Antivirus - Microsoft Defender for E...)
When we think about the purpose of EDR on a system, consider when, within the MITRE kill chain, defenders typically look to this solution to take effect. Some of the benefits include (not exhaustive):
- Telemetry from the end points (user and servers). However, in case of Containers, an EDR solution would need to be aware of presence of a containerization technology and runtimes like Containerd.
- Threat Detection: EDR needs to be sophisticated enough to detect container specific attacks (see MITRE Container Matrix above).
- Compliance: In cases where you are running your containers on a Docker host an EDR can help identify the security weaknesses in Docker hosts (https://learn.microsoft.com/en-us/azure/defender-for-cloud/harden-docker-hosts.)
The Importance of Shifting Left, In General
As we shift left in our threat driven approach to security, even with traditional solutions, managing vulnerabilities and misconfigurations is a logical step “left” in the kill chain, i.e., not just locking doors, but adding locks and fixing cracks on the small, hidden windows which might be attractive to an attacker with determined, malicious intent.
For a continued healthy security posture at scale, we can automate some of the post-breach activities, reducing time commitments, thereby shifting our focus to blocking or updating vulnerable applications, fixing over-privilege for browser extensions, addressing weak or self-signed certificates, and applying configuration baselines among other activities (many of which can also be automated.)
Since modern workers draw their applications from a massive library of republished SaaS solutions, without automation and prioritization, shifting left can be a tall task for security teams. Therefore, we layer on a threat-driven approach to prioritization, considering Microsoft’s visibility to the threat landscape, so organizations can quickly mitigate those vulnerabilities and misconfigurations that are accessible, exploitable, and with potential breach of sensitive or proprietary data first.
This technology has recently been described in the market as “XSPM.” With Microsoft’s native end-to-end, approach, we call this “exposure management.” (https://techcommunity.microsoft.com/t5/security-compliance-and-identity/introducing-microsoft-securi...)
The Intricacies of Securing Containers Versus Endpoints or VMs Alone
Modern Work security often relies on securing proprietary applications that are deployed on end user devices. As a result, the attack vectors, corresponding techniques, and attack surface are very different from a container-based Enterprise Application. Refer to MITRE Containers Matrix: https://attack.mitre.org/matrices/enterprise/containers/
vs. MITRE Windows Matrix:
https://attack.mitre.org/matrices/enterprise/windows/
If you are using Kubernetes you should also consider https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ (we will not do a deeper dive on Kubernetes in this article)
Container applications certainly complicate matters for security teams whose task is to reduce risk for the businesses they protect. Containers don’t follow the same rules as modern work environments when it comes to the existing threat landscape.
Since the purpose of using containers is efficiency, bundling application code with its dependencies for seamless, repeatable, and fast deployment at scale, protection must also support these business goals.
Does EDR Provide Any Protection for Containers?
Containers are inherently different from the end user’s SaaS driven assets because they are, by definition, DevOps assets--as we see from the figure above. Container images may be built with custom code (potentially embedded secrets) while also drawing from libraries of pre-built (and therefore potentially vulnerable) binaries.
Therefore, “shifting left” takes on new meaning and requires a process driven DevOps or “code-to-cloud” approach to security.
Considering our earlier EDR-based methods for securing and protecting, we’ll observe that containers are, at their essence, processes, running with their own potentially configured network isolations (port controls). At runtime, they do utilize the VM kernel. The image will have required application binaries as well.
So, it follows that EDR could detect certain “broken rules” of even newly built container apps, that anomalies would be detected if the app begins to act out of normal bounds for an application. More specifically, as an example, signals related to “Create or Modify System Process” https://attack.mitre.org/techniques/T1543/
A capable EDR solution like Microsoft’s Defender for Endpoint (MDE) will cover several of these Techniques.
Additionally, as mentioned above, Defender for Servers P2 provides a set of Docker hardening recommendations aligned with the Center for Internet Security (CIS) Docker Benchmark.
Does EDR Provide Enough Protection for Containers?
But here, also, is where the phrase “too little, too late” comes to mind as, containers, at runtime are meant to deploy, shut down, and redeploy at scale.
Allowing EDR to kill a process to disrupt potential attacks, might also mean shutting down entire business apps at scale, thereby disrupting the balance of risk versus business requirements. So, EDR, though important on the host, won't be enabled with all of its powerful end-user focused capabilities for container hosts/clusters.
Additionally, EDR might not be aware of the application libraries present in the containerized applications.
How Should Containers Be Secured Then?
Therefore, to properly reduce business risk, defenders, again, need to “shift left,” in this case, ensuring security as the image is being developed.
Like the concept of a layered approach for modern work, defense in depth means reducing the attack surface earlier in the kill chain and utilizing protective and detective tools for the entire kill chain. For instance, in end-user environments, you might be using Defender for Office for anti-phishing policies and to paint the full picture of potential phishing or malware in teams before it ever touches the endpoint, you'll look to Defender for Identity and Entra ID to mitigate identity risks and add detections such as lateral movement, and you'll look to Defender for Cloud Apps to create SaaS app usage policies and alert on things like unusual addition of credentials to OAUTH apps.
We will need a similar suite of tools for containers based on how they work. Cloud Native solutions like Defender for Cloud provide a suite of capabilities that help you centrally achieve defense in depth.
- Linting at Developer IDE as the application and Dockerfile (https://docs.docker.com/develop/security-best-practices) is built--for example, Docker Linter https://github.com/hadolint/hadolint/releases
- Running Static Tests as the code is checked in to repos like GitHub https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/microsoft-defender-for-devops-gi...
- Running Dynamic Application Security Tests (DAST) as the code is deployed in a test environment--like a test AKS Cluster or temporary Docker Host. These are language agnostic and can be automated in a CI/CD pipeline, automated on a schedule, or run independently by using on-demand scans.
- Image Vulnerability scanning as the pipeline uploads the image to a container registry like Azure Container Registry (ACR). The Cloud Native solutions like Defender for Cloud have native integration, and, as a result make this process completely frictionless, (https://learn.microsoft.com/en-us/azure/defender-for-cloud/agentless-vulnerability-assessment-azure)
- Once the application is deployed on the VM or Kubernetes Cluster, you will have EDR type technologies to monitor the container’s activities. If you are leveraging Kubernetes the solution should also protect against these techniques https://microsoft.github.io/Threat-Matrix-for-Kubernetes/. Defender for Containers, for example, provides coverage (https://learn.microsoft.com/en-us/azure/defender-for-cloud/alerts-reference#deprecated-defender-for-...)
There are many other things that are applicable to securing the pipeline like securing Kubernetes RBAC, ensuring images are pushed/ pulled from private repositories etc.
Summary
We saw that Container Security requires a holistic approach and simply relying on the traditional tools you use for securing your Modern Workspace will not suffice.
Cloud Native solutions like Defender for Cloud provide you with capabilities that allow centralized enforcement of layered security.
