API Security: Real-Time Blocking or Detection and Response?
The API threat landscape is evolving rapidly. New uses of APIs are emerging. Transaction volumes are ever-increasing. And of course, threat actors are always finding new ways to outsmart even sophisticated API security measures.
This is forcing the teams charged with protecting APIs to make strategic trade-offs between two competing objectives: immediacy and accuracy.
The limitations of real-time blocking
Many security products, for example, web application firewalls (WAFs), bot mitigation, and first-generation API security approaches are optimized for immediacy. They operate inline or through direct integrations with applications. This makes it possible to both see and block known (seen before) attacks in real-time.
But the word “possible” is where the problem lies. Real-time blocking can generally only be performed using traditional attack signatures. And while there is some value in being able to take an immediate response, there are also a number of significant limitations. Let’s take a closer look:
Limitations of real-time blocking: a closer look
Two approaches to real-time blocking
- Recall where network security devices are and how they block: First-generation and App-Layer Firewalls, Web Application Firewalls and the like all use signatures to identify threats and attempt to recognize threats on a per-packet basis.
But what’s the problem?
As networks evolve and API growth explodes, we see that B2B network connections don’t have traditional network security devices in front of them. So, all things being equal, if those devices are on the network, they can’t protect APIs if they’re not in the path!
Force-fit to solve a problem they cannot solve?
If a traditional network security device is force-fit into the API traffic path, if it even has the required signature, it can only permit or block traffic on a single-request basis. Lacking historical data, such devices lack context about a chain of API requests. Lacking context, real-time blocking can produce both false positives and false negatives, resulting in a high volume of alerts. The boy who cried “WOLF”: with too many alerts, organizations experience the risk of alert fatigue.
- API-specific software sensors are a different form of inline blocking. Software sensors are typically deployed within the software processing the APIs. Sensors face the challenge of shadow APIs. This refers to APIs deployed rapidly, by, for example, a business unit with a crucial new use case. Shadow APIs won’t have the sensors and can’t be protected.
Some big API threats don’t look like attacks
A crucial nuance of API security is that many threats don’t attempt to exploit a security weakness or vulnerability. Rather, API abuse is a critical attack vector that many API security approaches miss. API abuse doesn’t look like an attack. Instead, threat actors use standard API capabilities in unintended ways that cause harm. Since these activities often look like legitimate behavior, it is nearly impossible to stop them with attack signatures.
Attack signatures are susceptible to false positives
Sophisticated attacks often extend well beyond the scope of a single API request. While blocking an attack at “request zero” is highly desirable, there is rarely enough context to do it with a high degree of accuracy. And in the case of APIs, false positives can equate to business process disruption, alert fatigue, and a waste of your security team’s time.
Every API is different. Do signatures work?
In other areas of security, it is possible to source attack signatures that provide a foundation for your organization to build on. There is much less opportunity to do this in API security. API implementations are generally unique to a specific application or organization. At a time when most organizations are still struggling to discover all of the APIs in use across their business, creating custom attack signatures – and keeping them up to date – may be impossible in the real world.
XDR for API Security?
To overcome the limitations of the real-time blocking solutions above, consider the modern world of detection and response. Neosec brings the technologies eXtended Detection and Response (XDR) to API security. What does that mean?
A more complete picture of API activity
EXtended API Activity Collection – Discovery
Rather than limiting coverage to specific gateway choke points – or requiring proactive integration of sensors for each protected API – the Neosec platform collects API activity from all available sources of API activity information, including API gateways, WAFs, cloud providers, orchestration tools, reverse proxies, content delivery networks (CDNs) and network mirroring. The platform discovers APIs that aren’t known to IT security, known as shadow APIs. The API Security industry calls this process discovery. Next, the broad swath of API traffic collection points enables the Neosec platform to enrich the API traffic data with supporting details and business context.
Detection of hidden API threats – Advanced analytics and AI
With the broader view of API activity – enabled by cloud scale – Neosec analyzes data sets that span a time horizon that is several orders of magnitude longer than a WAF seeing a single request. The time horizon establishes a baseline of API behavior so that behavioral deviations can be rapidly detected.
Responding to API Threats: Taking action
Inline promises immediate action, and, of course, associated alerts and notifications, but inline is burdened by business-disrupting false positives and negatives.
The Neosec platform allows you to create a remarkable range of responses to the detection of vulnerabilities and abuse. You can create unique automated responses based on multivariable rules that arise from knowledge of each API Tag and value. Response options include:
- Block traffic at supported API Gateways and CDN edge filters
- Email notifications for security and business stakeholders
- Ticket creation for developers
- Trigger Webhooks
And many more.
It is not a contradiction for Neosec to block traffic using inline devices which block on single packets, because when API abuse is detected at 2AM after deep analysis and long time horizons, it’s still possible to stop the abuse immediately on an inline device! That is, if the online device is in the API traffic data path!
Beyond XDR for API Security
Another benefit of collecting and analyzing large data sets is the ability to analyze historical API activity. So in addition to responding more accurately in the moment when attacks or abuse are in progress, your security team can conduct proactive threat hunting activities. This allows you to find and resolve threats before they escalate into business-impacting security incidents.
Get started today
In addition to bringing accuracy and depth to your API security efforts, modern, SaaS-based API security platforms like Neosec are easier with which to get started. Register for a free trial to bring greater clarity to your API security and see the results in minutes.
*** This is a Security Bloggers Network syndicated blog from Blog authored by Eric Wolff. Read the original post at: https://www.neosec.com/blog/the-api-blindspot-2
