What Is ZTNA?
A key element of the Zero Trust model, Zero Trust Network Access (ZTNA) uses identity-based authentication to establish trust and provide access while hiding network locations (such as IP addresses).
With the dramatic growth in remote users, cloud systems, and IoT environments, ZTNA helps secure these distributed environments and identify anomalous behaviors. For example, ZTNA can help detect and block anomalous attempts to access applications, or attempts to download unusual amounts of data at unusual times.
ZTNA provides IT and security teams with centralized control and highly distributed IT security, tailoring access to specific applications and data based on the security context—including time, location, and device.
How Does Zero Trust Network Access (ZTNA) Work?
ZTNA takes a completely different approach to secure remote access, compared to traditional network security solutions. Unlike traditional access control solutions that provide users and devices unlimited access to the network once their identities are authenticated, ZTNA limits access to specific applications and resources. Even if the user's identity is verified, network access is denied if the device is untrusted, unsecured, or the signing attempt is suspicious.
Hiding the network from unauthorized users
ZTNA treats access to applications and networks separately. Connecting to a network does not necessarily give users access to applications within the network. This can reduce the impact of many cyber threats, including infected or compromised devices within the network perimeter.
As a general rule, ZTNA avoids exposing IP addresses to the network. By providing outbound-only connectivity, it hides the network and application infrastructure from unauthorized users, making the network topology undiscoverable.
Transitioning from MPLS to Internet-based communication
Traditional enterprise networks are based on private MPLS connections. This provided a high level of security, assuming attackers were not able to breach the network perimeter. At the same time, it limited the flexibility of corporate communications, due to the high cost of MPLS connections.
ZTNA, by contrast, can secure communications via encrypted Internet connections, not MPLS-based WAN connections. By leveraging the public internet and using TLS encryption to keep network traffic private, the Internet becomes the new corporate network. These changes enable organizations to seamlessly secure and manage a remote, distributed workforce.
Zero Trust Architecture and API Security
The NIST Zero Trust Architecture (ZTA) lists several risks that can endanger application programming interfaces (APIs) security:
- It is difficult to see all of an application's API interactions and how they change over time.
- APIs might process, send or receive sensitive data, creating the risk of non-compliance, data exfiltration, and data sovereignty violations.
- APIs can be exposed to vulnerabilities, such as the OWASP API Security Top 10, API DDoS, zero-day API attacks, credential theft, and perimeter vulnerabilities.
Mitigating these risks is critical, but also challenging, because it must be done while maintaining performance, scalability, and agility across heterogeneous environments. According to the NIST standard, there are four key considerations for incorporating zero trust into API design and usage.
Securing Users
Make sure the API user is authenticated and authorized. Zero trust treats every user as a potential threat—access to data and resources should be restricted until the account is authenticated and authorized. For authentication, mechanisms such as Security Assertion Markup Language (SAML) 2 allow users to log in to multiple services at once through single sign-on.
The most common API vulnerabilities tend to focus on authorization issues that allow API-based applications to access resources. Not all authenticated users should have access to all APIs, or all the functions within a certain API. Access control frameworks such as OAuth2 can help limit access to specific APIs and prevent unauthorized access to sensitive data.
Securing Transactions
Ensure individual API transactions are trusted, to prevent unauthorized users or devices from impersonating legitimate users or devices. To do this, you need to understand where API transactions start and end, based on observation of real application traffic. Next, you need to map traffic to the relevant users accessing specific applications and APIs.
It is important to enforce Transport Layer Security (TLS) encryption on all transactions between clients and applications to ensure an additional layer of security. Because modern applications are based on microservices, it is important to protect against internal attempts to hack into the environment, such as intercepting sensitive data or commands passed between internal microservices. TLS encryption can provide this protection.
Securing Data
Developers should be conscious of security when handling data. They must know where the data resides, what APIs can access it, and which users request sensitive information. The development team must ensure they only send and accept the necessary, authorized data, not any sensitive data the user doesn’t need.
A common practice to increase efficiency is to send more than the required data, but this implicitly trusts the user to treat the data correctly. It is important to be more selective with the sent and written back—this is especially important when storing user data in a SaaS application because data privacy regulations require protecting sensitive data at rest and in transit. Data must also be traceable from end to end.
Securing Monitoring
You cannot trust that users will not abuse your APIs. Attackers are increasingly exploiting business logic, so it is important to identify and block such attacks by monitoring and analyzing user behavior and API transactions.
Monitoring the whole application from end to end should cover all the application’s touchpoints. It involves collecting metadata and telemetry that provides a comprehensive view of the application, its behavior, and the structure of the business logic. This information provides a baseline that enables the detection of behavioral anomalies. Unusual API usage often indicates an attack or data exfiltration attempt.
I hope this will be useful as you adopt next-generation technologies to help combat API threats.
Top comments (0)