It was disheartening to read that a Financial Services Regulator's guidelines around data sovereignty lead to the termination of a Salesforce® deployment by a large bank. This mandate at least in part resulted in the bank abandoning their $10 million Salesforce investment. The reason this is a disheartening result is because there are cloud data protection solutions (such as Salesforce encryption) that can alleviate much of the security concern that exists with cloud applications.
One of the unfortunate facets of the cloud data protection industry is the lack of specificity in publicly accessible information. This can be frustrating for security architects planning on securing cloud applications and services. With this two part blog post, I intend on providing some practical steps on how one can apply additional layers of security (such as data-level encryption) to cloud applications. This information will focus on Salesforce encryption and StratoKey, but can be applied to any other cloud application.
Part 1 - Salesforce Encryption:
1 - Selecting a Cloud Encryption Gateway 2 - Choose appropriate encryption type(s) 3 - Lock the end application to the gateway
Part 2 - Salesforce Data Protection:
4 - Implement stringent security countermeasures 5 - Track and mitigate any anomalies immediately 6 - Security analytics, monitoring and visibility
The purpose of a Cloud Encryption Gateway (such as StratoKey), is to intercept trusted user communications with a remote cloud application (such as Salesforce) and selectively encrypt the content. The gateway acts as a proxy server, disassembling trusted user communications and encrypting the content. The gateway then transmits this encrypted data on to the remote cloud server.
The primary purpose is to encrypt data before it is sent to the end cloud application. Thus, sensitive information is not stored in the end cloud application. This gateway is usually deployed behind a corporate firewall, but can also be deployed in the cloud itself, layering security (Defense in Depth) rather than relying on the end cloud application).
The crucial point is that no sensitive data is ever stored in plain text (or directly accessible as plain text) by the end cloud system. Encryption is the key to making this a reality.
Some encryption gateways (not StratoKey), use back-end APIs of applications to perform a similar function to StratoKey. The key limitation with this approach is that if anything changes with the application then the gateway itself needs a software update. StratoKey sits in front of applications and is configured with XML configuration files. This means that if anything changes with an application, the configuration can be modified immediately without any need for a software update.
The StratoKey architectural approach is more flexible than the API based approach, in that StratoKey can be configured to work with any application. There is no software update required to support a new application. Simply configure and modify as you need to.
Encrypting information before it reaches the remote cloud system is an appropriate mechanism to secure sensitive data against data breaches. However, one often glossed over detail with Cloud Encryption Gateways is that one needs to categorize information based upon sensitivity and search-ability. After data is categorized appropriate encryption type(s) be selected.
Data categorization may have multiple purposes. For instance, its primary purpose may be to protect banking information, whilst its secondary purpose is to ensure that information stored is not personally attributable. It is important to identify the concrete goal is for data protection right from the start.
Consider, how would a cloud application perform financial calculations if you encrypt the financial figures? The figures at the end of the day may be totally irrelevant to protecting the identity of the account holder - the ultimate end goal. This is why categorization of data must take place at the earliest opportunity. Analysts should inspect each input field and give it a weight as to the sensitivity of the information.
It may appear at first that a bank account number needs to be searchable. The fact is, in most cases a bank account number will not need to be searchable. Search-ability is only needed if the data is the type that you find when entering it into a search bar within the application. Just because you encrypt the information with a high strength algorithm does not mean you can't find it. You can, as it will still be linked to the customer account.
Categorization is straight forward as long as one understands the ground rules. If the information needs to be located, by say typing in a search bar (for instance a client or company name) within the application, then it is deemed searchable. If the information needs to be encrypted but not searched for from the search bar within the application, then it is non-searchable.
If the information must be searchable then a lower grade of encryption must be applied. This grade is known as Searchable Encryption. If the information must be a fixed length or all numbers etc., then Format Preserving Encryption (which can be made searchable) must be used. If the information has a high confidentiality rating and does not need to be searchable, such as banking transaction attachments, then this can be encrypted with high-strength non-searchable encryption such as AES.
Encryption types can be mixed and matched even on the same page of a cloud application. There's no StratoKey restriction. We encourage this mixed-encryption methodology, as it results in appropriately secured applications without loss of functionality.
Fortunately, Salesforce has some good built-in security that compliments a Cloud Encryption Gateway. Salesforce allows you to lock access to specific IP addresses. This is useful if you wish to send all your users through a Cloud Encryption Gateway. This ensures that direct access to the end Salesforce application data is blocked outside of the gateway (i.e. direct access).
Whilst IP based locking can be utilized as a general security measure, it can also be utilized to force external (travelling) team members to proceed through the encryption gateway. Encryption achieves the same end result (users transiting through the gateway) just in a different manner, in that data is encrypted when accessing outside of the gateway. If users want intelligible data, then they must access said data through the gateway.
At first glance it may look like IP locking is limited to internal corporate network deployments. This is in-fact not the case. If StratoKey itself is deployed in the cloud, the cloud application (such as Salesforce) can then be locked to the StratoKey address.
Whilst a Cloud Encryption Gateway deployed in the cloud may sound like a strange concept, it is in-fact not as sinister as one may imagine. StratoKey provides your Salesforce application with a Defense in Depth approach to security. A layering of security controls and measures external to Salesforce (and indeed any protected application), regardless of where StratoKey may be deployed.
IP locking is in no way a complete security solution, although it is an important step to consider when using cloud applications.
That concludes part 1 of this post. Part 2 covers concrete steps outside of encryption, such as layering countermeasures, detecting and mitigating anomalies and having complete visibility over your users and cloud application.