Introduction

Log4shell type of vulnerabilities in software packages that were previously assumed safe (Log4J) keeps appearing everywhere. Open source tooling has widespread adoption amongst enterprises and yet most of these tools are supported by developers who are doing this in their free time. Enterprises have expected and in some cases demanded fixes while FTC has threatened to sue companies who do not patch vulnerabilities like Log4Shell.  But when you’re using free and open-source software, and in the event of a major exploit like Log4shell – a good fix may be some time away. Sometimes it might just be a design feature like the way it was in the case of Log4J and it was always up to you to build a tighter security posture, to begin with.

It must be assumed that for the foreseeable future – Log4Shell type of exploits will occur, open-source developers have no reason to rush to fix the patches just because your organization depends on the same, and yet, you are liable for any damages that might occur due to zero-day attacks.

Software supply chain risks are still an issue

Open source supply chain is riddled with vulnerabilities and sometimes embedded with malicious code.  Studies indicate up to 50% of docker hub images are exploitable.

Not all mis-configs or vulnerabilities can be identified

Vulnerability scanning tools and CSPM can tackle known issues, but cannot at all identify all misconfigurations or unpatched vulnerabilities and this remains a risk.

Zero-day exploits are a fact of life

You can verify and trust the supply chain but you don’t know what you don’t know and if there’s a new zero-day exploit available then the code is going to behave maliciously once a threat actor has identified the exploit on your infrastructure unless, of course, you can patch it.

Zero-day and its association with runtime are simple.

Lack of Runtime protection means..

your code can act maliciously once it’s compromised due to misconfigurations, unpatched vulnerabilities, or zero-day exploits.

Most workloads lack runtime guardrails except perimeter level network security which means they can behave maliciously once exploited of an unpatched vulnerability, misconfiguration, or a zero-day exploit.

MITRE Provides a reference on what a malicious workload can do
The MITRE ATT&CK framework is a knowledge base of adversary tactics and techniques based on real-world observations and represents a great set of attacks that can be used to develop threat models and understand how your workload might behave in the case of a malicious code or a threat actor that has been able to infiltrate your workload

K8s sample TTPs

In the above image, a malicious pod’s behaviors could include but are not limited to

• accessing the host path
• exec’ into the container
• accessing restricted OS binary files
• initiating unwarranted, unwanted network connections via L3, L4, or L7 transport.

Workloads can behave badly if they are not protected at runtime
Malicious. It can access capabilities and features through remote code execution due to a possible zero-day exploit that was previously unknown – as demonstrated by MITRE and with Log4J as an example.

Runtime security is the missing link in shift-left of security

There’s a lot of emphasis on shift-left security but there’s no real focus on runtime as a part of shift left. Operations should not just move to “monitor” but to active run-time protection to prevent malicious activity and code from executing

So how does one protect such a workload at runtime, disallowing the workload from not doing anything else that it is supposed to do?

Read part #2 of this blog for a summary on how to protect your workload at runtime.