Shifting Runtime Security Left
For the past few years, AppSec has been all about shifting left. It’s all the rage. All the kids are doing it. And the reasons for that are quite compelling. For one thing, putting security validation in the CI/CD pipeline, rather than just at runtime, means that you can prevent problems from getting into production, rather than just detecting and solving them once they are there.
Additionally, there is a notion, which is probably true but somewhat inflated, that fixing problems detected early is cheaper and faster. Finally, as more developers and DevOps engineers now take on parts of the burden of application security, these shift left tools and processes are often a better match for them than runtime security tools.
However, something dangerous is starting to happen. We’ve become so enamored with shifting things left, that some people are starting to put runtime security aside and focus entirely on things that can be done in the pipeline or earlier.
Why is shifting too far left a problem?
Ignoring runtime security is a problem because in reality, even with a tightly controlled DevSecOps process, bad things are possible. This can be because things that were thought to be benign were later discovered to be malicious. It can be because some complex interplay within our infrastructure allows some weakness which can’t be detected during deployment. And it can be because in life, we are rarely hit with what we’re expecting and preparing for.
Runtime security helps us mitigate these sorts of risks, and it’s still a necessary cornerstone of proper AppSec.
Having said that, all the motivations mentioned above for moving things earlier and into the hands of engineers still apply. This is why ProtectOnce is pioneering Runtime Security that can be shifted left.
Shifting runtime security left
While shifting runtime security left means several things, the overarching theme is figuring out how a developer that cares about security needs it to function.
For starters, developers don’t deploy runtime components in many scenarios, so shifting runtime security left means enabling security that a developer can insert into the application within their domain. For ProtectOnce, this means a lightweight security library that can easily be installed like any other library (if you’re thinking npm install protectonce then you’re spot on). Security should be like any other functionality a developer wants to include in their app.
Additionally, this runtime security should be something that not only applies to production environments, but that developers can transparently use (and test) during staging and even while running on their laptops debugging.
ProtectOnce’s runtime security also needs to be lightweight, transparent and robust, so it doesn’t significantly impact the application’s behavior or performance. Developers need to know that their code will still work well, that the security won’t cause unexpected interference (well, unless we’re under attack), and that everything will work as expected at runtime.
Developers also need multiple ways to interact with a security product. Dashboards and web-based UIs might be useful for some things, but developers need to be able to do most things via CLI, API and even IDE plugins, and ProtectOnce is empowering them to do just that.
How ProtectOnce works
It should come as no surprise that the phrase “with one line of code” appears eight million times on our website. We’re really focused on a solution that doesn’t add work to our developers’ already insane workloads. Surprisingly, we have been able to extract an incredible amount of security goodness from that one line of code. Let’s walk through the highlights:
- Application Runtime Posture Assurance – I know you’re scanning for bad configuration, dangerous code and malicious open-source during the pipeline. But trust me, when a log4j type event hits, you’re going to want to know, definitely, what’s actually deployed at runtime, not just what you think you saw last time it went through the pipeline. More than that, you’re also going to want to know if log4j is actually being loaded and used, rather than just part of the deployment package, because that will help you focus your time, effort, and triple-shot-espressos on fixing the ones that are more dangerous first.
- Workload Edge Defense – this is like WAF and API Protection, but built for 2022. In a modern application, workloads interact with the world, with each other, and with all sorts of managed services. Attackers know this and can leverage this complex architecture to find all sorts of clever ways to attack that don’t behave as we might expect. ProtectOnce believes that every workload needs edge defense, monitoring incoming and outgoing data for attack patterns and suspicious behaviors. This is true for external-facing web application servers, of course, but it’s also true for backend microservice that shouldn’t be directly accessible to an attacker (because shouldn’t and aren’t are, unfortunately, not the same thing).
- Runtime Application Self Protection – the elusive, holy-grail of AppSec, RASP, is realized here in a way that works for modern application architectures. The ProtectOnce library (remember, one line of code… yeah, you get it) automatically and transparently inserts behavioral detections deep in your application, so that malicious behaviors that might slip past the Edge Defense will still be caught.
- User Activity Tracking and Account Takeover Prevention – Another critical feature for the modern application is making sure you can detect malicious actions taken against your users. Attackers are always coming up with new ways to try and steal your users’ passwords, access their accounts, and abuse your system. Part of the challenge here is that this sort of attack can’t always be detected in the workload, since your application is distributed and auto-scales. Imagine your AWS Lambda-based login function. Someone trying to guess a user’s password won’t be hitting the same Lambda instance each time. ProtectOnce libraries securely communicate with a security backend that correlates the signals from all the libraries, and can detect and respond to these more complex attacks.
- Custom Security Workflows – Extending the ATO prevention to more custom triggers and responses empowers security minded developers and AppSec teams to collaborate on all sorts of workflows to enhance product security. For example, want to detect if someone is messing with your shopping cart logic? Set up a workflow. Want to block users who are sharing accounts across multiple geo-locations? Set up a workflow.
Sounds Too Good to be True
Sure it does. Because for a while now, AppSec, especially runtime AppSec, hasn’t kept up, and doing things like this took an incredible amount of work if it was even possible. That meant that only a really motivated security engineer, who had the time and knowledge, could even try to get all these things solved. Security minded developers didn’t stand a chance.
Surprisingly, when you decide to build your AppSec solution from the ground up with your number one requirement being “A Developer Can Use It”, a lot of other things fall into line. One line. Of Code. There, I got it in one more time.