Introduction
As a SaaS provider, you may offer your users integrations with third-party services or be thinking of doing so, whether to provide an intrinsic feature or add capabilities to improve your product’s competitive edge. These integrations can range widely. Relatively low-impact integrations can include pushing messages into a customer’s Slack channel or reading calendar entries. Other integrations go further, such as making a financial transaction on your clients' behalf using an Automated Clearing House (ACH) transfer or open banking.
However, whatever the integration, they all have something in common: as the provider of the SaaS, you need to request a secret access token from your customer and store it to enable your application to access the third-party system. This requirement creates an obligation on you to protect the secret.
This post explores the options available to safeguard your customers’ secrets.
Why protecting customers’ secrets matters
So, what is a secret? A secret is anything needed to authenticate a user to a service. Broadly, the secrets could include database or system usernames and passwords, but typically, for a SaaS integration, it's likely to be an OAuth token and secret.
If it needs to be clarified why protecting customer secrets matters, consider the recent Heroku breach/leak. This incident started with a threat actor gaining access using a compromised token from a Heroku machine account. This breach went unnoticed until GitHub notified Heroku’s security team of a potential issue. Heroku’s investigation revealed that the threat actor accessed a Heroku database and downloaded customers’ GitHub integration OAuth tokens.
A similar data breach occurred at Sisense, a business intelligence company. Attackers gained access to the company’s internal Gitlab code repository. In there, they found a token or credential that gave them access to Sisense’s Amazon S3 buckets. From there, the bad actors accessed customer data, including access tokens, email passwords, and SSL certificates. This event triggered an investigation by the US Cybersecurity and Infrastructure Security Agency (CISA), given that Sisense customers include critical infrastructure sector organizations.
The severity of these incidents would've been much reduced if those companies had appropriately secured their customers’ secrets.
Choosing the right level of protection
You might think, “But this is straightforward: My database is protected, so I'll just put the secrets in there.” or “I can use one of those secrets manager products.” Unfortunately, it's not that straightforward.
When I talk to potential customers, I describe the levels of protection using four categories: basic, field-level encryption, employing secret managers, and using a vault.
Level 0: Basic
Basic is the lowest level of protection and, sadly, one of the most common. At this level, your application database stores secrets in plain text.
This approach has the obvious advantage that the secrets are easily accessible along with the other information you need to implement your application. However, this easy accessibility is simply asking for a data breach. As the secrets are not protected, anyone who can access the database can access the secrets. And don’t think that encryption at rest provides any meaningful protection.
In addition, this approach offers limited access control; someone either gets access to all or nothing. So, if the application is compromised, all data is compromised. There's also no audit mechanism, so you cannot even see who's used the secrets.
Level 1: Field-level encryption
The next level of protection also uses the application database but adds field-level encryption to the secrets. Now, someone who accesses the database won't be able to see the secrets without also compromising the encryption mechanism.
However, this approach has the same issues with access control and auditing as the basic use of a database; it requires encryption key management, including key rotation and key access. If you don't do this correctly, a threat actor can easily compromise the encryption or the application.
Level 2: Secrets manager
Using a secrets manager or parameter management tool such as AWS Systems Manager (formerly Amazon Simple Systems Manager (SSM)) is stepping things up a level. These tools provide a significant improvement over field-level encryption. Customer secrets benefit from a mechanism that ensures the encryption keys are never exposed and the keys are managed appropriately.
Now, there is an added operational cost, but it can be cost-effective for relatively modest requirements (less than 100,000 secrets). However, these products were never designed for this purpose, so they may not provide the throughput and response times your application needs.
Level 3: Vault
You can achieve the highest level of protection using a vault. In this case, you also hand off the storage of the secrets to a third party. Using a vault, you benefit from managed encryption keys, like a secret manager or AWS SSM. In addition, you can get features such as granular access control, audits, and proxy or relay APIs. A proxy or relay API uses the stored secrets to connect to a third party at your application's request. This mechanism means your application doesn’t see the secret, reducing the risk of exposing customers' secrets should someone compromise the application.
The developers of this type of product engineer them for high throughput and optimal response times. This option should also be more cost-effective when managing more than 100,000 secrets.
This table looks at the features provided by each option in more detail.
How Piiano Vault can help
We designed Piiano Vault to protect sensitive and personal data for virtually any application. It is a purpose-built vault with a relay API that provides all the features needed to protect customers’ secrets securely. It is also designed with zero trust principles, so even if the application is compromised, it doesn’t necessarily mean all secrets are compromised, as is usually the case today.
Click here to learn more about Piiano Vault
Conclusion
A significant contributor to a SaaS offering's success is its ability to engender trust with potential and active customers. Where that service includes third-party integrations, building that trust means providing best-practice protection for those customers' secrets.
The best practice solution is to use a privacy vault to store, encrypt, and manage access to those secrets without easily exposing them.
Piiano Vault is a cost-effective way of implementing these best practices. It can be implemented in server or serverless versions to encrypt and tokenize customer secrets.
In future blog posts, we will explore some of the practicalities of implementing best practices for protecting customers’ secrets with Piiano Vault. In the meantime, check the documentation or contact us today to find out more.
Further reading
Entrepreneur, Founder, Engineer, Software R&D expert, Mentor, Consultant and Team Leader with more than 20 years of experience in project management, software engineering, large scale cloud based systems design and development. B.Sc. in Computer Science and finishing my M.Ss in Computer Science.
It all begins with the cloud, where applications are accessible to everyone. Therefore, a user or an attacker makes no difference per se. Technically, encrypting all data at rest and in transit might seem like a comprehensive approach, but these methods are not enough anymore. For cloud hosted applications, data-at-rest encryption does not provide the coverage one might expect.
Senior Product Owner
