Several months ago, I was diving deep into the concept of application security after spending years working on products for the practitioner side of enterprise security. During that period, it really started sinking into my mind that there is not a standard approach, let alone any approach, for embedding security directly into an application. Let’s define “embedding security directly into an application” - This means putting security code inline with application code that is invoked during the application runtime. Let’s be clear about what this does not mean - this is not about securing the application development process or the build time of an application. There are a lot of great solutions out there already for that.
As an example, let’s think about what a SOC analyst does during the incident response process. They receive an alert; they pull apart all of the artifacts of the alert and investigate those artifacts, make a determination, then act. If they are lucky, their organization has some level of automation in place to accelerate that process for them. But what if some of those calls could exist as runtime code inside the application? For instance, consider a developer’s file upload capability embedded with the ability to check the file against known bad hashes, scan it for malicious activity, and even detonate it in a secure environment to understand its behavior. It’s like taking a SOC team, codifying it, and wrapping your application around it. This is a great example of embedding security inside of the application. In this context, the term “runtime” does not mean container security while containers are running, and it does not mean Runtime Application Self Protection (RASP). In this context, security in application runtime specifically means code (in this case, security functions) invoked at application runtime.
Why isn’t this happening now? My initial read suggests that this is not on the mind of application builders. The typical builder is unlikely to have first-hand knowledge about the tools used by security analysts, let alone how to use them. Builders are unlikely to have heard of tools/companies such as ReversingLabs for file reputation, Crowdstrike for threat intelligence, Neustar for IP geolocation, and many others. And while builders are typically not plugged into that side of computing (security, incident response), the creators of these tools are typically not communicating to the builder community. The companies that build these tools are typically marketing to the enterprise security experts and leaders.
I’ve talked to a few stellar incident response experts and have asked, “What if a lot of the contextual information you gather in an investigation was baked into the development process and stored in a log?”. Unanimously every incident responder I talk to loves the idea for multiple reasons:
There is a measurable time savings and efficiency gain in the security process.
It gets application developers and security responders on the same page and communicating. It forces a team dynamic and a better (more secure) outcome.
Further, it allows for more efficient permit/deny decision-making to occur in the application runtime, helping to reduce penetration into the application attack surface, and helps to reduce risk of breaches and attacks. After spending a lot of time in the SOAR space with incident response, I see this as a possible evolution:
Phase 1: Incident response is done manually (yesterday)
Phase 2: Incident response is automated (in process today)
Phase 3: Next - Embed security processes into the application, and log effectively
NOTE: We will expand more into SOAR in a soon-to-be-released blog.
Now for some “what-ifs?”.
What if application builders had access to these tools via APIs?
What if application builders had code examples illustrating how and when to use these APIs?
What if the security team could constructively collaborate with builders on how and when to use these APIs?
This is the next project we’re all aimed at solving with the team at Pangea. We would like to build this and bring these capabilities to the front line of application development so that builders have friendly access to security APIs for their apps.
