Zero Trust API Cloud to make public API endpoints private

APIs are exploding at 200% annual growth rates, and securing these APIs is very difficult.  In fact, Gartner predict APIs will be 2022’s most frequent cyberattack vector.  Securing APIs is difficult because:

  1. The large numbers and distributions of API clients often make it infeasible to force all the clients on to private networks using old tools like VPNs. The result is most API server endpoints are accessed via public networks, rather than private networks.
  2. Newer tools such as zero trust security clouds (Zscaler etc.) are built to secure user-application access, rather than API networking.
  3. API gateways and WAFs provide some layer 7 security, but are still exposed to attacks from the network (layers 3 and 4) which target authentication and authorization bugs, zero-days, misconfigs and side doors in complex business logic. The result is 7 of the top 10 OWASP API vulnerabilities are not addressed by these solutions, and all 10 are all exploited from public networks.

NetFoundry responded to this challenge by providing API providers with a Zero Trust API Cloud to make API endpoints and gateways inaccessible from the networks.  The solution is similar to the zero trust clouds being rapidly adopted to secure user-app access, but addresses the unique challenges which API providers face with API security:

  1. Comprehensive. Addresses all 10 of the top 10 OWASP API vulnerabilities.
  2. Enable developers. Agentless approach enables API developers to embed private, zero trust overlays in API client endpoints, as code, rather than deploying separate VPN clients for each API client (it is infeasible for large scale API providers to manage VPN clients across all their API consumers).
  3. SaaS and open source. The platform is available both as hosted SaaS, and as an open source platform for self-hosting.  A cloud-native, API-first approach is taken in both cases, enabling customers to leverage existing solutions and tooling.
  4. Simple. It is expensive and difficult to manage too many security solutions, often with multiple sets of identities and policies. The platform secures the APIs, and also secures remote management of the API infrastructure, including both admin access and CI/CD system access.
  5. Visible. The platform provides app-level network visibility to all internal stakeholder groups, and even to end-customers (API consumers).  The rich data is exposed via both web console and NetFoundry Management APIs.

Helping API providers better mitigate against the top 10 OWASP API threats

Private networks defined by ‘boxes and wires’ (network firewalls, MPLS circuits, VPNs, etc.) can’t handle the scale, distribution and dynamics of APIs.  This forced API providers to make most APIs be Public Internet facing.  This shoved API Gateways, WAFs, servers and endpoints on to a playing field which is severely tilted against them because they are force to face attacks from the entire Public Internet, and they need to win 100% of the battles.

The NetFoundry Zero Trust API Cloud flips that playing field.  It enables API providers to make it so API clients can use Internet access, but meanwhile the API provider’s API gateways, API servers and API endpoints are not exposed to the networks.  This enables API providers to better mitigate against the problems identified by OWASP as the most severe API security vulnerabilities. In summary:

  • 7 out of 10 of the OWASP top 10 API threats are not protected against by network firewalls (FWs), Web Application Firewalls (WAFs) or API Gateways (GWs). This is one reason why they are in the top 10!
  • FWs, WAFs and API GWs are helpful with OWASP #4. WAFs and API GWs are effective for a small subset of OWASP #7 and #8.
  • NetFoundry can prevent over 95% of OWASP API threats #1, #2, #7, #8, #9, #10.
  • NetFoundry reduces the attack surface by factors of 8 to over 2200 for OWASP #3, #4, #5, #6 (the 8 – 2200 range of attack surface reduction depends on how many of the attacks are from the outside, as opposed to from authorized API clients).

Since the nature of APIs often makes it infeasible for API providers to use old network security tools to limit API client endpoints to private networks, this chart compares the approaches which API providers are taking to defend their network FWs, WAFs, API GWs, API servers and API endpoints which are exposed on public networks:

Network firewall, WAF, API gateway

 NetFoundry Zero Trust API Cloud

OWASP #1 Severity API Threat: Broken Object Level Authorization
OWASP #2 Severity API Threat: Broken User Authentication
  • Network FWs only prevent attacks from known attackers, and only after their IPs are added to the ACL.
  • WAFs only work if the auth problem is previously known and widespread enough to be added to the WAF
    (usually not the case and after initial damage).
  • API GWs do not detect most auth issues.
  • NetFoundry proactively shields the endpoint which is exposing the attacked object – the vulnerability
    can’t be exploited from the networks
  • NF adds independent authentication and authorization, so the attacker needs to simultaneously break the
    API auth, NF’s API auth, and gain access.

OWASP #3 Severity API Threat: Excessive Data Exposure

When the API developer needs to expose too many object properties, or rely on the API client to do all the filtering, then none of these solutions are very valuable for authorized users.  However, NetFoundry uniquely ensures that only authorized API clients can enter, limiting the attack surface.  If an authorized API client exploits this vulnerability, then NF ‘quarantines’ and sometimes disarms the threat entirely – it can’t attack laterally, ‘phone home’, etc.

OWASP #4 Severity API threat: Lack of Resources & Rate Limiting

This can be addressed by all the solutions. NetFoundry simplifies this problem by limiting the attack surface – eliminating all the requests from unauthorized API clients which add noise for the API operators if they are only relying on the other solutions.

OWASP #5 Severity API Threat: Broken Function Level Authorization OWASP #6 Severity API Threat: Mass Assignment

If the API developer needs to implement complex access control policies, or use mass assignment to bind client data and data models without granular filtering, then it is mainly up to the developer to prevent authorized users from finding holes or modifying object properties.  The other API security solutions do not help at all for this vulnerability. NetFoundry helps by minimizing the attack surface and noise – ensuring that unauthorized attackers can’t take advantage of function level authorization issues.

OWASP #7 Severity API Threat: Security Misconfiguration
  • Network FWs are irrelevant in dealing with these misconfigurations.
  • Some WAFs or API GWs may be able to detect commonly misconfigured HTTP headers, unnecessary HTTP methods,
    or permissive Cross-Origin resource sharing (CORS).
  • NetFoundry proactively shields the misconfigured endpoint so the vulnerability can’t be exploited from the
    networks, and the developer has time to fix it
  • NF minimizes the blast radius.  If a misconfiguration is exploited by an authorized API client, and it
    results in malware which then needs use the network to do damage, NF effectively quarantines it.

OWASP #8 Severity API Threat: Injection
  • Network FWs are irrelevant in dealing with injection threats.
  • Some WAFs or API GWs may be able to detect some common injection flaws, such as SQL, NoSQL, and Command
    Injection.
  • NetFoundry proactively shields the API endpoint or gateway from the network, such that the injection flaw
    can’t be exploited from the networks, and the developer has time to fix it.
  • NF minimizes the blast radius.  If an injection flaw is exploited by an authorized API client, and it
    results in malware which then needs to ‘phone home’ in order to do damage, NF effectively quarantines it.

OWASP #9 Severity API threat: Improper Assets Management

Network firewalls, WAFs and API GWs are largely irrelevant in the context of assets management attack vectors (these debug endpoints etc. often look the same as the production API infrastructure).

NetFoundry also may not be able to differentiate between these endpoints and prod, but NF proactively shields all endpoints from network-based threats, therefore protecting against these threats.

OWASP #10 Severity API Threat: Logging and Monitoring

Network FWs, WAFs and API GWs are largely unhelpful for the management threat because they are mainly outside of the interaction between API infra and management systems.  Furthermore, those systems can amplify the problem because they don’t block unauthorized users from trying to access the API at L3/L4.  The resultant noise created is one reason why API breaches often take over 200 days to identify, and often are found by third parties rather than internal teams.

NetFoundry helps in multiple ways, including:

  • API producers extend their zero trust network to include monitoring, management and logging
    systems.  This means attackers can’t ‘move laterally’ between these systems, preventing both infection and
    spread.
  • Because NF blocks unauthorized users before they reach the FW, WAF, API GW

or API server, the amount of logs to analyze can be decreased by 8x to over 2200x.

 

NetFoundry tilted the playing field back in favor of the API providers, enabling API providers to take their API endpoints off the Internet – to leverage private API networks, while API clients could still use Internet access.

So, although private networks defined by boxes and wires can’t handle large scale API deployments, clever software can!  It looks like this:

Yes, some software (code) added to the existing API code results in the API provider being able to close all their inbound firewall ports, and instead open outbound, mTLS-secured connections towards a private API Fabric.  Let’s take a look:

  1. API endpoints (consumer and producer endpoint) are enrolled with identities integrated into a PKI. This is similar to the process used to get L7 auth tokens which In this case, the identities will be used to govern layer 3 (network).
  2. The OpenZiti SDKs enable developers to add a few lines of code to their APIs to authenticate and authorize each API session, leveraging the enrolled identities, and route authorized API sessions across the Fabric. AWS Lambda webhook example:
  3. The Zero Trust API Fabric is a private, cloud native, software defined network. Businesses can choose to use the Fabric hosted by NetFoundry as SaaS, or use the OpenZiti open source to host their own Fabric.  Only authorized sessions can use the Fabric, and both the API producer and consumer endpoints open outbound sessions to the Fabric, enabling them to close their inbound firewall ports.

Summary

Close all of your inbound firewall ports, making your API gateways, servers and endpoints unreachable from the networks:

You can learn more about Zero Trust APIs, or start now for free and have your first zero trust API up and running in less time than it takes to read this doc (if you don’t skim read):

  • CloudZiti (NetFoundry-hosted) Ziti platform
  • OpenZiti (self-hosted, open source Ziti platform
Discuss On: