Myth vs Fact – Securing Containerized Environments
A quick reality check…
Albert Einstein failed math at school.
Marco Polo imported pasta from China.
Santa Claus’s image was created by Coca-Cola.
The great wall of China is the only human-made object visible from space.
Sugar makes kids hyperactive.
Lightning never strikes the same place twice.
The problem with these myths (and oh so many others…) is that they distort our perception – and therefore our reaction – to reality. In some cases, myths can be quite dangerous – in reality, the Empire State Building is hit by lightning about 25 times per year!
Another risky myth is that Containers are inherently secure.
Containers’ adoption rising – Security is still a challenge
As organizations seek to enhance scalability and accelerate delivery of their services while reducing the cost of maintenance, we see an increase in adoption of cloud and containers technology: more than half of enterprises are already (or in the process of) adopting containers, and the vast majority (86%) expect to adopt this technology by 2023.
There is a misconception that these environments are inherently secured — that they improve app isolation and are easier to patch, and that isolation is established by default to limit access to required resources only. However as proven in multiple attacks, this technology is still vulnerable to malicious attacks.
Top Container Security Risks:
- Vulnerable images (either from public or private source) – over 50% of 3rd party images include a high or critical vulnerabilities
- Often run as root or with “privileged” flag can do almost anything a host can do, run with all capabilities, and gain access to the host’s devices
- Unrestricted communication – implementing networking/firewalling rules that are in adherence to the least privilege principle can be a challenge
- Run rogue or malicious processes
- Not properly isolated from the host
Attacks on containers environments increased by 600% in the 2nd half of 2020 compared with the same period a year ago. For example, in early 2021 a cryptomining campaign targeted Kubernetes clusters.
NIST is recommending some best practices to secure containers, but many of these measures are inherent to the CI/CD process — for example, implementing minimal required access privileges, limiting the use of unauthorized images and segregating containers’ network. One of the challenges of securing containers is the implications it poses on development, integration, and delivery practices — security must be an enabler, it should not inhibit agility.
Thus, additional layers of containers-specific security are needed.
Security that enables Agility and Scalability
When considering cybersecurity for containerized environments, we are faced with the fact that existing security controls are less effective – they’re too heavyweight to monitor thousands of containers being created and removed, they were not designed to protect distributed apps, and it’s a challenge to deploy them in an effective way to monitor inter-container communication.
In addition, the hybrid nature of environments makes it difficult to control all systems with single solution – some security solutions only support certain environments (on-prem or certain cloud envs), or only specific types of container infrastructure.
Furthermore, with containers the responsibility doesn’t lie only with Sec, but is shared by development and devops – we already mentioned the importance of development and deployment best practices, and dev and devops need to collaborate with Security – making Security part of the CI/CD process.
There’s always this tension between Security and Business Continuity – how do we provide optimal protection against malicious activity and minimize risk, while not holding back the business?
Remembering that this new technology is being adopted to increase agility and scalability, Security should not be the factor slowing down the process.
DeceptionGrid in Containerized Environments
The TrapX DeceptionGrid can be deployed in containerized environments across on-premises and cloud infrastructures to secure containers, independent of attack vectors. Trap containers detect network-based attacks and provide visibility into attempts to exploit applications’ vulnerabilities and lateral movement between containers.
A “Deceptive Pod” is a pre-packaged Kubernetes pod, with one trap container. The trap container runs several services, that enable it to communicate with TrapX Security Operations Console (TSOC) and run emulations (one emulation type per Container Trap). A trap container can run any of the supported emulation types.
The “Deceptive Pod” can be deployed to any Node, at any number:
- Include One “Deceptive Pod” in a Node Image: This reduces the risk of an attacker accessing legitimate pods in the node, and enables detection of lateral movement attempts within the node and between nodes
- Include Several Deceptive Pods in a Node image: The more Deceptive Pods are deployed in a Node, the more they distract the attackers and further reduce the risk attacks on legit pods
- Define a “Deceptive Node” – a Node that Includes Only Deceptive Pods: Deceive attackers and distract them within a “mirror maze” of deceptive pods
Lures, such as fake files and credentials, can be deployed to real containers to divert attackers to traps without interfering with the real containers’ operation.
Deceptive Pods are managed through TSOC, just like any other emulation appliance.
Prioritizing Tactics, Techniques and Procedures Targeting Containers
MITRE recently released an ATT&CK Matrix for Containers, detailing tactics, techniques and procedures commonly used by malicious campaigns against containerized environments.
The challenge remains, as always, which TTPs should be addressed first?!
With TrapX Active Defense organizations can immediately find out which techniques are actively used against them and thus need to be addressed immediately, then test to view the remaining gaps – a comprehensive solution for all types of assets, including containers.