Cyber Risk is Rising

As I've read the results of annual threat surveys over the past several years, It’s clear that cyber attacks on API endpoints continue to increase. Some increase seems reasonable if APIs are added to the cloud with the general expansion of cloud workloads and IoT devices. But this year the numbers are quite alarming, much higher than is reasonable for a “per capita” growth rate. But it is also strange for another reason. In the past few years API management and security has become a hot area for startups and established cybersecurity vendors alike. Many new solutions have appeared in the market to protect APIs. The surveys and reports on API attacks indicate the new cyber defenses are not working. Here are two statistics that should cause significant concern to digital organizations with a presence in the cloud or multi-cloud:

‍

Several takeaways from these two statistics are important to realize: 

1)  APIs are a lucrative attack point for threat actors; they provide access to valuable information and money. 

2) Static API keys are easy for threat actors to obtain without detection.

3) The future of a global digital economy is in jeopardy if we cannot solve the API problem and reverse the cybercrime trend.

And here's one more important piece of data, if the first two didn’t create concern:

Lloyds of London, the world's leading insurance market providing specialist insurance services, performed an analysis and estimates that a single cyber attack on the global financial system could cost 3.5 trillion USD (over a five year period).

Their analysis recognizes the tight integration of the global digital economy, the Internet, and the cloud. Financial institutions and monetary APIs are relentlessly attacked using stolen credentials. Our economic viability is at risk if the trends are not reversed. Attackers will become better at exploiting APIs, avoiding defenses that rely on 'threat hunting' to protect the crown jewels.

It’s time to fix this problem. and avoid a crisis.

Cloud Native Automated Moving Target Defense

By definition, APIs are machine-machine transactions and there is an opportunity to use certain cloud native innovations to shrink the “attack surface” and disrupt cyber criminals by preventing them from obtaining useful machine credentials.

Current API security solutions such as code inspection for proper API structure, API logic, API testing, API management and API security are ineffective if the attacker has obtained legitimate access credentials. 

But there is a cybersecurity defense that is effective for credential theft. I'm speaking of Automated Moving Target Defense (AMTD).  And in particular a new form of AMTD that is cloud native. The cloud native form of AMTD was built to operate at the speed and scale of the cloud with ephemeral machine identity and secret credentials. And it also performs identity trust verification and protects untrusted access to API endpoints. AMTD is a simple cyber defense that doesn’t require threat information, behavioral analysis, machine learning, or other mechanisms that consume cyber budget today with a low ROI.

AMTD is an elegant cybersecurity defense because it focuses on what the threat actor needs and seeks;  and what the security owns and controls, and it moves that information (the ‘target’ of the threat actor) randomly and frequently so attackers are unable to successfully plan their attack. Simply put, AMTD prevents attacks.

Cloud Native AMTD for API Threat Protection and Access Control

‍The cloud native form of AMTD is effective in protecting APIs from the misuse of stolen API keys. The API endpoint can determine if an API key originated from a trusted source or not. It can distinguish “friend” from “foe” when API calls arrive at an API endpoint. This capability can make a huge difference for public-facing API endpoints that receive third-party API calls. 

Hopr’s cloud native AMTD Synchronous Ephemeral Encryption (SEE™), a protocol Hopr developed with its CHIPS™ technology, SEE™ wraps API calls sent from trusted endpoints (the legitimate API client) with end-to-end encryption. Only legitimate API calls will reach the API endpoint (the API server), because only those calls pass decryption on arrival at the workload endpoint. Any API call from an untrusted source, even if it is using a valid key and encrypted in TLS, will be recognized and immediately discarded.

The SEE™ protocol is effective when two trusted workloads use the same CHIPS™ algorithm and generate their identical secrets at nearly the same time. These secrets remain safely with the trusted workloads and are used as symmetric keys to encrypt and decrypt API calls and responses. Successful decryption is one method of trust verification that ensures the identity of the sender. 

Protection for Public Facing APIs

But with public-facing workloads (API endpoints) interacting with third-party clients, a slightly different protocol is used. In this situation, it isn’t possible (nor desired) for the connecting workloads to use the same CHIPS™ algorithm. But each organization in the transaction has a trusted relationship with Hopr and uses a special version of a Hopr Sidecar to connect with Hopr. Hopr operates as the “trust guarantor” for both organization's workloads. Hopr can independently verify trust in the client and server API workloads. Once Hopr has verified trust in each workload, the SEE™ encrypted channel from Hopr to each workload is used to transfer a session key to each so they can complete their API transactions securely and with high trust. 

This is a well-proven Kerberos security protocol, and the Hopr implementation is called “Kerberos for the Cloud” (K4C). It ensures that public facing API endpoints only accept legitimate API calls and reject 100% of the untrusted API calls that might arrive at the endpoint. Those untrusted API calls will fail decryption, are logged, and immediately discarded without a return response to the sender. This is an important response feature because it doesn't divulge any information to the Untrusted sender leaving them completely in the dark as to what happened to their message and giving them no information whatsoever about the API endpoint. 

Stolen API Keys, Data Leaks, and Breaches?

Although API keys are static and remain vulnerable to theft, the SEE™ protocol used in cloud native AMTD renders them useless to a threat actor because they cannot arrive at the API endpoint with the proper encryption (even when they arrive encrypted by TLS). The API key from trusted sources is still still presented to API endpoints and serves the purpose of identifying the sender to the endpoint to authorize access to specific data. With cloud native AMTD, no changes to application code or APIs are needed.

The result is high trust, ultra-secure, on-demand connections between client and server API endpoints inside and external to an organization.

The moving target in this situation is the encryption key generated by the CHIPS™ algorithm. The algorithm only runs at the start of an API communication session. Once the key is generated it is used for repeated API calls and responses until the session terminates. On session termination, The encryption Keys vanish and must be  regenerated at the next communication session between the two workloads. Every communication session between any two workloads will have a new unpredictable encryption key. 

There are other features and advantages and benefits of Hopr's cloud native AMTD solution. I recommend you subscribe to  the Hopr blog  as we write more about each feature, advantage, and benefit in future articles.

‍

‍