1 day Ago
ATHENS - AUGUST 27: Liu Xiang of China crosses the finish line as he finished first in the men's ...
More 110 metre hurdle final on August 27, 2004 during the Athens 2004 Summer Olympic Games at the Olympic Stadium in the Sports Complex in Athens, Greece. Liu equalled the world record of 12.91 seconds.
(Photo by Stuart Hannagan/Getty Images) Developers develop. Software application developers program applications by coding in their language of choice, on and to their platform of choice, inside their preferred integrated development environment and through their chosen application engineering methodology. While some or all of those factors may be governed by the team that they find themselves in and so become less of a personal decision, there is a general notion of freedom to be, especially perhaps when it comes to the use of open source toolsets.
As laissez-faire as all that sounds, developers are also directed towards a number of system management responsibilities that need to happen to ensure “uptime” is maintained and users get functionality out of the applications and data services that they need to work, or indeed play. While all software engineering teams of any reasonable size will have a dedicated security team (and smaller ones obviously won’t always have that luxury), the rise of cloud computing and the Kubernetes container orchestration platform has put more of the control responsibility back in the hands of the cloud development engineer themself. Because cloud and containers move so fast (some are “spun up” into existence for mere minutes), the security consideration must move to the point of application runtime i.
e. the point at which an application actively executes and makes calls to the resources that surround it in the environment it is built in. But how do developers know what to work on around security fixes today? Traditionally, this has seen them take a list of issues from the IT security team (all pretty much without context or application environment information) and then attempt to work through a process of reverse engineering logic as they try to understand what’s happening in any given cloud.
This could mean working through thousands of items spanning different software libraries, different cloud container images, different data feeds and different third-party plugins and more. What developers would like in these scenarios is a way to find the root cause of security issues and be able to prioritize actions to remediate system health. But cloud computing has changed some key fundamentals, so what route do we take to get to the root now? Real-time cloud-native security tools company Sysdig has plenty of opinions to share here.
“Sysdig was founded to solve a problem. That problem was the question of how we do observability when we can’t look at a packet [a chunk of data moving over a network with routing information to tell it where to go] in the virtualized and abstracted world of cloud,” said Alex Lawrence , director of cloud security strategy at Sysdig. “We knew that was our mission, because packets don’t lie.
But this is not the old days of networking where we could look at network switches to see packets; now, those packets run on someone else’s infrastructure, the cloud services provider. So we know that the system call becomes the lowest common denominator and we have access to that information. If I’m on a server in a virtual machine in the cloud, the system call is the thing that creates the packet.
It’s the thing that gives the instruction to write the file.” To define this term, a system call is an interface mechanism between an application and its governing infrastructure (often the operating system kernel) that enables the application to access the memory, processing power, data storage or other services that it needs to breathe. Sysdig Lawrence along with founder and chief technology officer Loris Degioanni say that a system call is arguably a richer telemetry source than a packet ever was.
This is due to the fact that in any software system, there’s “stuff that happens” without ever becoming a packet. For example, let’s say an application wants to perform a call on a host server in a container. It doesn’t have to leave the cloud container or the host to make this action happen, it all occurs internally.
“But if we can ‘instrument’ the system call, we can now know everything happening on that individual host, right? So Sysdig originally was an observability company that was doing all the observability metrics to analyze everything happening on a host cloud server and see what was going on,” said Lawrence. “But then we had customers early on saying, hey, you realize that this has really big security implications too and it’s not just observability. That’s what inspired the company to create project Falco, which is basically like a camcorder that tracks all the things happening inside a cloud.
It is system analysis that looks for an abnormal system call that shouldn’t be there, or find the structure of the executables within an application or database query or whatever that shouldn’t be happening in the ‘normal’ course of operations.” One analogy here is likened to being at home and turning the tap on and getting beer or wine out of the faucet instead of water i.e.
the thing that is instructed to do something which we would normally expect to happen, is doing something we don’t expect to happen. But this isn’t beer taps, this is what we can now call a cloud-native application protection platform, or CNAPP for short. The Falco project is powered by rules and all those rules are written in the the YAML software language.
Now a graduated project housed under the auspices of the Cloud Native Computing Foundation, Falco can be described as an open source runtime security platform that enables software developers to find and react to suspicious behaviour within Linux containers and applications. Falco was conceptualized, designed and built to work with Kubernetes, but its realm and purview is not limited to Kubernetes. This means it is also capable of delivering runtime security monitoring for other container orchestration platforms and standalone container deployments.
“Falco’s journey is far from over. As cloud-native security threats grow in complexity, Falco is evolving to meet them head-on. The focus for the coming year is clear: deeper Kubernetes integration, a more sophisticated plugin system.
.. and a shift toward automation in runtime security.
Perhaps the most exciting development, though, is the growing synergy between Falco and Stratoshark [a software tool built by the same team that created Wireshark, which analyzes system calls and log messages]. Together, they are setting the foundation for a new security paradigm – one where detection, investigation, and response are seamlessly unified,” wrote Degioanni on his company blog. “Runtime security has always been about visibility, but as Kubernetes environments scale, visibility alone isn’t enough.
Falco is tackling this by modernizing its stack, making security more automated and easier to deploy.” He asserts one final note to suggest that Falco and Stratoshark will pioneer a Kubernetes Detection and Response (KDR) approach. Next we will see tighter integration between the tools, automated forensic workflows and collaboration between the Falco and Wireshark communities to redefine open source runtime security.
Where companies like Sysdig are taking us is towards a future where software developers get more immediate control of system and application health from first principles. While the perceived notion is that programmers care most about “cool functionality” on the road to creating the next killer app, they do in fact care a lot about vulnerability management in the virtual cloud arena. “Taking stock of where we are today, there are vendors that specialize in software system detection & response (think of this like a security camera on your house) and there are vendors who offer security posture management technology (a wider angle view on an IT stack to make sure there are locks on the doors of the house) today.
To continue our home security analogy, if your door locks are broken, but no intruders are near your house, then you know how to act accordingly vs a scenario where you’re actually about to lose your possessions. Sysdig was engineered from the start to provide both sides of this weigh-scale so that we can offer a total security platform offering,” said Degioanni. “Our platform now sits at that broader point where we can offer users the most accurate visibility into their cloud IT stack as fast as possible.
.. a combination which is now empowered and accelerated with agentic AI services.
To offer a platform technology proposition in this way, Sysdig has collected and correlated vast amounts of data from system calls and posture status (using our backbone and employing a graph database) so that all data and information relationships can be tracked and mapped accurately, quickly and in the most efficient way possible.” We live in a world where software system security is trying to be more automated (through artificial intelligence yes, but also through system-level automation that we probably wouldn’t classify as AI), more hands-off and more self-service. It’s a large part of why we’ve been able to talk so volubly about so-called DevOps as the marriage of shared responsibility between developers and operations staff.
The notion of platform engineering and agentless technologies have subsequently followed suit for the same reason. Will we still need IT security teams in the future then? Yes, obviously, they may be able to spend more time refining and finessing the tools inside platforms like Sysdig than chasing vulnerabilities and attacks. It’s all getting a whole lot more granular in computing.
.. and, from a user security perspective, fine-grained is just fine.
.
