How to take a layered approach to API security

We need a new model for thinking about securing APIs. The answer may lie in medieval castle design.

A popular fairy tale told in IT circles is that the internet is built on a perfectly orchestrated 7-layer stack. A popular extension of this notion is that enterprises can secure their infrastructure using a layered approach to security. Like most fairy tales, there is some truth in these stories.

IT managers may run into problems, however, if they attempt to apply these models outside of a very generic context. And the context, particularly as it relates to security, has changed dramatically with the broader adoption of APIs.

A new model of a layered approach to API security is required to provide the highest level of protection at a minimal cost.

What is a Layered Approach to Security?

The ideas behind a multilayered approach to security originated from military strategy. Armies realized they could dramatically boost overall security by providing multiple types of defenses that complemented each other rather than investing too much effort in any one measure. These core ideas date back centuries.

I recently visited York Castle in the city of York, UK, which is famous for being one of the oldest fortresses in Europe. The town sits on a hillside between two rivers, making it an ideal place to build a secure enclave to protect a large army. The Romans housed almost 6,000 troops there in ancient times, and the fortress made it easy to rest them between military campaigns.

One of the things that struck me was how short the actual wall was. Having never seen an ancient castle, I was expecting some imposing 50-foot wall. But it was only about 7-foot tall in some places. A marauder could almost jump over it if he climbed up on someone’s back. Or maybe a bunch of them could climb a ladder. But then they would have had to wade through the moat, bring the ladder up the hill, and set up the attack while defenders poured hot oil and shot arrows at them.

The upshot is they could defend the city effectively using such a short wall by providing different layers of defense that complemented each other. Building a taller wall would take a lot of time and cost a lot of money but would not necessarily have provided better protection against some kinds of attacks.

The modern digital equivalent is to inventory the different types of security threats and then architect security levels accordingly. For example, a firewall is excellent at protecting an older database from SQL injection. But it will stumble when trying to protect against a large-scale denial of service attack that floods the application with malicious packets. Thus, enterprises often provision botnet protection services that can defend against the most significant attacks far more efficiently at the network layer.

There are many variations in the security layers, which seem to coalesce around seven design elements. At first glance, it may seem these are handed down by sage security experts that fundamentally understand these issues better than everyone else. These probably have more to do with the fact that humans seem to like seven gradations or sequences of things, as cognitive psychologist George Miller observed in 1956.

Many of these attempts align with the Open System Interconnect model for IT systems first proposed by the International Standards Organization. But that model never really made it out the gate, so its value in explaining security is not entirely clear. The TCP/IP model, with only four layers, played a more significant role in growing the internet. But it is essential to keep in mind that both models were conceived to explain how to improve network efficiency, not to protect them.

One of the most comprehensive efforts to align TCP/IP model with security layers was a 2002 SANS Institute analysis that aligned eleven types of security with the four TCP/IP layers:

• Link-layer – Physical security and media access control layer filtering
• Network layer: Firewalls, access control lists, virtual private networks
• Transport layer: TCP, UDP, and SSL
• Application layer: Application proxy firewalls, host-based firewalls, anti-virus scanners

More modern attempts to model security layers generally include seven layers with subtle differences in the specific elements, a nod to Miller’s insight. Here is one popular example:

1. Physical security
2. Identity and access
3. Perimeter
4. Network
5. Compute
6. Application
7. Data

Models such as these may help explain to the boss why your team needs to invest in better security cameras for the data center or the value of protecting data in transit and at rest. But it leaves a lot of gaps when it comes to safeguarding APIs, which represent one of the fastest-growing threats. And a layered approach to API security will become more critical as enterprises place more valuable assets and operations behind APIs.

Models like these leave a lot of questions unanswered.

• What exactly needs to be protected when web and mobile applications assemble an experience pulled from dozens of serverless apps, microservices, SaaS providers, and third-party data?
• How does the rise in business logic attacks and software supply chain vulnerabilities fit into this model?
• Why is data always at the lowest rung of these models — what about protecting against unwanted behavior or protecting physical things that APIs control?

As statistician George Box observed, “All models are wrong, but some are useful.”

Rethinking API Security Layers

The security industry needs a new model for thinking about the best approaches for securing APIs. A helpful model for securing APIs should clearly explain how different layers of security can complement one another to improve overall security with the minimum cost.

When thinking about API security, it may be helpful to leave out things addressed at the systems and infrastructure layers where the most focus has been for the last several decades. With APIs, security teams need to consider the code, software, and their behavior. One way of framing some of the different security layers specific to API security is to consider the following:

1. Software supply chain
2. API management
3. Authentication and Authorization
4. Inventory
5. Observability
6. API analytics
7. Forensic analysis

One caveat: This model does not include layers that neatly stack on top of each other. This reflects the fact that protecting APIs is not like protecting a castle wall. API infrastructure is composed of a complex coordination of multiple systems, and security vulnerabilities can emerge in how these pieces are integrated and work together. A more practical consideration is how the security benefits of each of these types of capabilities can complement one another to improve overall API security.

Let’s walk through this model in more detail.

Software supply chain

Increasingly, adversaries are finding ways to insert malicious code into open-source libraries used for building applications and services. Mitigation strategies include implementing a software bill of materials, analyzing code at deployment, and generating ongoing vulnerability alerts.

API management

Early API management gateways standardized various processes for monetization, analytics, documentation, and controls. As enterprises started decomposing monolithic apps into multiple, more sophisticated API gateways added support for protecting sensitive data, monetizing usage, rate limiting, and security policy management.

Authentication and Authorization

It is crucial to establish a chain of trust that connects users, APIs, and data. Teams need to consider the infrastructure that authenticates users or systems, authorizes transactions on their behalf, and shares secure tokens validating these requests. One popular approach is combining OAuth 2.0 for authorization, OpenID Connect for authentication, and JWT to implement the encrypted tokens.

Inventory

Even when APIs are implemented using best practices at the time, zombie APIs pose a security vulnerability if they are not retired at the end of their useful life. In other cases, well-meaning developers may implement shadow APIs outside the standard governance mechanism. API discovery and inventory capabilities are required to identify and protect APIs that might otherwise fall outside the purview of traditional API management tools.

Observability

Traditional API management tools tend to function as a gateway to protect against unauthorized access. Modern API observability tools can look at what happens within APIs that may cross many services. For example, this can help identify when API endpoints handle sensitive data.

Analytics

It is also essential to analyze observability data to identify more sophisticated attacks that might occur at the business logic layer of APIs. This can help identify and block attacks when a series of requests does not necessarily violate any hardcoded rules but also does not seem to serve any legitimate process.

Forensic analysis

After a new kind of attack has been detected, teams should investigate the root vulnerabilities. This investigation also needs to identify the kill chain that allowed a particular attack to escalate. Forensic analysis capabilities can help make sense of what allowed an attack to occur and support teams in identifying changes to APIs and associated infrastructure that can mitigate similar attacks in the future.

Connecting the Layers

One thing to keep in mind about a layered approach to API security is that it works better when these different layers can talk to each other. This is like making it easy for someone on the castle wall to ring for archers and hot oil when they see marauders approaching. The modern variant are tools like Traceable that can share data across inventorying, observing, analyzing, and forensics processes. This means that teams can improve each layer of security and improve the coordination between them as well.

About the Author

George Lawton is a technology writer and regular contributor to The Inside Trace.