Secure APIs Using Artificial Intelligence

Digital Transformation is built on APIs that drive a new operating model that provides direct access to business-logic applications and data.

While this access is invaluable for employees, partners, and customers, it also makes APIs an attractive target for hackers & botnets. With a growing number of attacks and increased API vulnerability, expanding security is now becoming more and more important.

Existing solutions (e.g. Access Controls, Rate Limiting, etc.) provide basic protections but are not enough to completely deter hackers. Today's security teams need to recognize and respond to dynamically changing attacks that are designed to exploit the unique vulnerabilities of individual APIs. Looking to Artificial Intelligence to detect anomalous behavior on APIs and unexposed data, automatically block attacks on entire API infrastructure, and design self-learning solution is the future of security. This approach provides deep visibility to IT infrastructure and empowers security teams to act immediately when malicious behavior is recognized.

API Breaches

In 2019, the largest property valuation firm in Australia, LandMark White, had an API breach that resulted in leaking property valuation details and customer information. In this case, an API originally intended for internal use eventually became accessible from outside the company's domain. 

The vulnerabilities resulted in breaches of varying severity, including account takeovers, theft of private information and photos, and the extraction of credit card numbers. In the wake of the breach, the firm’s high-profile reputation was damaged, as customers and banking partners scrambled to look for alternatives.

All of these took weeks or months to detect. Other similar breaches have taken almost a year to fully resolve. Many others are still in progress right now. To understand how to protect against these threats, we must first understand the underlying vulnerabilities that APIs present.

API Vulnerability 

Many enterprises are currently relying on inadequate security measures to protect their APIs. While API management tools provide an important set of security features, including authentication and rate-limiting, these practices often stop short at stopping attacks that are built specifically to breach APIs and the data and systems to which they provide access.

Incomplete and Missing Validations 

Missing entitlement checks are a recurring vulnerability pattern in a number of recent API breaches. These missing entitlement checks are leaving vulnerabilities exposed in production APIs. In some cases, a complete lack of access control has left APIs wide open, making it possible for bad actors with basic skills to gain access for malicious purposes.

In the cases of Facebook, USPS, and Verizon/LocationSmart, hackers used a valid account to reverse engineer the API behavior to identify at least one vulnerability that would provide access to data from another account without the proper credential check— all the while looking like a normal user. This technique has the potential to deliver access to a large number of accounts and has been used successfully to breach banks and insurance companies.

Such vulnerabilities are not exposed when using the application calling the API. The malicious access is gained by skipping the client-side app (a web app, for example) and calling the API directly to observe data and control flows. Client-side apps greatly limit the way that an API can be used through user interface restrictions. Relying on the app can create security blind spots, particularly when testing is not performed outside of the app at the API layer.

In addition to access control, API security must also include content validation. This lack of security maturity is evident in the case of the Kubernetes’ API server which was discovered (and patched) in early 2019. Users that were authorized to make patch requests to the Kubernetes API server could also send a specially crafted patch that consumed excessive resources during processing, incidentally (or purposefully), causing a denial of service (DoS) attack on the API server.

This type of vulnerability is leveraged to dramatically disrupt a service. The Kubernetes API server fix includes returning 413-type errors if the incoming JSON patch contains more than 10,000 operations. This type of content validation is easily configured in API gateways, yet it’s often missed because doing so requires going beyond auto-generated JSON schemas that only define simple rule types, require human intervention to recognize the need for specific validations, and ensure proper configuration and testing.

Proliferation and Lack of Visibility

The proliferation of APIs only adds to their vulnerability. APIs are being deployed faster than ever and by many different teams. In some cases, the ongoing pressure to innovate, reduce friction, and create new revenue streams has the unintended effect of opening cracks that APIs can fall through.

It’s not surprising then that many stakeholders report a lack of visibility across all APIs deployed by their organization. The fact that many API related breaches have gone undetected for months — and sometimes years — further illustrates this lack of visibility on overall API traffic.

Furthermore, some APIs are not meant to be public and may be considered little more than implementation details of an overarching project. This keeps them hidden from the perspective of security practitioners and, in turn, leads to a lack of specific security considerations. In other cases, APIs emerging from different parts of an organization may leverage heterogeneous platforms and inconsistent security policies.

Regardless, these APIs could be just as vulnerable as their public counterparts because they are just as susceptible to being reverse-engineered by hackers. To close these gaps, we need a clear understanding of what needs to be secured. Deep insights into API traffic provide the starting point for improved cyber resilience.

Thinking Beyond Token Validation 

Validating a token and authenticating a requesting user’s identity is often not sufficient for API infrastructure protection. The ability to apply granular access controls at the API layer is not only logical, but it will become the norm as APIs become the most common channel for accessing the data developers need to govern.

Additionally, rules that define what data should be allowed for individuals to request are not only defined by the API provider but also by end-users. During OAuth handshakes, for example, we ask end-users to make consent decisions. These decisions allow users to limit the ways in which applications act on their behalf when it comes to data they own. The management of user consent is therefore tightly connected with core API security concepts.

At the heart of foundational API security preparedness is the definition of review and governance processes that bring all of these concepts together. New or updated APIs must go through a review which starts with identifying answers to questions including:

• What permissions are required to access the API?

• Who are the expected requesters?

• What databases and data will this service leverage to read and write?

• What other services will this API interact with?

• What do input and output parameters look like and how should they be restricted?

Answers to these questions will inform which security policies should apply to the new API being published

Extending Past Foundational API Security 

Even with the right foundation in place, security is only as strong as its configuration. When configuration is subject to human error, the risk of an API vulnerability making it past testing and into production increases as the complexity of the API layer increases. Even if you’ve done everything right to prevent a breach, you can still be at risk of vulnerabilities exposed on a different vector beside the API itself.

For example, hackers often steal tokens through phishing attacks that allow them to pose as legitimate applications. Additionally, the client applications that call APIs on behalf of users also have weaknesses and are notoriously bad at keeping secrets. This can be as simple as API keys that are reversed-engineered from looking at a single-page application’s JavaScript code or looking at API traffic through an HTTPS proxy.

Case in point, a study from North Carolina State University revealed that GitHub is a gold mine of application secrets used to call APIs. The study concluded that over 100,000 repositories had leaked API tokens and cryptographic keys. GitHub is acting on this finding by implementing a new security feature to scan tokens from code submitted to its platform

Attackers also use remote access trojans to steal credentials with tools like Mimikatz. They then use the stolen credentials to impersonate users and obtain tokens. Finally, another common vulnerability is credential stuffing on an authorization server leveraging collections of credentials mined from previous breaches.

In each of these scenarios, an attacker obtains a token by exploiting vulnerabilities on users, client-side applications, or authorization servers — not the API itself. This presents a number of issues, as these tokens appear to be legitimate and the hacker looks like a valid user. This sets the stage for user data "leaking through the API". Even with proper access control policies and runtime enforcement, these attacks, in addition to those involving vulnerabilities with APIs themselves, will go undetected by traditional API security tools — often for months and sometimes years.

Security teams could invest a tremendous amount of energy in educating users and API developers about client-app security and identity infrastructure, but they could still be at risk of having vulnerabilities in production APIs and compromised credentials. API providers must account for this in their security measures whether the APIs are internally or externally facing. You can do this by applying artificial intelligence (AI) to both accelerate attack detection and block attacks automatically.

Applying AI to Security 

Security teams can train a machine learning engine on client, user, and API behavior normally exhibited. By using AI, teams can identify good and bad traffic, and recognize attempted attacks and ongoing breaches without manual intervention.

Detecting Atypical Behavior With AI

Metadata for each API call, access tokens or cookies, and the timing and sequence of certain actions can all feed into an AI model. At runtime, this machine learning engine leverages the behavioral model to identify signs potential threats such as whether or not a particular token or cookie is being used outside of a legitimate application, whether data is being leaked or changed, etc.

Leveraging AI-based detection of abnormal-use accelerates threat visibility dramatically, shifting attack discovery from months to minutes or seconds. Once the suspicious API activity is detected, the access token or cookie used to obtain access to the API can be blacklisted or revoked, instantly stopping access from any party using that token across all API endpoints. If the same user identity is behind these attacks, then the user identity itself must be blacklisted and flagged accordingly. This type of monitoring, attack detection, and blocking is realized without a human operator having to define custom rules.

Using API Decoys

The use of API decoys, or honeypots, can also accelerate the detection of API hacking. This involves adding fake API resources that return seemingly valid responses to a requester. Decoys leverage a hacker’s tendency to poke around in ways that legitimate applications do not, effectively turning the tables to take advantage of knowledge surrounding typical hacking behavior.

When hackers fall into these traps, they are instantly recognized. At the same time, their associated IP addresses and access tokens, if they have them at the time, are automatically deemed compromised and blacklisted. The decoy listener is able to recognize that these requests cannot possibly be incoming from genuine applications since those API resources don’t legitimately exist. These security measures need no custom rules or extensive configurations.

Blocking and Repairing

Of course, detection is only part of the solution. How the system reacts is equally important. Once the revelation that a client identifier (e.g., user or token) has been compromised occurs, that identifier must promptly be revoked and/or blacklisted. This information needs to propagate widely across all API enforcement points, API gateways, and agents. Additionally, these events must be recorded for subsequent auditing, and the Security Information and Event Management (SIEM) system must be notified to initiate any standard response processes.

Details surrounding the methods and resources invoked prior to the detection and blocking of the compromised credentials should be logged. Information in the form of forensic reports allows an API provider, a DevOps team, or a security team to take required actions to repair or reverse damage resulting from the attack. Forensics are also leveraged to help comply with regulations such as GDPR, PSD2, and Open Banking.

Securing APIs 

The Ping Intelligent Identity Platform provides a suite of solutions to address foundational API security and compliance enforcement specifically designed for API traffic.

PingAccess

PingAccess controls access to your enterprise’s internal and public-facing APIs. It is deployed at the perimeter of a protected network as a reverse-proxy, or as an agent running alongside your API endpoints. PingAccess supports granular API access control, limiting users to API transactions permitted by the authorization scopes contained in their access tokens.

PingDataGovernance

PingDataGovernance enforces fine-grained authorization to APIs and the data flowing out through your APIs by enabling policies that evaluate the body of API request and response. On API requests, fine-grained authorization policies can limit what a user can do in an otherwise authorized API call (e.g., if they’re authorizing a payment that exceeds a certain limit, modifying a high volume of data entries, etc.). On API responses, PingDataGovernance examines the outbound data against policy and consent records for unauthorized, unintended, sensitive or restricted data that should be dynamically modified or removed from the response prior to release to the client.

PingIntelligence for APIs

PingIntelligence provides deep visibility into API traffic, discovers APIs automatically, provides AI-powered automated API attack detection and blocking, and uses deception/honeypot environments to identify hacking in real-time. Its artificial intelligence engine brings cyberattack protection and deep insight into API activity to PingAccess, API gateways, API management platforms, and APIs implemented directly on App Servers, such as Node.JS, WebLogic, Tomcat or WebSphere.

Conclusion

API security is a critical component of digital transformation initiatives and can improve cyber resiliency across channels.

In an era of Zero Trust, adopting an identity-centric API security infrastructure is core to a modern digital transformation strategy. To ensure the security of your APIs, you need both deep visibility into API activity and AI-powered breach detection. And both need to be layered over basic API access control to catch attacks that stem from API vulnerabilities and to remediate the risk of human error in the configuration of traditional API security systems.