API series - NetFoundry: The tug of war between API access & security

This is a contributed piece for the Computer Weekly Developer Network’s API series written by Galeal Zino in his capacity as co-founder and CEO of NetFoundry – the company is the originator and maintainer of OpenZiti, the an open source zero trust networking platform.

Zino writes as follows…

APIs are now the number one attack vector, according to Gartner. The problem is getting worse as the number of APIs deployed is trebling every year.

There are three sets of reasons why APIs are difficult to secure:

Firstly, APIs need to be easily accessible to be useful. API clients are numerous, distributed and dynamic. Trying to force all those clients to use VPNs or MPLS circuits, or define firewall ACL rules for all of them, would be anything but ‘easily accessible’. Hence, most API endpoints are accessible from anywhere on the Internet.

Second, in other similar cases, zero trust clouds have come to the rescue. Unfortunately, most zero-trust security clouds, such as Zscaler, secure user-application access, not API networking.

Thirdly and fortunately, API gateways and web application firewalls (WAFs) provide layer 7 security. However, they are still exposed to attacks from the network (layers 3 and 4), unless the clients are on a private network. As we’ve already established, they’re unlikely to be. That leaves attackers free to target authentication and authorisation vulnerabilities, zero-day exploits and misconfigurations from the Internet. In more specific terms, these address or partially address three of the top ten API vulnerabilities identified by Open Web Application Security Project (OWASP).

What to do?

So, what can we do about the remaining holes, as identified by OWASP? Solutions like NetFoundry’s Zero Trust API Cloud fill in the missing layer of network security. This is a Zscaler-like approach, but for APIs.

This whitepaper shows specifically how a zero trust API cloud addresses each OWASP top then threat.

The resulting solution can address about 90% of the OWASP list, with the exact range depending on two main variables: how many attacks are external versus from authorised API clients, and the nature of the attacks.

The trillions of dollars of cybersecurity damage per year tells us that we can’t secure networks without defeating their purpose – the free flow of applications and data for legitimate uses.

Zino: put the secure network inside the app or API,

The new alternative is to put the secure network inside the app or API, such that the network doesn’t exist until after it has been fully authorised…and make that paradigm as simple as public networking.

This is the ultimate result of the new “shift left” trend, and puts the development team in the driver’s seat, freed from the shackles of bolted-on approaches such as firewall rules, VPNs, port forwarding, IDS/IPS and proxy configurations.

Five factors

There are five things a zero trust API Cloud should do for developers:

Enable them to simplify and strengthen API security. Enable all inbound ports to be closed – inbound firewall rule of default: deny. In the outbound direction, the API endpoints can only talk to their private API cloud.
Enable developers to shift left to make it simple for API clients to consume the APIs. Embed private zero trust overlays in API endpoints without the need to install separate clients or firewall entries for each API client
Provide developers with security and networking functions so that the developers don’t need to build from scratch – including mutual TLS (mTLS), secure enrolment including PKI infrastructure and key management; certificate identities; optimised network routing and management functions.
Provide developers with flexibility. For example, NetFoundry provides both open source (OpenZiti zero trust networking platform) and a managed OpenZiti offering (Zero Trust API Cloud, including NaaS).
Provide developers with better visibility – API producers need simple, application-level visibility of the network, and may want to make the same web console and management APIs available to customers (API consumers).

Private networks defined by boxes and wires (network firewalls, MPLS circuits, VPNs) can’t handle the scale, distribution and dynamics of APIs.

However, this means API gateways, WAFs, servers and API endpoints face attacks from the entire public Internet.

Now we can add in the missing layer – private API clouds that take API endpoints off the Internet, while allowing API clients to continue to use Internet access.

Some think of this as embedding a zero trust Cloud inside the API, as code… and all benefit from the unique combination of simple and secure.