NIST Zero Trust Security Model: What it Means for API Security
Zero Trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources. A zero trust architecture (ZTA) uses zero trust principles to plan industrial and enterprise infrastructure and workflows. Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned). Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established. Zero trust is a response to enterprise network trends that include remote users, bring your own device (BYOD), and cloud-based assets that are not located within an enterprise owned network boundary. Zero trust focuses on protecting resources (assets, services, workflows, network accounts, etc.), not network segments, as the network location is no longer seen as the prime component to the security posture of the resource
How Corsha Helps
By giving its users the ability to authenticate every API call, Corsha abstracts away the security vulnerabilities of relying on API secrets and PKI as implicit trust granted to assets based on asset ownership. In MFA speak, these are simply ‘the things we have’.
INTRODUCTION
This complex enterprise has led to the development of a new model for cybersecurity known as “zero trust” (ZT). A ZT approach is primarily focused on data and service protection but can and should be expanded to include all enterprise assets (devices, infrastructure components, applications, virtual and cloud components) and subjects (end users, applications and other nonhuman entities that request information from resources)
How Corsha Helps
We are on a mission to elevate machines as first class citizens, and all of the machines communicating across APIs or the service accounts that applications leverage in order to communicate with APIs.
ZERO TRUST BASICS
The system must ensure that the subject is authentic and the request is valid. The PDP/PEP passes proper judgment to allow the subject to access the resource. This implies that zero trust applies to two basic areas: authentication and authorization. What is the level of confidence about the subject’s identity for this unique request? Is access to the resource allowable given the level of confidence in the subject’s identity?
How Corsha Helps
Corsha ensures an API request is valid by authenticating every API call that is made. By creating a cryptographically verifiable, dynamic identity for each machine, enterprises have that utmost confidence in the identity of the non-person entities they are communicating with across their API, whether that NPE is within or outside of their network.
TENETS OF ZERO TRUST
Section 2.1(1)
All data sources and computing services are 'resources'; this includes 'multiple classes of devices'
How Corsha Helps
Corsha helps secure machine to machine communication - and those machines could be pods, containers, servers, virtual machines, microservices, IoT devices and physical machines.
Deployment Scenarios/Use Cases/Multi-cloud/Cloud-to-Cloud Enterprise
Sec. 4.2
For cloud-to-cloud, need a gateway to enforce ZTA as access point; ZTA implementation may be different for each cloud provider
How Corsha Helps
Corsha provides a proxy as an access point and can also integrate with other API gateways like Kong, Apigee and Mulesoft.
Threats Associated with ZTA/Use of Non-person Entities (NPE) in ZTA Administration
Sec. 5.7
AI and other software agents are deployed on a network "in lieu of a human [admin]"; "The software agent may have a lower bar for authentication (e.g., API key versus MFA)…"
How Corsha Helps
The more we automate tasks in lieu of a human admin, risk shifts from human entities to non human entities. We focus on machine (NPE) to machine (NPE) communication in an automated, humanless fashion. Our platform allows enterprises to assign, rotate and manage NPE identities and securely authenticate all of the requests between them via agents. And we’re raising the bar on the zero trust architecture standards but adding MFA to that API communication instead of relying on API keys.
Threats Associated with ZTA/Use of Non-person Entities (NPE) in ZTA Administration
Sec. 5.7
"There is … a risk that an attacker could gain access to a software agent's credentials and impersonate the agent when performing tasks."
How Corsha Helps
Because the underlying identities are dynamically generated and frequently rotated, as are the one-time use API credentials, the ability to impersonate the machine (NPE) or the agent that is running it is impossible. Our cryptographically verifiable identity and authentication platform has no single point of failure and immediately prevents the exploitation of software agents
Steps to Introducing ZTA to a Perimeter-Based Architected Network/Identify Actors on the Enterprise
Sec. 7.3.1
ZTA requires knowledge of "enterprise subjects"; "Subject could encompass both human and possible NPEs, such as service accounts that interact with resources."r
How Corsha Helps
Corsha creates dynamic identities for each NPE, and therefore organizations can easily manage all of the NPE subjects touching your APIs, as well as the surface accounts that run on them.
Steps to Introducing ZTA to a Perimeter-Based Architected Network/Identify Assets Owned by the Enterprise
Sec. 7.3.2
ZTA requires cataloguing all enterprise assets, including their configuration; be able to "configure, survey and update enterprise assets, such as virtual assets and containers"
How Corsha Helps
Corsha provides full visibility and control over an entire inventory of API clients that are communicating with your services.
