LAST UPDATED Oct 18, 2022
A Confusing Menu of Options
APIs have become a top target for cyberattackers, and for many enterprises, the variety of solutions saturating the API security marketplace can be confusing. For example, API gateways are stretching their capabilities towards security, API security pure-play vendors are advocating for their own efficacy, and WAAP platforms like ThreatX provide protection for a combination of these same problem areas. For practitioners, there’s a lot to get their heads around. To simplify things, the biggest distinction comes down to timeliness of protection – API security solutions come in two flavors: real-time, inline protection, and reactive, out-of-band analysis.
Inline protection means sitting in front of an application, inspecting and analyzing all traffic as it’s going through it.
Out–of–band analysis means monitoring a port or installing an agent to ship packet data to some back end, and then the analysis occurs after the attack has already happened.
Based on what we’re heard from security practitioners, one of these sounds like protection, the other sounds like detection.
The Disadvantages of Out-of-Band Analysis
Delayed Traffic Analysis: Not receiving traffic inline means that data will need to be integrated, copied, mirrored, or shipped to a separate solution for blocking, such as a WAF. The extra processing time for the traffic data alone will result in delays for detecting and analyzing, and by the time the decision is made to block the attacker, it will be too late.
After-the-Fact Blocking: Not having real-time or run-time protection is costly, especially when it comes to attacks like SQL injection, XSS, and zero-day vulnerabilities because it only takes one request to go through to lead to a breach. The request will be processed before the IP is blocked, leading to compromise. It’s as simple as that. Without a protection solution that sits inline, able to block attacks by request, organizations cannot stop attacks effectively.
The Disadvantages of Inline Architecture
Uptime Risk: Putting anything inline of application traffic has risks associated with it, because it’s another point of failure in the critical path. That’s one more dependency, and one more unknown to manage in the infrastructure. This disadvantage, while real, is easily mitigated through deployment planning and technical diligence, which we emphasize with ThreatX’s deployment services that comes with the platform. ThreatX runs thousands of sensors, all over the world, handling both analysis and protection of API and app traffic 24X7. We’re inline for some of the biggest B2B and B2C websites on the planet. We deploy a high-availability architecture that scales up and out automatically, while supporting multi-regional failover in case of unusually large events and provide service availability history to our customers and prospects on demand. All this gives us the confidence to say that we have the best uptime performance in the business.
If an organization has existing appliances inline of traffic flow, tool chaining, as mentioned in https://www.datacomsystems.com/chaining-network-bypass-switches/, “allows you to pass traffic through multiple inline tools monitoring the same network link.” The ThreatX Managed SOC supports onboarding and partnering with customers to ensure even complex deployments are completed fast, and effectively.
Induced Latency: We recognize that users are sensitive to even small changes in performance, and organizations increasingly expect a high degree of performance from all systems they operate. Fortunately, this is easily tested in a POC environment before production deployment. The ThreatX Platform minimizes latency by deploying censors intelligently (aka, close to origins or API endpoint servers).
False Positives: Probably the biggest fear security professionals have is the risk of false positives. At ThreatX, we agree that this is a pernicious risk. In fact, this is why we were founded! Our Attacker-Centric Behavioral Analytics provides precise analysis of risk, and our FP reduction algorithms mean that customers put us in blocking mode and never look back. And if that isn’t enough to mitigate this perception of risk, we stand behind our work, and all our customers have access to our SOC, in the unlikely event that we need to further tune our rulesets to match the business logic of customer endpoints.
Risk vs Reward
Deploying an out-of-band solution to analyze layer 7 web app and API traffic might check a box, but checkbox solutions don’t protect against attacks or stop an incident from occurring. If an attacker can be stopped before they ever gain access to an organization’s systems, then you can prevent damage or theft before it occurs. If an organization can stop attacks at the recon phase, it does not have to deal with the cost of investigating and remediating a cybersecurity incident or data breach.
When making a buying decision, teams must weigh real risk vs. perceived risk, but ultimately, the reason they started looking for a security solution is that the application layer is under attack. To us, the only option to actually stop attackers is with inline protection. Sure, we’ve got a horse in that race, but we architected the ThreatX Platform this way for a reason – to protect the web apps and APIs that run the world.
To learn more about ThreatX’s solution, contact the team to schedule a demo.
