Explanation of How to Expand API Security From Defense-in-Depth to Zero Trust Model

“The pandemic placed immense urgency on businesses to get all kinds of digital transformation projects live as quickly as possible, and that is almost certainly a driving factor behind this surge in attacks,”

— Peter Klimek, Director of Technology at Imperva.

DYKT APIs have been used for more than 20 years. Since then, APIs have evolved drastically — from a limited set of companies using APIs to tackle specific needs to, recently, an endless collection of use cases in DevOps environments of all sizes. APIs can be found across App Developments — agile development, connecting customers and partners with services, and powering digital transformation initiatives.

But regarding cybersecurity, according to research by ProgrammableWeb, an average of 220 new APIs have been added every month since 2019. Yet, with broader adoption, APIs expose more sensitive data today than ever, making them a valuable target for attacks.

This post is an introduction to how to map the requirements of API Security, from Defense-in-Depth to Zero Trust Model.

Background -The State of API Security

Before entering how to secure the API, let's look at the current threat landscape of API Security. According to the State of API Security Report by Salt Security:

• API Attacks Increased by 681% in the Last 12 Months
• 95% of respondents have experienced an API security incident within the last year
• 34% of respondents lack any API security strategy
• 62% of survey respondents acknowledged slowing down the rollout of a new application because of API security concerns

In short, we can tell that most enterprises are unprepared for an API-based attack. Also, reliance on existing security and API management tools, e.g., web application firewalls (WAFs) and API gateways, could have effectively prevented security incidents and provided a false sense of security.

What About Shift-Left?

The report highlights that shift-left tactics are not helping, at least on API security. Over 50% of respondents said that developers, DevOps, or DevSecOps teams are responsible for API security. Companies that spend more on pre-deployment efforts include:

• secure coding best practices,
• code scanning, and
• manual test

However, 85% acknowledged that their security tools are ineffective in API attack prevention - Proving that these DevOps security practices, while important, are not enough.

So, what protection should an organization build or adopt to defend against API attacks? To answer this question, first, we need to understand the common attacks against API.

The Current Threat Landscape

In the recent report on API security by Google Cloud, the sources of API security threats are:

1. Misconfigured APIs (40%),
2. Outdated APIs, Data, and Components (35%),
3. Spam, Abuse, Bots (34%).

According to another study by Imperva Research Labs, the most significant attack rises Remote Code Execution (RCE) or Remote File Inclusion (RFI) which jumped by 271%. Hackers use RCE or RFI attacks to steal company information, compromise servers and website defacement, or even take control of the websites.

Other API vulnerabilities are, according to OWASP API Security's top 10:

• API DDOS fan-out,
• zero-day API attacks,
• stolen credentials,
• perimeter breaches,
• lateral movement of breaches,
• data leak at the egress, or
• resource hijacking

Cybersecurity: API is the New Endpoint

As mentioned above, the first reason for the increased security risk of APIs is the explosion of adoption - many APIs in an environment. For example, a Kubernetes application has hundreds of pods and microservices. Each of them is managing half a dozen or more APIs. (That's a typical scenario in a DevOps environment).

Now add that these microservices workloads (and hence the API calls) are temporary, run across clouds, are written in a multilingual fashion, and use different protocols. Or in short, APIs create a complex environment and challenging for the security team to oversight the API operation.

Secondly, APIs were never meant to be exposed to the outside world. Yet, this is what we faced with the vulnerabilities found inside network protocol stacks. Those developers would never imagine their works would be adopted on the scale today. As a result, APIs have innate vulnerabilities and risks built within them.

Thirdly, attacks and breaches have gotten increasingly sophisticated, especially those executed in the post-authentication and authorization phase. They are also more profound within the API data payload.

Therefore, there is a need to look at security beyond authentication and authorization, also the application and API data payload layer. One way to do that is to think of API Security as analog to our traditional Endpoint security.

DiD (Defense-in-Depth), Again!

Security problems also happen in our daily life outside of computers. From the early stage of human history, various countries have been exploring and practicing multiple defense mechanisms and fortifications. These experiences and ideas also apply to endpoint, network, and API security.

Let's say Endpoint Software is analogous to the castle:

• Identity authentication is equal to the commanders' ID proof, and
• Honeypots (or decoys at war) lure attackers away from high-profile targets.
• Among these war strategies, one of the most effective ways is Defense-in-Depth (DiD).

The DiD approach can be divided into two areas:

1. Boundary Defense (Anti-malware Signatures)
2. Intrusion Detection/ Prevention (IDS/ IPS/ EDR)

I'll explain API security with these DiD areas one by one.

1# Boundary Defense

Boundary defense is the most basic type of defense. Almost all companies invest in boundary defenses. In endpoint security, we use signatures and IP denylists to defend against known attack methods.

As the front line of protection, this layer aims to stop 90% of all attacks, non-targeted and initiated by unskilled individuals who do not have solid technical know-how or a hacker mindset. In this scenario, boundary defense can resist these indiscriminate attacks well enough.

In API Security, WAF is doing an excellent job in this area. It offers standard features for boundary defense:

·         IP allowlists and denylists,

·         WAF rules engine,

·         Rate limiting, and

·         fault injection/ fuzzing.

When in combination, it can block almost all commodity attacks.

2# Intrusion Detection (++)

Security visibility is a critical element of attack prevention. After a hacker has breached the perimeter, we need a proper way to identify which file/ process/ traffic is likely related to the malicious attack. In Endpoint Software, we have host-based IDS/ IPS to inspect all requests passing through the front gate.

Some other detection methods, such as APT detection and machine learning, could be more intuitive to evaluate against targeted attacks.

Other typical ways of implementing behavior analysis are:

·         Honeypots,

·         EDR (Endpoint Detection and Response), and

·         Threat intelligence (file & process).

Among all those methods, honeypots are one of the oldest (since the beginning of wars). By luring some high-value targets into traps/ decoys, they can analyze the enemy’s behaviors and even help locatei them. Nowadays, we adopt these tactics and turn them into deception techs.

In the modern world, API security solutions provide combinations of the mentioned techniques; for example, artifacts collected in honeypots can then send into the threat intelligence feed for WAF or Web Application and API Protection (WAAP) consumption. In this layer, we have similar techniques to enhance visibility and the speed to stop an attack:

·         Network Honeypots

·         NDR (Network Detection and Response), and

·         Threat intelligence (payload & network).

Using bots to execute "credential-stuffing" attacks is another common attack tactic. It attempts to steal high-value assets. The strategy is to find a way to get login information, such as leaked emails/passwords, and then try to access network locatons in batches (lateral movement). By far, the most efficient defense to combat credential stuffing is from the source: identify the bot from real users to intercept all requests made by the bot.

As such, some AppSec tools also equip anti-bots features, a specific type of behavior detection as part of API security.

When API Security Meet Zero Trust

I am not saying DiD is useless. API and Application Security solutions such as WAF protection for organizations from commodity attacks. However, as mentioned, API creates a complex environment, and misconfiguration worsens the problem.

With an uncleared perimeter, there may need to be more than DiD approach. Zero Trust essentially puts obstacles everywhere for the attackers, making it impossible for them to move laterally within the environment.

Zero trust is a comprehensive security framework and strategy. It requires strict and unified verifying steps for all terminals, BYODs (Bring Your Own Devices), servers, APIs, microservices, data storage, and internal services.

The main idea of Zero Trust isto turn the centralized enforcement point into multiple micro checkpoints in every path of your applications, including APIs. Whether it is an internal access external request, a mobile phone or a PC, an API call or HTTP request, an ordinary employee or a CEO, none can be trusted.

To effectively achieve such a goal without stopping or slowing your applications, orchestration and automation would be the critical determining steps.

Why Orchestration and Automation are Crucial for Zero Trust API Security?

ZTA, NIST SP800–207 | Image by the author

To explain the necessity of the two, let’s take a closer look at one pillar of Zero Trust Architecture — User/ Device access trust. This defense method is similar to showing your passport at the airport checkpoint and your ID cards to purchase alcohol.

Without the corresponding identity and authority, it is impossible to enter the related system. This is where an API Gateway comes in strong, as it provides some key authentication features:

• Automatic rotation of keys
• Integrating with multiple authentication systems such as OKTA and Auth 2.0
• Support TLS and mTLS encryption of traffic

There are two core components of User and Device Trust:

• Identity and Access Management
• API Gateway with integrated security

Imagine adding identification equipment in all transportation hubs, such as airports and high-speed railways. You must also understand all the routes to and from all transportation hubs and implement safeguards.

In a large enterprise, there will be hundreds of systems, tens of thousands of APIs and microservices, and hundreds of thousands of clients. Unless we have unlimited resources and time, the DevOps, Security, or Application team can’t define and manually add hundreds of thousands of micro-identification checks in modern applications.

All the other pillars of Zero Trust Architecture, Application, Workload, and Data also require the same logic for adoption. The need is a solution that:

1. It uses modern architecture,
2. Works in heterogeneous environments,
3. Mitigates these risks (not just the commodities), and
4. Does all this in an automated manner across multi-cloud environments
5. (optional) open-source, such that to enable technology agility and creativity.

What’s the Idea Zero Trust API Security Look like?

To adopt the complex and heterogeneous environments in API, the Zero Trust API Security solution must be able to be deployed as multiple formats and thus support different settings, for example:

• Docker Container,
• A standalone reverse proxy,
• Agent for web/ application server, or
• Embedded in Kubernetes Ingress Controller.

With the support of the cloud and modern application architecture, automation and scalability would be taken care of.

But to maintain orchestration, the “agent” (or micro-enforcement point) must be able to be deployed on top of an existing application without changing existing architecture while ensuring minimal latency and maximum control.

After considering the deployment and architecture form factors, it is also essential that the security level is not degraded. To be genuinely Zero Trust adopted, security processing should be done locally without transmitting to other clouds or engines, such as a cloud sandbox for analysis.

If external parties are not in our control, verifying the Data / Network access trust is difficult. There are some other benefits of doing such locally, such as:

• Sensitive data does not leave the protected environment.
• You don’t need to share certificates and private keys with third parties.
• No dependency on 3rd party uptime for processing traffic.

The last part is to consider orchestration. Ideally, we need a solution that can infuse into the application environment while an orchestrator can manage those agents and take care of the following operations:

• agents registration/ deregistration
• policy update
• configuration update
• software update
• logging and
• Data synchronization.

In short, Zero Trusted API Security should be in various forms to infuse into modern app environments. Meanwhile, the best solution should be able to provide orchestration and all the security functions that traditional solutions can provide.

So as you know, zero trust is not flawless. Zero-trust solutions cannot fully defend against zero-day or social engineering attacks, although they can significantly reduce the attack surface and impact.

Final Words

APIs have become the central nervous system of modern applications, bringing critical information and data from one part of the application to another or from one application to another. As a result, API security should be the priority when securing applications. This is particularly true for public APIs, with users worldwide accessing software components and sensitive data.

Adopting Zero Trust Framework shifts the focus from a single safeguard to different pillars (Users, Devices, Networks, Applications, and Data). That can help you ensure that every part of API access, whether inside or outside the perimeter, is under the least privileges approach and continuously monitored.

Thank you for reading. May InfoSec be with you🖖.