Everyone is looking at GDPR compliance, but what if you process data through cloud services. Companies using cloud services such as Salesforce and Dropbox have to ensure that the data practices at each of them are compliant with GDPR.
GDPR data subjects need to be well-informed about the use of their data and trust that it will be processed securely and only for purposes of which they are aware. This can be a challenge in the cloud, as it isn’t always clear exactly where the data is.
Electronic data in cloud can be hard to track, because it can be spread across backups, archives and copies shared with third parties such as Dropbox and Salesforce. The data in every repository needs to be clearly recorded.
Cloud providers will normally process data they don’t own which is provided by their client. The GDPR will nonetheless give them joint liability, which means any aggrieved subjects can hold both the data controller and the relevant data processor responsible.
In comes CASB to protect data in the Cloud
Cloud Access Security Broker (CASB) is a software tool or service that sits between an organization’s on-premises infrastructure and a cloud provider’s infrastructure. A CASB acts as a gatekeeper, allowing the organization to extend the reach of their security policies beyond their own infrastructure.
CASBs work by ensuring that network traffic between on-premises devices and the cloud provider complies with the organization’s security policies. CASBs enforce a number of different security access controls, including encryption and device profiling. They may also provide other services such as credential mapping when single sign-on is not available.
CASBs securing data in the cloud and on devices can use encryption or “Tokenisation” which is basically switching data to a token. This token maps to the data through a tokenization system. The token itself is practically useless to try to understand what data it is mapped to; only the tokenization system knows. The tokenization system would be inside the CASB provider. When the tokenization system gets the right token, it can “detokenize” the data for access.
Where CASBs run
CASBs runs on premises or in the cloud. Logically, CASBs sit between the end user and the cloud, but physically a CASB has to be located in one of two places: in a corporate data center or in the cloud itself. That means you have a choice between using a cloud access security broker as a service or hosting one on a physical or virtual appliance.
The SaaS option is easier to manage and is the more popular option, according to Gartner, but in certain industries you may have to use an on-premises system for compliance reasons.
The 4 Key Pillars of CASB
There are four key functionalities of CASB. These include Visibility, Data Security, Threat Protection, and Compliance.
Visibility is important because it allows you to keep an eye on both sanctioned and unsanctioned activities. Sanctioned activities can be Office 365. While unsanctioned activities like “Shadow IT” (apps not allowed in your company) are used beyond your knowledge.
Data security in cloud computing presenting a unique challenge. While the data is yours, the systems that store and process it is not. CASB implements measures to protect your data like encryption and tokenization.
Threat protection permits you to control devices, users, and even application versions and can watch carefully for anomalies through user behavior analytics (UBA) and entity behavior analytics (EBA).
Compliance is become a far greater concern, especially with more regulations on who what and how data can be accessed. An example is General Data Protection Regulation (GDPR).
How CASBs work
There are three key ways that a CASB can work. It can be set up as a forward proxy, reverse proxy or API mode. Increasingly CASBs are becoming “mixed mode” or “multi-mode,” using both proxying and API technology. That’s because each approach offers pros and cons.
A forward proxy can be used for all types of cloud applications and all data passes through the proxy, but to use a forward proxy you need to install self-signed certificates on every single device that accesses the proxy. This type of method would be called agent-based. This can be difficult to deploy in a distributed environment or one with a large number of employee-owned mobile devices.
An agent-based deployment requires proxy agents on each endpoint. This deployment is best suited where the assets are corporate-owned and managed. An example would be to install it with your mobile device management clients
A reverse proxy system is the most common method deployed in CASB. The reverse proxy can be accessed from any device, anywhere, without the need for special configuration or certificate installation. This method can be called agentless. CASB owns the Cloud service URL, authenticates it and then passes it to the identity and access management service provider for the next level of authentication.
Agentless deployments cover all devices whether company owned or not and is much quicker to deploy then the Forward Proxy agent-based. This method is good for BYOD mobile devices, since no software is installed on these devices. Agentless deployments only concern themselves with corporate data, ignoring personal data unless otherwise configured.
The CASB’s can be directly connected to the cloud service API’s to monitor the usage irrespective of how and where the cloud services are accessed. This also covers the tracking of the usage out of the organizational network in unmanaged devices.
The method requires installing an API agent on each device. The benefit of the API agent is instantaneous incident response by alerting/ quarantining anomalies if any, while handling the cloud data.
The API method is good for management to inspect data in the cloud for events but can yield a wealth of information to allow you to stay on top of things.
Below is an example of using CASB from inside the company office.
1) CASB can be used with a company’s identity stores to provide a SSO token to log into an app.
2) In proxy mode, CASB can provide access control to resources in the cloud. CASB can provide adaptive controls defined by device or user behavior like location and time.
3) CASB can provide Data Loss Prevention (DLP) by encrypting or tokenizing data
4) Data from the CASB to the user can provide threat protection reducing the risk of malware being placed on the user’s device. CASBs can also scan data across cloud apps for malware.
An example from an outside device
1) Here the device will access the cloud app via a Brower
2) The cloud app is set to redirect authentication to the company’s identity store
3) Once the user is authenticated the device will be directed to the CASB for the entire session. If the device is using a native app it will be required to install a component on the device to insure the device is using the CASB.
Major CASB vendors
If you use cloud in relation to your business, you need a CASB as part of your Cyber Security Strategy. In terms of vendors, you should review the major vendors below.
· Blue Coat
· Skyhigh Networks
Many organizations, I have spoken with over the past three years have adopted a cloud-first strategy focusing to have any new systems as cloud-based. Data has moved beyond the four walls of an enterprise into apps like Salesforce, Concur, Expensify, Workday, Box, and Dropbox making security management and compliance a tough task.
Now add in GDPR to your cloud-based strategy and you have dialed up a tough task to a daunting task.
The CASB market has evolved rapidly since its recent beginnings and has become a necessary cloud security control technology, regardless of the industry vertical, for enterprises adopting multiple cloud services and transferring sensitive data to the cloud.
Gartner reports say by 2020, 85% of all large enterprises will use a cloud access security broker solution for their cloud services. More than a dozen CASB startups have launched since 2010, and a number of the major CASB vendors have recently been acquired by bigger players in the enterprise security and IT markets.
My conclusion on GDPR and CASB as it relates to cloud. CASB can help provide added protection, but an organization would still need to answer then six GDPR points while using the cloud:
- Know the location where cloud apps are processing or storing data. You can accomplish this by discovering all of the cloud apps in use in your organization and querying to understand where they are hosting your data.
- Take adequate security measures to protect personal data from loss, alteration, or unauthorized processing.
- Close a data processing agreement with the cloud apps you are using. Once you discover the apps in use in your organization and consolidate those with overlapping functionality, sanction a handful and execute a data processing agreement with them to ensure that they are adhering to the data privacy protection requirements set forth in the GDPR.
- Collect only “necessary” data and limit the processing of “special” data. Specify in your data processing agreement (and verify in your DLP policies) that only the personal data needed to perform the app’s function are collected by the app from your users.
- Don’t allow cloud apps to use personal data for other purposes. Ensure through your data processing agreement, as well as verify in your app due diligence, that apps state clearly in their terms that the customer owns the data and that they do not share the data with third parties.
- Ensure that you can erase the data when you stop using the app. Make sure that the app’s terms clearly state that you can download your own data immediately.