The Need for Runtime security in the cloud – Part #1
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 […]
Reading Time: 2 minutes
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
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.
Must read articles
- Zero Trust (ZT) – The Future of Cloud Security
- Zero Trust (ZT) Architecture, Framework and Model
- Cloud Security Governance, Risk and Compliance (GRC)
- How to Pick the Right CNAPP (Cloud Native Application Protection Platform) Vendor
- What is Driving the Need for CSPM (Cloud Security Posture Management)
- Agent vs Agentless Multi Cloud Security
You cannot secure what you cannot see.
Your most sensitive information is stored on endpoints and in the cloud. Protect what is most important from cyberattacks. Real-time autonomous protection for your network's edges.