Use Piiano Vault to protect your customers’ secrets with encryption or tokenization

In April this year business intelligence company, Sisense, suffered a breach where bad actors accessed customer data, including access tokens, email passwords, and SSL certificates. The attackers accessed the company’s internal Gitlab code repository and found a token or credential that gave them access to Sisense’s Amazon S3 buckets. This event triggered an investigation by the US Cybersecurity and Infrastructure Security Agency (CISA), given that Sisense customers include critical infrastructure sector organizations.

Could this happen to you? In a world where cybercriminals are always looking for unprotected PII, either for its intrinsic value or to blackmail your business, protecting customer secrets is more important than ever.

In my post, How to Protect Customers' Secrets in Your SaaS Offering: Detailed Guide, I introduced you to best practices for protecting customer secrets and how using a privacy vault has the potential to offer the best protection. In this post, I dig deeper into the practical approaches to implementing this protection using Piiano Vault. Specifically, I show you how straightforward it is to encrypt or tokenize your customer secrets using the Vault REST API.

For this post, I'm using a use case where your app integrates with Slack and sends a message whenever an event occurs. You enable your customers to receive these messages by requesting Slack webhooks from your customers through a simple webpage with an input box.

The challenge is storing these incoming Slack webhooks (i.e., the secret) securely.

I don’t cover setting up your instance of Piiano Vault in this post. 

If you've never done this before, you have a couple of options to try things out:

1. Set up a local developer version. See the get started guide in the Piiano Vault dev docs for instructions.
2. Create a sandbox account on the managed version of Piiano Vault.

I recommend using the managed version.

Option 1: Encrypt customer secrets

This option protects your customers' secrets by encrypting them with Vault. You then store the resulting ciphertext in your system. You can use a self-hosted full or stateless version of Piiano Vault or the managed version to do this. 

Set up a Vault collection

While you don't store customer data in Piiano Vault using this option, Vault needs a collection to perform the encryption against. Vault uses this collection to validate and normalize data, control access to the data, and manage encryption keys.So, the first thing you need to do is define one. In this case, you can keep it very simple: a collection with a webhook property. You define this to Vault using the REST API like this:

Encrypt your customers’ secrets

Now, you are ready to encrypt the Slack webhooks your customers provide. You do this using the encrypt operation of the Vault REST API., You pass this operation details of the collection and collection property you want Vault to perform the encryption against –  the webhook property in the secrets collection – along with the webhook value you want encrypted like this:

‍

The response is the ciphertext generated by the encryption, like this:

‍

You now simply store the ciphertext in your database.

Send the message

When sending a message from your application to the customer's Slack account, you can use Piiano Vault to decrypt the webhook ciphertext and then use the webhook in your code. However, Piano Vault provides a more secure mechanism through the Invoke HTTP call action REST API operation. With this option, you give Vault the ciphertext and information on how to make the HTTP call. Vault then decrypts the webhook and builds the request without exposing the plain text webhooks to your application, further reducing the risk of data leaks.

To prepare for using the call action, you define variables that will take values from Vault and the HTTP request, which uses the variables to pass information to the third party.

Variables are defined using the Vault Global Identifier. In this example:

‍

This code tells Vault to populate the variable to_webhook with the value it gets by decrypting an object from the secrets collection for the webhook property using a ciphertext string.

You now use the to_webhook to create the body of the HTTP request, in the case of our Slack message, like this:

‍

Putting this all together, you make a call using the HTTP call action like this:

Option 2: Using tokenized customer secrets

WIth this option you protect your customers' secrets by storing them in Vault and obtaining a token representing the stored value. You then store the token in your database. You use the full version to do this as you are storing values in Vault.

Set up a Vault collection

To get started, Vault needs a collection to store your customer secrets in, so it has the original data to retrieve when a user attempts to detokenize a token. As you are only storing the customers’ Slack webhook in Vault, all you need is the collection you used to encrypt the webhooks: a collection with a webhook field.

Tokenize your customers’ secrets

When you've set your collection, you determine the token type you want to generate. Vault can create a variety of token types. In this example, you use a pointer token. This token represents a property value (the webhook) as it is when the token is detokenized.

You can now store and tokenize webhooks using the tokenize REST API operation. Very much in the way you perform encryption, you pass the operation details of the collection and collection property Vault stores the webhook in and the webhook value you want Vault to store and tokenize like this:

‍

The response provides you the token and the ID of the object stored in the Vault collection, like this:

‍

You now simply store the token ID in your database.

Send the message

As with encryption, you can use Piiano Vault to detokenize the webhook token and then use the webhook in your code. However, the Invoke HTTP call action REST API provides a more secure option.

You use the same REST API call as described in the encryption section. The only difference is that the Vault global identifier needs to specify that the action is to detokenize and provide the token, like this. 

‍

You make a call using the HTTP call action like this:

Using Vault as your turnkey solution

The chances are that your customers’ Slack webhooks are not the only personally identifiable information that you hold for your customers. By storing them in Vault, you can easily enhance the protection provided to details such as names, addresses, and payment information.

Conclusion

In this post, I have shown you how to take practical steps to protect customer secrets with encryption or tokenization, illustrating the Piiano Vault REST API operations you would use. I've also introduced you to the invoke HTTP call action REST API operation. This operation enables you to use a customer secret without exposing it to the user who makes the call. This means that, after a customer secret has been encrypted or tokenized, no part of your application needs to handle it in plain text, significantly reducing the risk of leaks.

‍

‍