Recently, I’ve been championing the idea of a “protection-first” approach when it comes to API security. If you missed it, I’d recommend checking out API Security Checklist: Five Standards for Protecting APIs as a bit of background. A protection-first approach may initially sound a little bit unorthodox. After all, protection usually comes later on in most security models. So, with that in mind, I wanted to provide a little more detail on why a protection-first approach makes sense and how it can be done safely and effectively.
Why Protection Should Come First
We often think of security as a chronological narrative. The start of the application security story begins with application development and secure coding practices. After that, maybe we move on to building an inventory of all APIs and assets, then scanning for vulnerabilities, then monitoring for health and security issues, and ultimately protecting against threats. This is very much the normal narrative of how a hypothetical application would be built and secured.
But in a world where there are no green fields, and where attacks are omni-present, targeting business-critical apps and APIs that are already deployed and already running our customers’ business, that approach is naive.
Triage the Patient
Unless you are a brand-new organization that has yet to push its first code live, then we are joining a game that is very much already in progress. The exposures are already there and so are the attackers.
It reminds me of an analogy I heard from a surgeon who likened surgery to fixing a car while the engine is running. The same is true in API security; the engine is almost always already running. And much like a doctor and patient, we have to focus on the immediate threats first. We have to stop the bleeding and prevent infection before we can worry about adjusting medication, taking multi-vitamins, or dusting off that gym membership card.
This same sort of triage applies to our APIs as well. By securing existing APIs from the immediate threats, we can buy ourselves the time to address the many root-cause issues upstream.
Avoid Getting Bogged Down
There is a lot to be said for solving problems at their source. I am a huge advocate of continuously teaching developers secure coding practices and proactively auditing all code for vulnerabilities. It’s incredibly important and necessary work. But we always have to balance that with the reality that training carbon-based lifeforms and actually improving their behavior is a very slow process, with ROI measured in seasons or years. It is also a task that requires eternal vigilance. Developers are always going to be under pressure to deliver code quickly, and eventually, security will get short shrift.
By contrast, the benefits of protection are immediate. If an attacker is trying to exploit a SQLi vulnerability in an API, it makes sense to stop that attempt in real-time before going back to fix the source code. In any complex process, there are steps that are faster than others. But with security, there is no need for the entire process to run at the speed of the slowest component. Mitigation – the immediate relief of protection – can once again provide air cover for remediation: those slow, long-term fixes that go all the way back to the IDE.
How to Tackle Protection First Safely
Hopefully, the benefits of a protect-first approach are becoming clear. Next, we need to tackle how we are going to implement protections safely and without impacting valid application functionality. For those with any long-term AppSec experience, this may sound like the most daunting part of the whole conversation. After all, when it came to their WAFs, many organizations never implemented protections at all due to the chronic risk of false positives. Unfortunately, this is a real concern in the industry because API gateways and old-school WAF vendors have simply ported over the same basic ModSec regex-based signatures to run in front of APIs.
The good news is that ThreatX takes a very different and far more effective approach.
Attacker-Centric Protection
While traditional security tools have focused on building signatures for individual malicious events (e.g., code injection, CSSRF), ThreatX builds a much more complete view that understands how many events come together in the context of a real attack, and ultimately the attacking entity that is behind the entire operation.
You can think of the traditional approach as a security guard checking IDs as visitors enter a building. He doesn’t know anything about a given visitor’s history, and can only detect a problem if there is something glaringly obvious. ThreatX works more like an automated investigation of an organized crime ring, where all the members are constantly tracked even as they change their appearance. In this analogy, even when a criminal arrives at the door with a fake ID, ThreatX knows who the attacker really is, all of the attacker’s history, who they work for and all the crimes they’ve committed, whether they were prosecuted or not.
Instead of making simple yes/no decisions on limited information, ThreatX builds a complete view of the attacker, and uses that insight to drive smart, high-confidence (read low false-positive) protections. At the core of the ThreatX Platform, we use a variety of proprietary techniques to make this possible in the context of API protection:
- Attacker fingerprinting: First, ThreatX has developed a suite of highly advanced fingerprinting techniques including but not limited to TLS fingerprinting. These techniques are critical to understanding the true identity an attacker even as they rotate or change their IPs, user agents, or other infrastructure.
- Attacker behavioral analysis: ThreatX also builds highly detailed profiles of every attacking entity. This can include fingerprints as well as detailed behavior maps that track attacker tactics, techniques, and procedures (TTPs) over time.
- Attacker deception: ThreatX can also employ deception techniques that can reveal the presence of an attacker. For example, an attacker that interacts with a fake endpoint or service can easily reveal an attempt to enumerate the endpoints of an API.
- Full-context enforcement: ThreatX automatically builds a complete view of the total risk to an API based on all events and history of the attacking entity. While many tools will claim to do a correlation of multiple security events, those efforts are useless without the ability to keep track of the attacking entity. Attackers continually change to hide their identity, and this is where having an attacker-centric view is absolutely essential.
Application-Centric Protections
The attacker-centric protection methods discussed thus far have the advantage of being fairly immediate. However, it is important to note that ThreatX brings many other forms of intelligence and protection to bear that are more focused on the applications and APIs themselves. Some of these techniques edge into the latter stages of the API Security Five Steps. Some of the key capabilities include:
- API discovery: By actually analyzing all traffic, ThreatX will help you find any API that you didn’t know about, such as rogue APIs that were never approved or zombie APIs that were never deprecated. Blocking insecure APIs can be a quick way to reduce your attack surface.
- Schema validation: ThreatX works with your Open API schema support and allows you to quickly verify that your APIs are actually working the way that they are supposed to and aren’t handling data that they shouldn’t or haven’t implemented any undefined or unspecified functionality.
- Business logic enforcement: While the schema is great for defining the syntax of how your APIs handle data, they do not codify your business logic. ThreatX steps in here with flow-based analysis that can make sure your API users hit endpoints in a specific workflow that you define, while ensuring attackers can’t abuse the process.
- API behavioral analysis: ThreatX can also learn and enforce norms for your APIs. This could be learned based on previously observed API behavior such as tarpitting queries that are causing DDoS events and overloading the application.
Always Have a Swim Buddy
I want to make it clear that this is not a case of someone spouting high-minded ideals that you should undertake. This is an approach that we take together with our clients and partners. ThreatX is very unique – we don’t nickel-and-dime our customers with pay-by-the ticket support models. Every customer gets access to our 24×7 SOC. This is a highly experienced team of experts who block and disrupt attacks targeting APIs, all day every day.
ThreatX customers also have global access to all of ThreatX’s attacker-centric intelligence. For example, if you start seeing suspicious activity on an API, not only can ThreatX proactively identify it, but it can know that it is tied to the same attacker that has been observed performing credential stuffing against other applications in your same industry.
So it is important to know that you can take a protection-first approach aided by a team that does it successfully every day for real-world APIs and applications.