API Security in a Zero Trust World
Now, more than ever, the traditional concept of a security perimeter is changing. This is leading many organizations to adopt the principles of Zero Trust architecture (ZTA), many of which focus on assessing user trust and governing access to sensitive networks, systems, and data through primary user interfaces.
However, many ZTA initiatives overlook the increased prevalence of application programming interface (API)–based access to sensitive application functionality and data as they are designing ways to assess trust on a continuous basis.
In this blog post, we'll highlight some of the points of intersection between APIs and ZTA. We'll also outline some initial steps that you can take to extend your ZTA to include APIs.
What is Zero Trust?
In 2010, Forrester Research introduced the principles of ZTA to mainstream enterprise security audiences. ZTA design has been improved greatly since then — both by Forrester and by numerous other industry stakeholders, including the National Institute of Standards and Technology in NIST Special Publication 800-207.
In simple terms, Zero Trust assumes that no user or device can be trusted by default. Instead, either should be subject to assessment every time access to a sensitive resource is attempted — and then assessed continuously thereafter.
For many years, ZTA was more of a discussion topic than something that organizations were pursuing in the real world. But the global migration of workers to their homes spurred by the COVID-19 pandemic caused many organizations to push forward with tangible plans to adopt ZTA principles.
Where do APIs and Zero Trust intersect?
The NIST SP 200-807 outlines seven basic tenets of ZTA. While these tenets encompass much more than API-based access to application functionality and data, they also have very clear points of intersection with an organization’s API strategy.
The 7 basic tenets of Zero Trust
The following table includes the seven basic tenets of ZTA as defined in the NIST SP 200-807 with recommendations for aligning your organization's API security practices with these tenets.
The 7 basic tenets of Zero Trust Architecture |
API security implications |
|---|---|
1. “All data sources and computing services are considered resources.” |
Many of the applications and data sources within the scope of ZTA are accessible via APIs in addition to direct user interfaces. Therefore, your ZTA assessment and policy enforcement model should include API interfaces. |
2. “All communication is secured regardless of network location.” |
Even if APIs are intended only for internal use within a private data center or cloud environment, you should implement encryption, authentication, and authorization as though they are externally facing to ensure data confidentiality and integrity. |
3. “Access to individual enterprise resources is granted on a per-session basis.” |
You should evaluate trust before granting access to an API resource. Access should be granted with the least privileges possible. Use behavioral analytics to monitor API usage and continuously assess trust. |
4. “Access to resources is determined by dynamic policy — including the observable state of client identity, application/service, and the requesting asset — and may include other behavioral and environmental attributes.” |
To apply ZTA to APIs, you must be able to identify the entities involved, infer business context, and use behavioral analytics to identify deviations from normal usage patterns. A behavioral attribute of note is service-denial via rapid API calls. This is why a lack of API rate limiting is categorized as Unrestricted Access to Sensitive Business Flows in the Open Worldwide Application Security Project (OWASP) API Security Top 10. As NIST notes, “These rules and attributes are based on the needs of the business process and acceptable level of risk.” |
5. “The enterprise monitors and measures the integrity and security posture of all owned and associated assets.” |
This requirement is based on the Continuous Diagnostics and Mitigation (CDM) concept defined by U.S. Cybersecurity and Infrastructure Security Agency (CISA). CDM includes elements such as asset management, vulnerability management, and configuration/settings management. Just like physical assets, APIs must be continuously discovered, classified, and tracked. Similarly, ongoing vulnerability assessments should extend beyond traditional network and application security vulnerabilities to include possible API-based vulnerabilities. |
6. “All resource authentication and authorization are dynamic and strictly enforced before access is allowed.” |
This concept can and should be extended to APIs. Organizations that adopt ZTA should perform continuous monitoring of API usage and use automated technology (e.g., block, limit, revoke credentials) to respond when anomalistic or abusive behavior is detected within authenticated and authorized API traffic. |
7. “The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.” |
To be an effective element of a ZTA, your API security measures must be capable of capturing data over extending periods — ideally, it should be sufficient time to detect subtle API abuse. This level of detail is necessary to perform behavioral analytics for both real-time risk assessment and ongoing improvements to the ZTA design. This includes providing on-demand access to API and threat data to threat hunters for use in identifying possible policy improvements. Similar integration points should also be created with the development and operational tools and workflows that your teams use. |
Take these 7 initial steps to extend your ZTA to include APIs
One of the biggest challenges for most organizations that want to adopt ZTA is deciding where to start. In the case of API security, implementing the following capabilities will make an immediate impact on your security posture while also giving you the foundation you need to incorporate API security into your future ZTA plans.
Implement continuous API discovery and maintain accurate inventory of all APIs and API-accessible assets
As unsanctioned APIs are discovered, ensure that systematic workflows are in place to either bring them into management or eliminate them
Implement sound API authentication and authorization regardless of whether APIs are public or private
Proactively identify API vulnerabilities as an ongoing discipline, starting with the OWASP API Security Top 10
Develop the capabilities to analyze large API traffic datasets to determine a baseline for normal behavior and to perform anomaly detection
Feed threat and trust insights into ZTA policy engines as they are implemented through API integrations
Initiate automated responses when API vulnerabilities, threats, and abuse are surfaced
The first step
Incorporate API security into your ZTA. See what’s possible with Akamai API Security.
