LAST UPDATED Jul 06, 2022
It has been a couple of weeks since the return of RSA Conference to San Fran’s Moscone Center. There was a ton of energy on the floor, and those who attended were genuinely excited to be back in person.
For ThreatX, it was a great opportunity to talk with a slew of security professionals about their challenges and priorities. A number of times, those we spoke with commented that APIs seemed to be a major theme at the conference.
Along those lines, I’m not sure if it was intentional or not, but there was even a mini-API security tool pavilion in Moscone South where Salt Security, Noname Security, and others were a stone’s throw from one another. Beyond that, API messaging was sprinkled throughout the show floor. Including at our booth, where “API Protection” was prominently on display.
Given the corner-to-corner API messaging at RSA, it’s not surprising that one of the first questions we tended to hear was: “So, how are you different?”
Fortunately, that is not a hard question for the ThreatX team to answer. Unlike ThreatX, which offers the ability to stop attacks against both APIs and web apps in real time, the point tools mentioned above generally focus on API observability and anomaly detection – not API protection. Observability and anomaly detection may provide a pile of data for analysts to review, triage, and action, but it does not deliver immediate protection against attack.
The bottom line is there are a set of questions that need to be answered with an affirmative “YES” to state, with conviction, that a technology is well-suited to deliver API protection capabilities. And, if you can’t get an affirmative and provable (ask for a demo!) “YES” – then understand you are on the fast track to not protecting APIs against attack.
Does the technology protect against bots natively – i.e., without requiring a separate bot protection tool?
APIs are under constant threat from bots and complex botnets. As companies roll out mobile apps – think hospitality, travel, and entertainment, for example – bots target APIs, often via credential stuffing and account takeover attacks, among others.
Salt Security and Noname, among others, do not offer bot mitigation capabilities. If an API “security” product can’t protect against one of the most prevalent forms of attack – how is it positioned to secure APIs?
And, even with a third-party bot management integration, these API security point products cannot correlate attacks across multiple IPs. Why? Because they don’t have enough information about the user or IP to make the association. The results are that distributed attacks will often go undetected.
ThreatX, on the other hand, offers an integrated platform (not cobbled together through acquisition) to protect APIs and web apps against bots, complex botnets, and DDoS attacks, for that matter. These are capabilities native to the platform and actively protecting customers every minute of every day.
Can the technology block attacks in real-time – i.e., stop an attacker before they are successful in their mission?
The offline nature of many API “security” tools is a bit of a paradox. Merriam-Webster defines “secure” as being free from danger. The only way for an API security technology to live up to this promise is to block attacks in real-time – which cannot be done with out-of-band, offline approaches.
What will the offline API vendors say? “Beware latency with in-line approaches,” most likely. Better statement would be: “Beware the FUD.” For the record, nearly all ThreatX’s customers run in full blocking mode, including a global enterprise with more than 500 APIs and web apps where we field nearly 2 trillion requests per month. If latency were an issue, I am certain we would have heard that.
Will the technology require an integration with yet another product for blocking – albeit after the fact?
Most security teams today are loathe to add more point products unless necessary. In the case of protecting APIs, observability tools lack the ability to block in real time. Rather, they tend to operate in a “SIEM-like” capacity, requiring offline analysis of attack data and then integration with another tool (e.g., WAF) for future rules-based blocking.
If integration with a third-party WAF or other such tool is required for real-time blocking, then examining the respective capabilities of these products is important. In this context, legacy WAFs fall far short because these products are generally not capable of understanding complex, multi-mode attack patterns deployed today – a requirement for real-time blocking. Therefore, rules-based, after-the-fact blocking based on an IP is really the best-case scenario.
Can the technology do more than observe APIs – i.e., is that really it?
Attackers are not single threaded, and APIs are rarely the only attack surface target on their scope; web apps are often part of that mission. Take a major restaurant chain we work with, for example: attackers were bombarding both the website and APIs that power mobile apps via botnets and DDoS. With API observability only, this company would have gained data to analyze – but only related to APIs. And, neither the APIs or web site would have been able to block the complex, multi-mode attacks.
To be sure, protecting APIs is hard – and really important. For security professionals beginning or moving along a journey toward securing their APIs, I encourage you to ask these questions above – and push to make sure the technology you choose is up for the challenge at hand: protecting APIs from attackers.
Learn more about ThreatX’s API protection.
