In recent years, the software security industry has focused on identifying and updating vulnerable dependencies and securing the supply chain. However, neither of these approaches will do anything to prevent the exploitation of a vulnerability introduced by an in-house developer writing a business application or stop an exploitable dependency that slipped through the scanning. Preventing exploits also requires runtime security that detects and blocks malicious behaviors in production.

Software supply chain security is just the beginning when it comes to complete software security. Focusing on only the supply chain is like focusing only on perimeter security, like firewalls and VPNs in networking. A good start, but we now live in a dynamic cloud-native world that is far from fixed. The internet and even software itself are no longer a walled garden where everything is known, we need to start thinking about what happens in the cloud-native world once software hits production. Runtime security is the answer and its role is growing, beginning in the software supply chain and ending long after the software is delivered.

Why Organizations Don’t Already Use Runtime Enforcement Tools

Runtime security tools are not new, but classic Linux security modules are notoriously hard to use and easy to turn off. They are from a world where IPs, ports, and applications could be tracked in spreadsheets. Writing or understanding profiles also requires dealing in low-level abstractions like syscalls and Linux capabilities that most developers aren’t familiar with. They can’t keep up in a cloud-native world where an abstracted identity has become key to dealing with dynamic workloads. Even adding them can be a manual and static process requiring a service restart and missing monitoring processes that started before the module itself.

Organizations often defer to using default profiles for a set of well-known applications because they don’t have the skills to write or modify bespoke ones. Even if they use tools to generate unique profiles for their business case by observing the behavior of individual applications, they are scared to use these profiles in enforcement mode for fear of false positives that could have worse business outcomes than the attacks they’re hoping to protect against.

For example, imagine that a profile turns out to disallow an alerting mechanism used to inform operators when an application is running low on resources, or hitting some kind of rate limit. If that is inadvertently interpreted as potentially malicious activity and causes the workload to be killed, the organization has a bigger problem than a lack of resources – they might end up DDoSing the application.

Conversely, the current use of overly broad profiles that aren’t tailored to the precise needs of an application means that it’s less likely that a runtime security profile will detect, let alone mitigate against, the exploitation of a (zero-day) vulnerability. Organizations want to operate on the principle of least privilege, but finding out what privileges are needed can be difficult. This leaves us between too hard to use and not granular enough.

Correcting the Abstraction for Runtime Security

If organizations are afraid to use runtime enforcement tools because they can’t write or interpret policies correctly, it’s time to rethink the abstractions that we are using. We need policy languages that refer to concepts that application developers understand, not just kernel developers! A programmer in an enterprise is probably familiar with concepts like running an executable under a certain user ID, user/group IDs having permission to read and/or write data to a certain set of files, root users being privileged, network requests using L7 protocols like HTTP or gRPC, and manipulating data in memory.

Microservice architectures make it much easier for engineers to reason about what behaviors are expected from each service. This is demonstrated in practice using application-specific network policies that restrict the traffic to and from that application’s pods. The same engineers should also be able to define a policy that restricts what executables are allowed to run in those pods and what files they are allowed to access. If we create application security policies at the right abstraction layer, we make it possible for developers to “shrink-wrap” a policy to fit the code they have written – no digging in the kernel required.

High Level Policies for Malicious Behaviors

Let’s dig into a few example runtime profiles to understand what these higher-level policies might look like when we want to block an attacker on a per-workload basis. The ones listed here won’t catch all possible malicious activity; they define a set of rules specific to one application and some behaviors are suspicious whenever they occur.

Attack: Running executable instructions of their choice on someone else’s hardware like crypto-mining, or running an executable that will be used to further escalate the attack, like a reverse shell in Log4shell). This could be executing a program on disk or in memory.
Policy: Only permitting execution of an approved set of executables (ideally identified by SHA of the file)

Attack: Accessing files to obtain, modify or corrupt data, or to change configurations that allow further escalation of the attack, like adding your public key to ssh/authroized_keys to gain a persistent foothold on the system.
Policy: Only permitting read/write access to a limited set of files.

Attack: Intercept, block, modify, or generate network traffic to obtain data, impersonate a user, exfiltrate information from the compromised system, or further escalate the attack.
Policy: Prevent with network policy and zero-trust networking.

Attack: Escalate privileges to further escalate the attack
Policy: Limit workloads to specified user/group IDs, Linux capabilities, and/or disallow namespace changes

Protecting Production, Not Merely the Supply Chain

Just relying upon supply chain security is betting on security through obscurity, hoping attackers won’t find the other holes. Enabling developers to understand the capabilities and privileges their applications need and what malicious behavior is through higher-level policies will allow them to begin to self-service the security of their applications. Rather than trying to eliminate bad actors by merely reducing CVEs, detecting malicious behavior in production will help find and stop attackers where they are. Runtime enforcement is the future of software security, if we can only make it accessible to the developers that understand their applications the best.