Organizations are increasingly relying on Kubernetes to orchestrate and manage their containerized applications. While Kubernetes offers a powerful framework for deploying and scaling applications, managing complex applications manually can be a daunting, error-prone, and lead to a multitude of security issues. One of the primary challenges lies in the sheer complexity of managing multiple components across a Kubernetes cluster.

10 minutes to pain. When it comes to cloud security, 10 minutes or less is what bad actors need to execute an attack. Does it mean your business could be at risk if you fail to detect and respond to an attack in less than 10 minutes? Absolutely yes. With more and more sophisticated security attacks actively occurring nowadays, security teams need to hold themselves to a modernized benchmark.

In my previous blog post, What you can’t do with Kubernetes network policies (unless you use Calico): Advanced policy querying & reachability tooling, I talked about this use case from the list of nine things you cannot implement using basic Kubernetes network policy — advanced policy querying and reachability tooling. In this blog post, we’ll focus on the use case — the ability to log and analyze network security events.

Containers have revolutionized development in the cloud, allowing dev teams to work with unprecedented speed, efficiency, and scale. But securing containers at that speed and scale can be a thorny problem. The infrastructure of containers is complex and contains multiple attack vectors, and most enterprises don’t have the time or resources to secure all attack vectors for all containers.

Containers offer many benefits, including lightweight portability from one environment to another, but they add a layer of complexity to application security that can introduce additional risks. There are many ways a container can become vulnerable to attack: through its source code, how the container is built, how the container is configured, how it secures secrets, and how it interacts with the host and other containers. Each of these avenues has its own security solutions and best practices.

The heightened demand for cloud applications places a premium on the agility of development teams to swiftly create and deploy them. Simultaneously, security teams face the crucial task of safeguarding the organization’s cloud infrastructure without impeding the pace of innovation.

The Sysdig Threat Research Team (TRT) discovered the malicious use of a new network mapping tool called SSH-Snake that was released on 4 January 2024. SSH-Snake is a self-modifying worm that leverages SSH credentials discovered on a compromised system to start spreading itself throughout the network. The worm automatically searches through known credential locations and shell history files to determine its next move. SSH-Snake is actively being used by threat actors in offensive operations.

The Sysdig Threat Research Team (TRT) published their latest Cloud-Native Security & Usage Report for 2024. As always, the research team managed to shed additional light on critical vulnerabilities inherent in current container security practices.

This is the first article in a series focusing on syscall evasion as a means to work around detection by security tools and what we can do to combat such efforts. We’ll be starting out the series discussing how this applies to Linux operating systems, but this is a technique that applies to Windows as well, and we’ll touch on some of this later on in the series. In this particular installment, we’ll be discussing syscall evasion with bash shell builtins.

Today’s digital organizations thrive in the cloud. The advantages are undeniable – cost savings, scalability, and seamless access to resources, applications, and data all foster better business agility, collaboration, and innovation. With over 85% of organizations adopting a cloud-first strategy by 2025, it’s clear that the cloud is integral to modern operations.