Shifting Application Security into the Runtime
Let’s go through a quick history lesson on AppSec. In the early 2000s, injection vulnerabilities were everywhere. Entire careers and companies were made to combat XSS and SQL injection.
The approach to stop this at the time was to try to find as many of these vulnerabilities as possible before the hackers did. All the vulnerability scanners started adding AppSec scans, throwing XSS payloads into every parameter on your website. At the same time, the industry craved a way to prevent these attacks rather than just worry about detecting them all.
Drawing the parallel to network security, which was significantly more mature than AppSec at this point, people were hoping for firewalls and antivirus rather than vulnerability scanners.
Why WAF Exists
Enter the WAF. Now instead of just a pizza box screwed into your server rack inspecting network traffic and blocking attacks, you could get a new pizza box to screw in next to it that you would put all of your web traffic through.
Here is how WAFs would work (oversimplified):
Each HTTP packet hit the firewall, which tried to inspect it with a pile of rules that were “known bad,” and if any of those things matched, it would block the HTTP request. This was fraught with issues, namely latency and false positives/negatives.
A network firewall is a bit simpler. It just blocks traffic from untrusted sources to ports that expose services that should only be used by trusted sources.
A web firewall is (generally) only concerned about two ports, 80 and 443, and cannot block traffic to them, so it needs to inspect whether the traffic to those ports contains attacks.
Example: A SQLi textbook would show ‘OR 1=1-- as an attack. The ‘ character ends the SQL statement and then writes a new statement that evaluates to “true,” and this bypasses login forms that were vulnerable to SQLi.
Great. How can a WAF stop this? Some of them blocked that single quote character in login forms, thinking it must be an attack. The country of Ireland had a bad time for a while, as the O’Leary family couldn’t create accounts anywhere.
The Rise of NG WAF and WAAP
Fast forwarding a bit in time, Next Gen WAFs/WAAPs started to emerge, adding a bit of sophistication to this “just run a really fast regex on the HTTP request” approach. Now there were companies like Signal Sciences, which added a new dimension to inspecting web traffic: time.
Instead of deciding whether a single HTTP packet was bad or not, SigSci would look at web traffic over time grouped by sources and let teams make more intelligent decisions on traffic that looked like an attack. Rarely did somebody pop a fully working exploit on the first HTTP packet they sent a website, so this approach worked on blocking the attacker rather than the individual attack.
This was great for a while, but now the web is changing. According to Cloudflare’s state of application security report for 2024: “API traffic is also still growing, now accounting for 60% of all traffic, and maybe more concerning, is that organizations have up to a quarter of their API endpoints not accounted for.”
Now, web traffic is quickly morphing into API traffic, and even the addition of the time variable isn’t enough to catch the new wave of security issues that come with this.
Adding more dimensions to Decisioning
Our approach that builds on all of this: We’re adding more dimensions to this graph. Bringing in additional context to this front-line decision-making allows us to be faster, smarter, more accurate, and just overall better than some of these historical approaches.
Remember when I told you SigSci just added time to their evaluations? What if we can bring in data from eBPF, logs, and API discovery tooling and build this into the same inspection that used to just be looking at HTTP packets with a regex?
How about we add info from CI/CD on what is actually being built into the app?
What if we add the API spec knowledge into the mix to really understand all the endpoints that are live?
Business logic? A WAF nightmare. Well we include it in our model and can truly understand login, password reset, AuthN/AuthZ issues, etc. - This would’ve been fully out of a WAFs scope.
Combine this with the ability to write complex custom rules that teach our protection platform about your web app specifically, and now we can move way beyond the catching of injection attacks and start preventing attacks against business logic.
Historically it would’ve been virtually impossible to catch authorization attacks while inspecting small windows of web traffic, with all the added context, we can start to piece together APIs being misused by attackers that are finding authorization and authentication bypasses.
And this is just the beginning. We’re adding new integrations and context constantly. The more of the stack we bring to the table, the more we can truly understand what is going on with your app.
With all these added vectors, Impart can do anything your WAF or your WAAP can do, and so much more.
A demo is worth a million words, how about we set one up? Schedule some time with me to see what we’re cooking, I promise it’ll be worth your time.