LAST UPDATED March 22, 2022
“Can the API security tool you are pitching – on its own – stop (block) API attacks real-time?”
(Salesperson avoids the question – round 1)
“No, not through integration with yet another tool – on its own, and in real-time?”
(Salesperson avoids the question – round 2)
“No, I’m not talking about the OWASP API Top 10. Those are important, but do not speak directly to stopping attacks on APIs in real-time.”
(Salesperson uncomfortable pause)
Why the uncomfortable pause? Because it’s all in the fine print for some salty, nameless vendors hawking API security tools – under the guise of real-time blocking. But that’s where the conversation needs to begin.
But, before we get ahead of ourselves, let’s back up for a moment:
API security is one of the hottest markets today – and for good reason. Last year, Gartner predicted that APIs would become the most sought-after target for attacks. Given the extreme growth in APIs – and the fact that APIs are a gateway to a ton of valuable corporate and personal data, it is not surprising that attackers have set their sights on API.
When an attack is launched at an API – which are often complex initiatives combining massive botnets along with any number of evasion techniques – job one is clear: block the attack in real-time. If the attack is not stopped, the breach may result in the loss of private corporate or consumer data. Exfiltration doesn’t wait for analysts to pour through data after the fact. It often happens in real time – thus, the attack needs to be blocked in real time.
Read the Fine Print – “Blocking” API Attacks in Real-Time
Which brings us back to the introduction of this blog and the question API security tool vendors need to be asked: “Can the API security platform you are pitching – on its own – stop (block) attacks on APIs in real-time?”
At first glance – and if you listen to the claims of Salt Security and Noname Security – you’d think the answer was yes. These vendors make bold claims that their tools block attacks and stop threats in real time. But, when you read the fine print, the real answer seems to be a resounding “no.”
Rather than blocking attacks, those salty, nameless API security tools are, for the most part, serving as anomaly detection tools that then feed data to another tool – such as a WAF – for blocking. Don’t take my word for it – here’s what they say in their own words taken from their own websites:
Salt Security
- “Stop attackers manually or automatically using existing enforcement points such as an API gateway or web application firewall (WAF).”
- “Salt captures the full attack timeline, displaying it in our dashboard and sending the information to your SIEM for incident response teams to analyze. You can also opt to have the Salt platform automatically block attacks. Salt leverages integrations with inline tools such as API gateways and firewalls to block attackers before they succeed.”
Noname Security
- “Prevent attacks in real-time, fix misconfigurations, automatically update firewall rules, webhook into your WAFs to create new policies against suspicious behavior and integrate with existing workflows (ticketing and SIEMs).”
As we wade through the fine print, a few red flags fly high:
🚩🚩🚩 “Stop attackers manually” – manually? 😳😳😳 enough said.
🚩🚩🚩 Integrate with a WAF to “stop attackers automatically” or “prevent attacks in real-time” – in other words, use an API security tool to detect an anomaly and another tool to stop the attack; hard to imagine that’s the ideal scenario for a security team.
🚩🚩🚩 “Create new policies” – oh, that sounds a lot like writing new rules – every security professional’s favorite pastime. And, by the way, it’s nearly impossible to build rules that defend against complex, multi-vector attacks. It simply doesn’t work.
So, while the claims of blocking attacks in real-time are mighty and bold – the reality is quite different. These tools expect to become yet another point solution in a portfolio of technologies that never stops growing. More importantly, though, these are likely highly flawed strategies from a security perspective.
As mentioned earlier, one problem with moving API security data offline to a SIEM-like solution is that you are essentially detecting threats after-the-fact. Because the traffic flow is not being assessed in real time, it is not possible to block an attack in reality.
Beyond the lack of real-time capabilities, when these data are fed to another tool for blocking, the presumption is that a static rules/signature engine will be sufficient. Again, here, the thinking is flawed: attackers are not using simple attacks that fit the model for static rules. Rather, they are launching complex attacks – and attacks that span weeks or months – in campaigns that are nearly impossible to defeat via rules. Sure, if you recognize a suspicious IP address, it can be blocked, but attackers know this and will use various evasion techniques, including multiple IPs, in response.
One problem with moving API security data offline to a SIEM-like solution is that you are essentially detecting threats after-the-fact.
Why does this matter at ThreatX? Because, unlike these other vendors, we do – and are happy to show you in a demo or prove it in a POC – have the ability to block attacks in real time. We have the ability to discover APIs you didn’t know existed. We don’t require you to write an endless number of rules. And, we certainly don’t expect you to do any of this manually. That’s what our managed services and Security Operations Center are here to do for you.
Drop us a line and let us prove it to you. And, be sure to ask any salty, nameless vendors you run into to do the same!
