For several years API attack statistics continue to rise at an alarming rate. At the same time there have been many API Management and API Security vendors that have introduced new solutions that promise to solve the problem. That begs the question: with so many API security solutions, why are API attack statistics still so high?

Gartner describes API Security as covering two main categories: API Threat Protection and API Access Control. The API Security market is crowded with solutions, but judging from the attack statistics, few seem to be effective. Some of them focus on content validation (coding practices and business logic to create better APIs and reduce vulnerabilities (always a good thing). Others focus on threat detection and traffic throttling, such as application firewalls, API gateways and API management. They inspect sources of traffic, prevent bot and denial of service attacks, and filter known threat sources. Some also examine the messages en route to API endpoints to detect anomalous behavior or malicious code. The inspection and scanning tools often involve machine learning (ML) or artificial intelligence (AI) and have a false-positive and false-alarm rate (they aren’t 100% successful and may filter legitimate traffic). 

A Topology View of Threats to APIs

The figure below shows a notional enterprise cloud network topology (black and gray) overlaid with common threat vectors (red boxes).

While the popular API Security solutions may offer some protective capability to certain attack vectors (e.g., content validation negates the use of hard-coded API keys, improper API structure, and untested APIs), they are not making a dent in the volume of API attacks and they are not preventing attacks because the security is not applied where it is most needed. 

Three Strategic Cybersecurity Principles

There are three strategic principles that every CISO and Security Architect should consider when working with APIs:

1. Place API protection at the API endpoint, 
2. Add Automated Moving Target Defense (AMTD), and
3. Verify workload trust before sharing data.

These three principles will prevent attacks and losses. Here’s why.  Any threat attacking an API must eventually reach the API endpoint. They have to gain access to the API for a successful attack. So it makes sense to put the strategic line of defense at this location. And apps and data also meet at the API. Protection at that point in an architecture is effective for apps and data. 

Next comes the question of how to defend API endpoints. What kind of defense should be used? Traditionally, the answer has been authentication. But we know from attack statistics that even authenticated APIs are leaking sensitive data to threat actors. The biggest reason for this is the vulnerability caused by static API credentials. Static credentials (and those that rotate infrequently)can be discovered or “sniffed” in transit and misused. 

High Frequency Credential Rotation

The obvious solution here is to rotate credentials at a high frequency - so frequent that any discovery is too late for their misuse by a threat actor. This is the essence of Hopr’s AMTD. Hopr’s AMTD performs API threat protection and API access control in a single solution. It is a  remarkably simple and effective defense because it doesn’t rely on specific knowledge about the threat actor or their methods. It moves the target (credentials) so quickly that any threat is unable to plan for the defense they will confront at the defensive perimeter of the API. AMTD deprives threat actors of the knowledge they need to launch their attack on an API endpoint.

To prevent attacks on the API endpoints at workloads that operate in the cloud, two credentials must be rotated (the identity and secret credentials) at the API. In traditional API security solutions, these credentials are products of PKI and TLS. PKI forms the basis of workload identity, and TLS (or mTLS) forms an encryption key to protect the message between APIs and their clients. Another form of identity is the API key that a client must present to an API so that it can associate the client with data access permissions. However, it is the PKI identity certificate that is the concern for API attacks. Developers will often use a “self-signed” certificate without an expiration date, but they shouldn’t be used for production, and this is overlooked too often. But PKI certificates have another problem. The chain of trust is passed from certificate authority (CA) to CA and automation of certificate production or replacement is focused on speed and not trust. To meet zero trust principles, workloads need an identity credential whose chain of trust is with the workload, and the trust can be verified.

Frequent Workload Trust Verification

Hopr’s AMTD creates a machine alias ID (MAID) credential and rotates it frequently. The MAID is formed when a trusted DevOps engineer first registers a workload with Hopr. From that moment on, Hopr monitors the sessions of the workload and the MAID rotations and verifies trust in the MAID each time a workload begins a new communication session. Hopr’s AMTD preserves a chain of trust in the workload identity.

In addition to a novel rotating identity credential, Hopr’s AMTD has a novel use for the rotating secret credential. Instead of passing it to other workloads for classic authentication, the rotating secret is used as an encryption key and it encrypts and decrypts messages to/from other trusted workloads. The engine of the AMTD is Hopr’s Codes Hidden In Plain Sight (CHIPS) technology and protocol. It enables workloads to build identical keys and construct on-demand end-to-end-encrypted (E2EE) communication channels without a key exchange. The successful decryption of a message verifies the identity of the sender since only that sender could have produced the identical key.

The high frequency rotation of both Hopr AMTD credentials plus the E2EE communication channel protects APIs and data at the endpoints and over the entire route between them. The figure below depicts the same topology presented earlier, but with the addition of Hopr’s AMTD as an API security solution (the blue line and ‘h’ logos). Many more API threat vectors are negated (light red boxes) with the AMTD solution applied at the workloads and API endpoints.

The advantages of using AMTD for API security include:

1. Blocking all untrusted and malicious traffic before it reaches the API endpoint. Only decrypted messages are seen by the API,
2. Both client and server workloads are protected (not just the API),
3. Trust in the client and server is verified at every communication session,
4. Data remains confidential and tamper-proof over the entire route between the client and the API endpoint,
5. A wide range of Man-in-the-Middle (MITM) attacks are negated.

It’s our hope that with this new form of AMTD the rising trend of API attacks can be reversed, less data will be leaked or stolen by threat actors, and workload trust verification in any cloud will become a standard and expected practice in cloud business services.

‍