When it comes to API security, protection typically comes as an afterthought in most security models. So, with that in mind, I’ve been championing the idea of a “protection-first” approach when it comes to API security. While this may initially sound a little bit unorthodox, let me offer a little more detail on why this approach makes sense, and how security teams can do it safely and effectively.
Why protection should come first
We often think of security as a chronological narrative. The start of the application security story often begins with application development and secure coding practices. After that, 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. It’s very much the normal narrative of how developers would build and secure a hypothetical application.
However, in a world where there are no green fields, and where attacks that target business-critical apps and APIs that already run our customers’ business are omni-present, it’s a naïve approach.
Unless the security team operates in a brand-new organization that has yet to push its first code live, the team will join a game that’s very much in progress. The exposures are already there and so are the attackers.
The “state of play” reminds me of an analogy I heard from a surgeon who likened surgery to fixing a car with the engine running. The same holds true in API security – the engine is almost always already running, and much like a doctor and patient, the team must address the immediate threats first. We have to stop the bleeding and prevent infection before we can worry about adjusting medication, taking multivitamins, or dusting off our gym equipment.
This same sort of triage applies to 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’s 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 need to balance that with the reality that training carbon-based lifeforms and actually improving their behavior takes time, with ROI measured in seasons or years. It’s also a task that requires eternal vigilance. Developers are always under pressure to deliver code quickly and eventually, security will get short shrift.
By contrast, the benefits of protection are immediate. If an attacker tries to exploit an 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’s 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 safely tackle a protection-first strategy
Hopefully, the benefits of a protection-first approach have become clear. Next, we need to tackle how we will 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, many organizations never implemented protections because of the chronic risks of false positives. Unfortunately, it’s 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.
While traditional security tools have focused on building signatures for individual malicious events, it’s important to develop a much more complete view that understands how many events come together in the context of a real attack, and ultimately the attacking entity behind the entire operation.
Security teams 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’s something glaringly obvious. Instead, security teams should function 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, the organization already 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, build a complete view of the attacker, and use that insight to drive smart, high-confidence (read “low false-positive) protections. When looking at the organization’s security, security teams should look for solutions that offer the following:
- Attacker fingerprinting: These techniques are critical to understanding the true identity of an attacker even as they rotate or change their IPs, user agents or other infrastructure.
- Attacker behavioral analysis: Build 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: Employing deception techniques 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: 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 that’s why it’s important to have an attacker-centric view.
The attacker-centric protection methods have the advantage of being fairly immediate. However, it’s important to also bring many other forms of intelligence and protection to bear that are focused on the applications and APIs themselves. Some of the important capabilities include:
- API discovery: Analyzing all traffic will help find any APIs that the team didn’t know about, such as rogue APIs that were never approved or Zombie APIs that were never deprecated. Blocking insecure APIs can offer a quick way to reduce the attack surface.
- Schema validation: Working with open API schema support allows the team to quickly verify that its APIs are 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 APIs handle data, they do not codify your business logic. It’s important to ensure that the organization’s API users hit endpoints in a specific workflow that the team defines, while ensuring attackers can’t abuse the process.
- API behavioral analysis: Learning and enforcing norms for APIs has also become a vital part of application security. The team can learn these based on previously observed API behavior, such as tarpitting queries that are causing DDoS events and overloading the application.
When it comes to API security, security teams have plenty of work to do. Start by protecting the APIs and mitigating attacks. Do it fast. Do it today. These approaches will help to keep the threats at bay while the security team safely builds for the future.
Tom Hickman, chief innovation officer, ThreatX