In API attack protection, context is key. The old-school method of looking for attack signatures then swatting away threats as they emerge will not be effective against contemporary API attacks. Attackers are sophisticated, stealthy, and patient: API attacks don’t always look overtly malicious, and attackers frequently take their time, making the long view a critical defense.
How Attackers Target APIs
APIs are a two-edged sword: They expose business functionality and allow easy and powerful integration between back-end systems, but they also provide attackers with more attack surface, and through that, grant visibility into the back-end functions of an application. One of the benefits of the web front end is that users make requests, and the application handles all the plumbing internally, obscured from the user. APIs, by contrast, often provide direct access to back-end services. By reading API documentation and doing a little experimentation, attackers can gain a toe-hold, and can then map new attack surfaces. This level of access can be crucial in the early stages of an attack.
In addition, compared to apps, APIs are “under the covers,” they are intentionally “exposed” and perimeter protection solutions may not “know” about them. So they don’t have the same level of protection web sites have. Because of this, we see attacks spend a lot more time in the reconnaissance phase, poking around, trying to identify and map vulnerable assets.
These recon attacks are crafty – they begin low and slow, staying below the threshold of detection. Then they’ll stop, go idle for days or weeks. Then, they’ll reappear after a month or more, probing with more precision, almost surgically.
Then, after building a nice dossier on their target, the attack begins.
During the attack phase, almost all attackers distribute these attack vectors across tens of thousands, if not hundreds of thousands, of botnet nodes. Against defensive systems based on IP address, this allows them to cycle rapidly through attacks, but stay, from the perspective of the defensive system, low and slow, with only one or two requests coming from each node in the botnet. This tactic – staying under the thresholds of detections of traditional web application firewalls by distributing the attack across multiple IPs – lets attackers craft much broader, and longer-lasting attacks.
Why a Long View Approach Is Key to API Protection
Because modern API attacks now feature lengthy reconnaissance phases and are distributed across many IP addresses, it’s hard to identify malicious entities or networks of entities attacking an API. When only looking at one point in time, it becomes impossible. What may be normal behavior for a particular endpoint under one context would be suspicious behavior under another context. That’s where the long view comes in to play. You need to understand both the baseline of normal API behavior – i.e., how the APIs are executed on an end-to-end business flow process – and the key indicators of someone looking for an authorization or authentication vulnerability.
How ThreatX Can Help
ThreatX extends the timeline of API protection, providing real-time blocking, and also monitoring the behavior of suspicious entities over time, to detect and block mapping and reconnaissance attacks targeting APIs. ThreatX constantly monitors and learns application and API behavior for signs of attack. This includes attacker reconnaissance such as scanning the application, mapping of endpoints, fuzzing techniques, and method enumeration.
ThreatX also identifies these actions in the context of the attacker kill chain. Attackers can be detected early on in the mapping phase and then fingerprinted to track future behaviors such as progressing to brute force techniques. This context is maintained and raises the overall risk score of the attacking entity. This allows the ThreatX Platform to confidently block requests from the suspicious entity well before damage occurs to the API.
Classifying Risk
The ThreatX Platform thinks like a Security Analyst, and classifies all observed behavior in terms of risk. For instance, SQL injection or cross-site scripting attacks would be blocked on the first attempt. But if ThreatX identifies a lower-risk activity, the solution raises the risk, but doesn’t block until it has clear indicators that the traffic isn’t originating from a legitimate user.
