Why Real-Time API Threat Prevention is a Must-have?

The ability to prevent an API attack in real-time, without relying on integration with a WAF, or other tool is a must-have API security requirement. Native, or real-time API threat prevention ensures you respond to the attack as quickly and efficiently as possible. The difference between relying on a third-party and real-time prevention is like setting a signal fire to alert rescuers that you are lost vs a park ranger arriving in a Jeep to save you. Let me explain.

Imagine you are hiking and become disoriented. You’re about ready to set a signal fire to alert rescuers, when a park ranger drives up in a Jeep, offering you a ride home. Which option would you choose? The obvious choice is the one that gets you to safety most quickly. Now, shifting gears to API protection, let’s apply the same scenario.

Your APIs are under attack, and your existing web application firewalls (WAF) and other security tools cannot keep up, so you look to the wide array of API security offerings who bill themselves as being able to mitigate API attacks. Yet when many of these full lifecycle API products detect an attack, they rely on signaling another tool, most often a WAF, to initiate mitigation. This is an important, and somewhat ironic point that bears repeating. The API security offerings that came to market because WAFs are not able to detect sophisticated attacks against APIs, rely on signaling WAFs to block the same attacks that WAFs miss. Which do you want? A signal fire, or a guaranteed ride home?

History Repeats Itself

A quick review of the evolution of web app protection shows us that many of the testing and protection tools that exist today came to be some time after web applications existed. These tools were developed because web apps were being deployed with gapping security holes. Testing efforts helps reduce the number of vulnerabilities, but attacks persisted, leading to the introduction of WAFs as a way to protect your web app from a known threat using signatures. This moved protection out of development to where the attacks were targeted. Location matters when it comes to mitigation.

That same scenario exists with API security. The tools that exist today were borne out of the need to find and fix API errors sooner and the existing web testing tools could not adapt. Existing API security tools are heavily focused on the development side, which means they tend to be deployed more deeply in an organization’s infrastructure. So while they may see the end result of an API specific attack, their location within the infrastructure makes them ill-suited to take an action, requiring that they send a signal to a third-party tool (like a WAF) that is located nearer to the perimeter.

Real Time Protection Means Being Proactive – not Passive

Mitigating an attack means being proactive, responding to malicious actions immediately. Some of the more modern, AI-based WAFs are deployed in an active mode, most WAFs still rely on static signatures and rules based on vulnerability findings. The result is a high false positive rate and an equally high operational overhead to keep them in sync with application changes. This means that many WAFs are deployed in a passive mode which allows users to pass PCI and other compliance requirements but makes them unable to mitigate an attack directly. This challenge, coupled with additional management challenges and signaling delays highlights the importance of being able to see an attack in real time, and mitigate the attack in real time with policy-based actions. The Cequence Unified API Protection solution uses hundreds of predefined policies that can be enabled to mitigate attacks out-of-the-box based on a wide range of dynamic criteria including malicious infrastructure and thousands of attacker behavioral patterns.

Location Matters for Real-Time API Threat Prevention

Just as location matters when trying to be rescued, so too does it matter when it comes to mitigating an API attack. The move to an API first methodology world changed how the perimeter is viewed. WAFs are typically deployed at the perimeter, as part of a CDN (Content Delivery Network) offering or in the form of a dedicated cloud based WAF. The perimeter location dictates that all API traffic in need of protection be routed though the CDN.

The challenge arises with the fact that APIs typically generate and exchange dynamic content, minimizing the need for content caching. Rather than route APIs through a CDN, API gateways are now considered to be the new (API) perimeter. Acting as management and access control layer, multiple API gateways, sometimes from different vendors are often distributed across an organization. This means that if an API security offering detects an attack on an API, the WAF to be used for blocking may not be able to block the attack because it is not in the line of traffic. In contrast, the Cequence UAP solution integrates with a wide range of API gateways, CDNs and proxies to ingest all your API traffic to uncover and respond to attacks regardless of the location.

Real Time Protection Means Now

Much like a signal fire may mean a rescue, albeit delayed, so too does signaling a WAF with an ongoing attack. But prior to the attack mitigation conversation, there are several other areas of delay to consider.

• The first delay to consider is the effort to integrate the two solutions and validate it will function properly in a business-critical capacity. If a WAF goes down because of a faulty integration, or the connection itself fails, what is the recourse?
• Integration validation of third-party tools is time consuming and never a one and done scenario. It must happen each time the two respective tools are updated, adding to the overburdened dev team workload.
• Do the two products speak the same language? Will the WAF accept an IP address as a blocking target or is there a more involved process of creating a signature in the (typically) proprietary WAF signature language. The critical consideration here is to ensure that the detection and mitigation fidelity matches.

Finally, the process of initiating a block may be delayed by the need to manually validate the attack and any network congestion that may exist between the API security tool inside the dev environment and the WAF located at the CDN/perimeter. Real time mitigation, without the need to signal a third-party is a core feature of the Cequence UAP, enabling customers to quickly detect, analyze if needed and respond to an automated attack or vulnerability exploit.

Reliance on third-Party Signaling Impacts Efficacy and Feedback

At the end of the day, your security tools are only as good as the efficacy rates they deliver in finding and blocking attacks. Whereas known, CVE-based vulnerabilities have corresponding signatures that may deliver successful blocking via your WAF, attacks on perfectly coded APIs may appear to be legitimate traffic resulting in false positives and low(er) efficacy. To maintain high efficacy against ever changing attack, your API security solution should include predefined, yet customizable policies that can be enabled for immediate protection. These policies should be fully developed, ready to use, and be based on:

• User behaviors leveraging a threat research database of observed patterns over time
• Known malicious infrastructure and tools collected from customer environments
• Stolen, or compromised credentials as posted on the wide range of criminal repositories

While out-of-the-box, high efficacy policies are critically important, every environment and attack is different, so it is equally critical that your security team be able to view the traffic analysis and policy results to extract details and apply modifications to maintain protection. In depth analysis based on the result is not possible when your analysis is performed separately by the API security offering and your response is performed by a WAF. These capabilities are exactly what the Cequence UAP includes as part of its centralized management dashboard.

Response Flexibility Enhances Real Time Protection

There may be scenarios where you want to go beyond blocking as your mitigation response. You may want to send a deceptive response to the attacker, or respond based on a set of behaviors. This mitigation flexibility is elusive when you rely on signaling a WAF for a number of reasons including:

• The third-party solution response options may be limited to simple IP addresses and basic WAF rules, which attackers can easily bypass.
• Depending on the network architecture, the third-party solution may not see the same API traffic as your API Security solution, making it useless from a response point of view.
• The signaling provided may not include any context surrounding the attack behavior or actions, thereby forcing you to make a block or not decision.

Having flexibility in your response options is critically important to your real-time API threat prevention strategy. Simply blocking API requests is not always an ideal response as it may encourage attackers to try different methods and may not be feasible from a business point of view. For example, a business may detect a data governance issue with a business-critical API, so blocking access to that API may not be an option. The Cequence UAP solution allows you to detect and block attacks on legitimate APIs while the DevOps team develops and rolls out a fix.

Conclusion

Whether you are just starting your API protection journey, or you are deeply entrenched in an API-first methodology, on-box, real time mitigation is a critical capability that should not be overlooked. Being able to see the attack traffic, analyze it, respond, and adjust based on the results is not something that can easily be accomplished when using two different solutions, with disparate management interfaces, and possibly located in different parts of your network. Learn more about the Cequence UAP solution.