Cloud App Encryption and CASB
Blog Article Published: 01/19/2018
By Kyle Watson, Partner/Information Security, Cedrus Digital
Many organizations are implementing Cloud Access Security Broker (CASB) technology to protect critical corporate data stored within cloud apps. Amongst many other preventative and detective controls, a key feature of CASBs is the ability to encrypt data stored within cloud apps. At the highest level, the concept is quite simple – data flowing out of the organization is encrypted, as it is stored in the cloud. However, in practice there are nuances in the configuration options that may have impact on how you implement encryption in the cloud. This article outlines important architectural decisions to be made prior to the implementation of encryption solutions through a CASB.
Gateway Delivered, Bring Your Own Key (BYOK), or Vendor Encryption
There are three generic methods in cloud-based encryption.
Gateway delivered encryption – In this model, the CASB may integrate with your organization’s existing key management solution through Key Management Interoperability Protocol (KMIP) or provide a cloud-based key management solution. In either case, the keys used to encrypt your data never leave your CASB.
- Data is encrypted before it leaves your environment and is stored at the vendor
- You control the keys
- The vendor retains no capability to access your data
BYOK encryption – In this model, the keys are generated and managed by your organization, and then are supplied to the vendor. BYOK allows you to manage the lifecycle of the keys, which are then shared with the vendor. This includes revoking and rotating keys. The keys are then provided to and utilized by the vendor to decrypt requested data for use by authorized users. CASB can be involved as a broker of the keys to simplify, centralize, and streamline the process of key management by allowing you to perform this administration directly in the CASB User Interface (UI). This also may be done using KMIP with your existing key management solution. Alternatively, without a CASB you may still enjoy the benefits of encryption with your own keys, but administration would be manual on an app-by-app basis.
- Data is encrypted at the vendor
- You can control the keys
- The vendor retains the capability to access your data
Vendor provided encryption – In this model, the vendor provides keys and key management. The administration may be provided through user interfaces provided by the vendor. The CASB is not involved.
- Data is encrypted at the vendor
- The vendor controls the keys
- The vendor retains the capability to access your data
There is not a “best” way to manage encryption for cloud apps. One important consideration for you to make the best decisions for your company begins with your motivation. Is your primary concern compliance, mitigating risk of vendor compromise, protecting data from being disclosed in blind subpoenas, all three?
- Compliance – Encryption for compliance can be met easily by any of the three approaches, and is simplest with vendor provided encryption.
- Mitigating risk of vendor compromise – Using encryption to mitigate the risk of vendor compromise implies the need to manage your own key, since your data will not be accessible without the key. Gateway delivered encryption is the approach that can provide the highest level of risk mitigation due to vendor compromise, as your keys never leave your environment. Cyber- attackers stealing your data will not be able to decrypt it without using your key or breaking your encryption. Risk may also be mitigated through BYOK, but agreements must be secured from the vendor to communicate breaches in a timely fashion. Then you must take appropriate revocation actions in your key management process.
- Protecting data from being disclosed in subpoenas / blind subpoenas – Using encryption to protect data from being disclosed in subpoenas also implies the need to manage your own key. Gateway delivered encryption is the approach that can provide the highest level of risk mitigation from blind subpoena through a completely technical means, as third parties retrieving your data will not be able to decrypt it without your key. Risk may also be mitigated through BYOK, but agreements must be secured from the vendor to communicate third-party requests for your data in a timely fashion. Then you must take appropriate revocation actions in your key management process.
Unstructured and Structured Data
To further explain these approaches we must break out two very different types of data prevalent in the cloud: Unstructured and structured data. Unstructured data refers to data generated and stored as unique files and is typically served through end user apps, for example, Microsoft Word documents. Structured data refers to data that conforms to a data model and is typically served through relational databases and User Interfaces (UI), for example, Salesforce UI.
- Gateway delivered encryption – Since the CASB sits between your end user and the application, structured data can represent a challenge to usability. From a usability perspective, whenever the application vendor changes field structures, the encryption must be addressed in order to maintain usability. From a security perspective, the app must decrypt and reveal some information in order to allow search, sort, and type-ahead fields to work properly in a cloud app UI. This is known as “Format Preserving”, “Order Preserving”, and “Order Revealing” encryption, which can lower the overall standard. A growing body of research is challenging this method and exposing weaknesses that may lead to compromise. For example, if you were to type “JO” in a field and it revealed all of the persons with names beginning with JO, this data has to be retrieved decrypted to support the UI.
- BYOK encryption – since you supply the keys to the vendor, encryption/decryption occurs within the vendor application architecture. This reduces the risk of usability problems when using encryption, because the decryption happens under vendor control. From a security perspective, BYOK does not suffer from the same risk of compromise in “reveal”, as exists in gateway delivered encryption.
- Vendor provided encryption – Since the vendor owns the keys, encryption/decryption occurs within the vendor application architecture. This reduces the risk of usability problems when using encryption, because the decryption happens under vendor control. From a security perspective, vendor provided encryption does not suffer from the same risk of compromise in “reveal”, as exists in gateway delivered encryption.
- Gateway delivered encryption – Risk of usability problems is low on unstructured data in cloud storage. However, an important consideration is key rotation. Data encrypted under one set of keys can only be opened with those keys. Keys may need to remain available in archive, for reads, even if they have been retired.
- BYOK encryption – Since the keys are supplied to the vendor, encryption/decryption occurs within the vendor application architecture as does key rotation and management.
- Vendor provided encryption – Since the vendor owns the keys, encryption/decryption occurs within the vendor application architecture. This reduces the risk of usability problems when using encryption, because the decryption happens under vendor control. Key management processes will be dependent upon the vendor.
Most major cloud vendors are moving toward the support of a BYOK model. Some of these include Salesforce, ServiceNow, Box, Amazon Web Services (AWS), and Microsoft Azure to name a few. As more and more vendors are offering this type of capability, at Cedrus we believe that this is the direction of cloud encryption.
- Gateway delivered encryption – This is the highest level of security that can be provided when it comes to cloud app encryption, but may have an impact to the business in usability issues, especially when applied to structured data. High-risk apps and data are safest in this configuration and require the most care and feeding.
- BYOK encryption – This implementation can provide a very high level of security without the impact that comes with gateway encryption. Through integration with a CASB as a broker of keys to centralize this management, this solution provides an excellent balance between protection and usability for high-risk apps and data.
- Vendor provided encryption – This implementation provides a much higher level of security than not implementing encryption. This solution may be best suited for apps and data of lower criticality or meeting compliance requirements, only.
As with all security decisions, risk and compliance must be the yardstick in any decision. Since we do not know the industry, application, or risk to your business; this is a generic recommendation.
Where possible, always leverage your own keys over vendor-provided keys. Remember, a breach into a lower-risk app may provide clues to breach other apps.
When provided as an option, the best trade-off between security and usability is BYOK. It is very important to gain agreement from vendors for proactive communication. Where BYOK is not offered, the risks must be weighed carefully between vendor provided and gateway delivered encryption, especially for structured data.
When considering a move to gateway encryption, risk analysis of the app and data are critical. The risk of compromise should be clear and present danger. This is because a decision to move to gateway encryption for structured data means a commitment to the management and maintenance at a much higher level than BYOK or vendor provided encryption. This is not a recommendation against taking this course, but advice to consider this path carefully and plan the resources necessary to maintain this type of implementation. In a recent exchange with a customer they articulated the challenge: “We use CASB to provide field level encryption for our Salesforce instance. There are many issues requiring a lot of support and we have plans to move away from it and leverage encryption that is part of the Salesforce platform.”
Sign up to receive CSA's latest blogs
This list receives 1-2 emails a month.