API security solutions for gaining visibility into API payload encryption

When it comes to API security, end-to-end encryption presents something of a paradox. On one hand, encryption secures the data that is exchanged during transactions. This is, of course, a good thing.

But there’s a drawback: When you use end-to-end API payload encryption, it becomes impossible to perform trace analysis. This means you lose visibility — one of the pillars of API security.

Thankfully, it doesn’t have to be this way. By creating TLS policies, you can have your encryption and eat it, too. In other words, you can encrypt transactions from end-to-end, while also enjoying full visibility into the transactions.

Keep reading to learn how to have the best of both worlds — encryption and visibility — for your API requests.

Better API security solutions: Understanding the drawbacks of API payload encryption

There’s a problem. In the context of the API security solutions you’re after, encrypting API payloads is a good thing to do. But, depending on how you manage the encryption, you may run into some major pitfalls.

As noted above, the biggest drawback is that end-to-end encryption often comes at the expense of visibility. For example, imagine a call between an application that accepts payments and a PayPal API that processes those payments. The call is encrypted, which secures the data, but it makes it impossible to track the transaction and monitor how tokens are used in it:

With a solution like Panoptica, the Cisco Secure Application Cloud, you can see in the first image below the layer 7 attributes are missing for the connections coming from payment (source) to PayPal (destination) because it is encrypted.

This is a challenge for security because without visibility you can not trace accordingly, in this case missing the layer 7 attributes. The result is there is potential to miss calls to risky APIs or sensitive data in the API calls.

In addition, beyond security, a lack of visibility can create issues for data reliability and analytics. Visibility into transactions provides additional information that may be useful for troubleshooting slow transactions or determining why some requests fail, for instance.

How TLS policies enable secure and visible payment gateway APIs

We can create a Transport Layer Security, or TLS, policy to get back the visibility we need to ensure API security.

A TLS policy works by intercepting HTTPS traffic (in other words, the traffic that is encrypted via TLS) and allowing IT /security teams to leverage tools to inspect the traffic, while transactions are being processed. For example, in the context of a PayPal payment processing call, a TLS policy means that teams can read the encrypted traffic and understand how tokens are used during payments.

This is beneficial as it ensures that private information, such as credit and debit card details for example, are protected from hackers. In essence, the payment gateway does not allow unauthorized parties to decrypt encrypted data - making the overall process more secure.

Creating a TLS policy with Panoptica

Using a tool like Panoptica, configuring a TLS policy that allows you to inspect encrypted traffic is easier than you might think.

The first step is to use a secure version of TLS. The current version of TLS, TLS 1.3, provides several crucial security and performance enhancements as compared to TLS 1.2 (or prior).

Fortunately, if you’re unsure which version of TLS you are running, you don’t have to check manually: Panoptica can alert you to TLS 1.2 implementations that may be lurking in your environment.

With TLS properly configured in your environment, you can create a new connection rule in Panoptica:

You can apply the policy to a specific pod, or to any pod.

Next, select the destination from which you want to intercept traffic:

Then configure the methods you want to intercept:

Congrats: Your TLS policy is now ready for action.

In the example we configured above, any pod can communicate with PayPal, but HTTPS traffic will be intercepted. The proxy can terminate the connection, decrypt the traffic, analyze it and then re-encrypt it to send it on its way to its final destination.

Thus, the policy lets us achieve full visibility without compromising on encryption. We can perform trace analysis, report the specific call, block calls (if desired) and determine which token is used in each transaction. To external parties, the data remains encrypted.

In practice, the policy would work something like this: Imagine we want to buy a pair of socks, and we proceed to checkout in an online store:

After submitting the order, we can go to Panoptica and filter for payments. There, we can see the layer 7 attributes and trace the post — visibility we wouldn’t otherwise have when dealing with an end-to-end encrypted transaction.

With Panoptica, and the proper rule in place, the layer 7 attributes for the connections coming from payment (source) to PayPal (destination) are now present.

In short: By allowing the TLS intercept, we were able to enable the system to look into the trace and report usage of the trace.

Seeing the unseen to enhance your API security solutions

You don’t need to choose between security and visibility when processing API transactions. With TLS policies, you can have it all: The security of full payload encryption as data passes over the network, and the ability to inspect traffic and trace the transaction — which, in turn, means the ability to verify data integrity, see usage frequency, and enforce granular access controls within API requests. Your API security solutions require a lot of creative problem-solving sometimes, and with Panoptica, that’s possible.

To get started with Panoptica, sign up for our free tier today at Panoptica.app.