In our last post in this series, we covered the cloud implications of the Use phase of our Data Security Cycle. In this post we will move on to the Share phase. Please remember that we are only covering technologies at a high level in this series on the cycle; we will run a second series on detailed technical implementations of data security in the cloud a little later.

Definition

Share includes controls we use when exchanging data between users, customers, and partners. Where Use focuses on controls when a user interacts with the data as an individual, Share includes the controls once they start to exchange that data (or back-end data exchange). In cloud computing we see a major emphasis on application and logical controls, with encryption for secure data exchange, DLP/CMP to monitor communications and block policy violations, and activity monitoring to track back-end data exchanges.

Cloud computing introduces two new complexities in managing data sharing:

• Many data exchanges occur within the cloud, and are invisible to external security controls. Traditional network and endpoint monitoring probably won’t be effective. For example, when you share a Google Docs document to another user, the only local interactions are through a secure browser connection. Email filtering, a traditional way of tracking electronic document exchanges, won’t really help.
• For leading edge enterprises that build dynamic data security policies using tools like DLP/CMP, those tools may not work off a cloud-based data store. If you are building a filtering policy that matches account numbers from a customer database, and that database is hosted in the cloud as an application or platform, you may need to perform some kind of mass data extract and conversion to feed the data security tool.

Although the cloud adds some complexity, it can also improve data sharing security in a well-designed deployment. Especially in SaaS deployments, we gain new opportunities to employ logical controls that are often difficult or impossible to manage in our current environments.

Although our focus is on cloud-specific tools and technologies, we still review some of the major user-side options that should be part of any data security strategy.

Steps and Controls

Activity Monitoring and Enforcement

We initially covered Activity Monitoring and Enforcement in the Use phase, and many of these controls are also used in the Share phase. Our focus now switches from watching how users interact with the data, to when and where they exchange it with others. We include technologies that track data exchanges at four levels:

• Individual users exchanging data with other internal users within the cloud or a managed environment.
• Individual users exchanging data with outside users, either via connections made from the cloud directly, or data transferred locally and then sent out.
• Back-end systems exchanging data to/from the cloud, or within multiple cloud-based systems.
• Back-end systems exchanging data to external systems/servers; for example, a cloud-based employee human resources system that exchanges healthcare insurance data with a third-party provider.

1. Database Activity Monitoring (DAM): We initially covered DAM in the Use phase. In the Share phase we use DAM to track data exchanges to other back-end systems within or outside the cloud. Rather than focusing on tracking all activity in the database, the tool is tuned to focus on these exchanges and generate alerts on policy violations (such as a new query being run outside of expected behavior), or track the activity for auditing and forensics purposes. The challenge is to deploy a DAM tool in a cloud environment, but an advantage is greater visibility into data leaving the DBMS than might otherwise be possible.
2. Application Activity Monitoring: Similar to DAM, we initially covered this in the Use phase. We again focus our efforts on tracking data sharing, both by users and back-end systems. While it’s tougher to monitor individual pieces of data, it’s not difficult to build in auditing and alerting for larger data exchanges, such as outputting from a cloud-based database to a spreadsheet.
3. Cloud Activity Monitoring and Logs: Depending on your cloud service, you may have access to some level of activity monitoring and logging in the control plane (as opposed to building it into your specific application). To be considered a Share control, this monitoring needs to specify both the user/system involved and the data being exchanged.
4. Network Data Loss Prevention/Content Monitoring and Protection: DLP/CMP uses advanced content analysis and deep packet inspection to monitor network communications traffic, alerting on (and sometimes enforcing) policy violations. DLP/CMP can play multiple roles in protecting cloud-based data. In managed environments, network DLP/CMP policies can track (and block) sensitive data exchanges to untrusted clouds. For example, policies might prevent users from attaching files with credit card numbers to a cloud email message, or block publishing of sensitive engineering plans to a cloud-based word processor. DLP can also work in the other direction: monitoring data pulled from a cloud deployment to the desktop or other non-cloud infrastructure. DLP/CMP tools aren’t limited to user activities, and can monitor, alert, and enforce policies on other types of TCP data exchange, such as FTP, which might be used to transfer data from the traditional infrastructure to the cloud. DLP/CMP also has the potential to be deployed within the cloud itself, but this is only possible in a subset of IaaS deployments, considering the deployment models of current tools. (Note that some email SaaS providers may also offer DLP/CMP as a service).
5. Endpoint DLP/CMP: We initially covered Endpoint DLP/CMP in the Use phase, where we discussed monitoring and blocking local activity. Many endpoint DLP/CMP tools also track network activity – this is useful as a supplement when the endpoint is outside the corporate network’s DLP/CMP coverage.

Encryption

In the Store phase we covered encryption for protecting data at rest. Here we expand to cover data in motion. Keep in mind that additional encryption is only needed if the data would otherwise be exchanged as plain text – there’s no reason or need to redundantly re-encrypt already encrypted network traffic.

1. Network/Transport Encryption: As data moves between applications, databases, the cloud, and other locations, the network connections should be encrypted using a standard network-layer protocol. For larger systems where this could affect performance, hardware acceleration is recommended. Virtual Private Networks are useful for encrypting data moving in and out of clouds in certain deployment models.
2. Application Level Encryption: As we discussed in the Store phase, data encrypted by an application on collection is ideally protected as it moves throughout the rest of the application stack. Don’t forget that at some point the data is probably decrypted to be used, so it’s important to map the data flow and determine potential weak points.
3. Email Encryption: Email encryption isn’t cloud-specific, but since email is one of the most common ways of exchanging data, including reports and data dumps from cloud services, encryption is often relevant for cloud deployments – especially when built into the cloud application/service.
4. File Encryption and Enterprise Digital Rights Management: These technologies were discussed in detail in the Store phase. They also apply in the Share phase since encrypted files or DRM protected documents are still protected as they are moved, not just in storage. For cloud security purposes, encryption or EDRM may be built into various data exchange mechanisms – with EDRM for user files, and encryption as a more general option.

Logical Controls

We discussed Logical Controls in the Use phase, and they can also be used to manage data exchange, not just transaction activity.

Application Security

As with logical controls, we discussed Application Security in the Use phase. Again, a full discussion of cloud application security issues is beyond the scope of this post, and we recommend you read the Cloud Security Alliance Guidance for more details.

Cloud SPI Tier Implications

Software as a Service (SaaS)

Data sharing in SaaS deployments is encapsulated within the application, is connected to back-end external applications, or involves generating data dumps to transfer the content to a local system. Application and logical controls are your best defense, combined with encryption to cover any data transfers. Once data leaves the SaaS application, DLP/CMP may be useful for tracking the content, or to protect it from leaving your managed environment. DLP/CMP is also useful to determine if the data should go to the cloud at all, and ensure that any data is transferred conforms to policy requirements. Since most SaaS solutions rely principally on HTTP for communications/access, most off-the-shelf DLP tools will work.

Platform as a Service (PaaS)

Depending on your PaaS deployment, it’s again likely that application logic will be your best security option, followed by proper use of encryption to secure communications. You may also be able to deploy monitoring in your application that connects to the PaaS provider if they don’t offer a desired level of monitoring/logging, but that will only track connections from your managed environment (someone trying to compromise the PaaS directly, without going through your application, won’t appear in your application logs).

Infrastructure as a Service (IaaS)

VPNs are commonly used to protect communications to IaaS infrastructure, both internal and external. When VPNs aren’t an option, such as with many types of cloud-based storage, SSL/TLS network encryption is usually available. Any additional Share controls rely completely on what you can deploy in the infrastructure. Any monitoring/auditing such as DLP require some sort of network traffic to analyze, or an alternative hook, such as a local agent.