Cloud Data Security: Archive and Delete (Rough Cut)

By Rich

In our last post in this series, we covered the cloud implications of the Share phase of Data Security Cycle. In this post we will move on to the Archive and Destroy phases.

Archive

Definition

Archiving is the process of transferring data from active use into long-term storage. This can include archived storage at your cloud provider, or migration back to internal archives.

From a security perspective we are concerned with two controls: encrypting the data, and tracking the assets when data moves to removable storage (tapes, or external drives for shipping transfers). Since many cloud providers are constantly backing up data, archiving often occurs outside customer control, and it's important to understand your provider's policies and procedures.

Steps and Controls

Encryption

In the Store phase we covered a variety of encryption options, and if content is kept encrypted as it moves into archived storage, no additional steps are needed. Make sure your archiving system takes the encryption keys into account, since restored data is useless if the corresponding decryption keys are unavailable. In cloud environments data is often kept live due to the elasticity of cloud storage, and might just be marked with some sort of archive tag or metadata.

1. Database Encryption: We reviewed the major database encryption options in the Store phase. The only archive-specific issue is ensuring the database replication/archiving method supports maintenance of the existing encryption. Another option is to use file encryption to secure the database archives. For larger databases, tape or storage encryption is often used.
2. Tape Encryption: Encryption of the backup tapes using either hardware or software. There are a number of tools on the market and this is a common practice. Hardware provides the best performance, and inline appliances can work with most existing tape systems, but we are increasingly seeing encryption integrated into backup software and even tape drives. If your cloud provider manages tape backups (which many do), it's important to understand how those tapes are protected -- is any existing encryption maintained, and if not, how are the tapes encrypted and keys managed?
3. Storage Encryption: Encryption of data archived to disk, using a variety of techniques. Although some hardware tools such as inline appliances and encrypted drivesxist, this is most commonly performed in software. We are using Storage Encryption as a generic term to cover any file or media encryption for data moved to long-term disk storage.

Asset Management

One common problem in both traditional and cloud environments is the difficulty of tracking the storage media containing archived data. Merely losing the location of unencrypted media may require a breach disclosure, even if the tape or drive is likely still located in a secure area -- if you can't prove it's there, it is effectively lost. From a security perspective, we aren't as concerned with asset management for encrypted content -- it's more of an issue for unencrypted sensitive data. Check with your cloud provider to understand their asset tracking for media, or implement an asset management system and procedures if you manage your own archives of cloud data.

Cloud SPI Tier Implications

Software as a Service (SaaS)

Archive security options in a SaaS deployment are completely dependent on your provider. Determine their backup procedures (especially backup rotations), any encryption, and asset management (especially for unencrypted data). Also determine if there are any differences between backups of live data and any long-term archiving for data moved off primary systems.

Platform as a Service (PaaS)

Archive security in PaaS deployments is similar to SaaS when you transition data to, or manage data with, the PaaS provider. You will need to understand the provider's archive mechanisms and security controls. If the data resides in your systems, archive security is no different than managing secure archives for your traditional data stores.

Infrastructure as a Service (IaaS)

For completely private cloud deployments, IaaS Archive security is no different than managing traditional archived storage. You'll use some form of media encryption and asset management for sensitive data. For cloud storage and databases, as with PaaS and SaaS you need to understand the archival controls used by your provider, although any data encrypted before moving to the cloud is clearly still secure.

Destroy

Definition

Destroy is the permanent destruction of data that's no longer needed, and the use of content discovery to validate that it is not lingering in active storage or archives.

Organizations commonly destroy unneeded data, especially sensitive data that may be under regulatory compliance requirements. The cloud may complicate this if your provider's data management infrastructure isn't compatible with your destruction requirements (e.g., the provider is unable to delete data from archived storage). Crypto-shredding may be the best option for many cloud deployments, since it relies less on complete access to all physical media, which may be difficult or impossible even in completely private/internal cloud deployments.

Steps and Controls

Crypto-Shredding

Crypto-shredding is the deliberate destruction of all encryption keys for the data; effectively destroying the data until the encryption protocol used is (theoretically, some day) broken or capable of being brute-forced. This is sufficient for nearly every use case in a private enterprise, but shouldn't be considered acceptable for highly sensitive government data. Encryption tools must have this as a specific feature to absolutely ensure that the keys are unrecoverable. Crypto-shredding is an effective technique for the cloud since it ensures that any data in archival storage that's outside your physical control is also destroyed once you make the keys unavailable. If all data is encrypted with a single key, to crypto-shred you'll need to rotate the key for active storage, then shred the "old" key, which will render archived data inaccessible.

We don't mean to oversimplify this option -- if your cloud provider can't rotate your keys or ensure key deletion, crypto-shredding isn't realistic. If you manage your own keys, it should be an important part of your strategy.

Disk/Free Space Wiping and Physical Destruction

These options is only available when you have low-level administrative access to the physical storage. It includes software or hardware designed to destroy data on hard drives and other media, or physical destruction of the drives. At a minimum the tool should overwrite all writable space on the media 1-3 times, and 7 times is recommended for sensitive data. Merely formatting over data is not sufficient. Secure wiping is highly recommended for any systems with sensitive data that are sold or reused, especially laptops and desktops. File-level secure deletion tools exist for when it's necessary to destroy just a portion of data in active storage, but are not as reliable as a full media wipe.

For physical destruction (again, assuming you have access to the drives), there are two options:

1. Degaussing: Use of strong magnets to scramble magnetic media like hard drives and backup tapes. Dedicated solutions should be used to ensure data is unrecoverable, and it's highly recommended you confirm the efficiency of a degaussing tool by randomly performing forensic analysis on wiped media.
2. Physical Destruction: Complete physical destruction of storage devices, focusing on shredding the actual magnetic media (platters or tape).

Due to the abstraction involved in cloud computing, these will often not be available, although your provider may include them as part of their procedures for management of their drives. When managing a private/internal cloud, you can include physical media wiping or destruction as part of your procedures for managing drives removed from active service. In IaaS deployments, you may retain the low level access to overwrite data in individual virtual machines or storage.

Content Discovery

When truly sensitive data reaches end-of-life, you need to make sure that the destroyed data is really destroyed. Use of content discovery tools helps ensure that no copies or versions of the data remain accessible in the enterprise. Considering how complex our storage, archive, and backup strategies in the cloud are today, it is impossible to absolutely guarantee the data is unrecoverable, but content discovery does reduce the risk of retrieval.

As with content discovery in the Store phase, these tools are only effective if they have access to the storage infrastructure; they cannot work through an application interface unless they are built into the application.

For details on Database Discovery and DLP/CMP please see the Store phase. There are two additional technology categories we also see used for this purpose:

1. Storage/Data Classification and Search: These are tools typically used and managed by enterprise storage teams. Their content analysis is generally less detailed than DLP/CMP tools, but can be helpful for broad searches for stored data. Storage/Data classification tools are third-party tools which crawl a storage environment and use rule sets (usually keywords and regular expressions) to apply metadata tags to files. If your cloud storage offers standard file access, they may be helpful. Search is either built into the application or a third-party tool that indexes stored data. While these are not ideal tools for content discovery to ensure data destruction, search may be your only option in some SaaS deployments.
2. Electronic Discovery: Tools dedicated to the electronic discovery of data for legal proceedings. Likely the same tools that will be used to search for destroyed data if there's ever reason to attempt recovery in the future. As with most of the tools in this section, they are not cloud specific and may not be an option.

Cloud SPI Tier Implications

Software as a Service (SaaS)

As with Archive, your data destruction options are completely dependent on your provider. Typically you will be limited to some level of deletion, although in some applications crypto-shredding may be an option. What's most important is to understand how your provider handles data destruction, and to obtain any documentation and service level agreements that are available. Search will usually be your best content discovery option.

Platform as a Service (PaaS)

For data stored with your PaaS provider, unless you have file system access of some sort you will face the same limitations as with SaaS providers. If you encrypt data on your side before sending it to the platform, crypto-shredding is a good option. Any data stored in your environment is obviously easier to destroy, since you have greater control of the infrastructure and physical media. Content discovery may be an option, but this depends completely on how your PaaS-based application is designed.

Infrastructure as a Service (IaaS)

For cloud data storage (database and file based), crypto-shredding is likely your best option. For other infrastructure deployments, particularly those with virtual machines and disks, you may be able to overwrite stored data. Content discovery using DLP/CMP will probably work, again depending on the details of your deployment.

–Rich

Cloud Data Security: Share (Rough Cut)

By Rich

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.

–Rich

Cloud Data Security: Use (Rough Cut)

By Rich

In our last post in this series, we covered the cloud implications of the Store phase of Data Security Cycle (our first post was on the Create phase). In this post we'll move on to the Use phase. Please remember we are only covering technologies at a high level in this series -- we will run a second series on detailed technical implementations of data security in the cloud a little later.

Definition

Use includes the controls that apply when the user is interacting with the data -- either via a cloud-based application, or the endpoint accessing the cloud service (e.g., a client/cloud application, direct storage interaction, and so on). Although we primarily focus on cloud-specific controls, we also cover local data security controls that protect cloud data once it moves back into the enterprise. These are controls for the point of use -- we will cover additional network based controls in the next phase.

Users interact with cloud data in three ways:

• Web-based applications, such as most SaaS applications.
• Client applications, such as local backup tools that store data in the cloud.
• Direct/abstracted access, such as a local folder synchronized with cloud storage (e.g., Dropbox), or VPN access to a cloud-based server.

Cloud data may also be accessed by other back-end servers and applications, but the usage model is essentially the same (web, dedicated application, direct access, or an abstracted service).

Steps and Controls

Activity Monitoring and Enforcement

Activity Monitoring and Enforcement includes advanced techniques for capturing all data access and usage activity in real or near-real time, often with preventative capabilities to stop policy violations. Although activity monitoring controls may use log files, they typically include their own collection methods or agents for deeper activity details and more rapid monitoring. Activity monitoring tools also include policy-based alerting and blocking/enforcement that log management tools lack.

None of the controls in this category are cloud specific, but we have attempted to show how they can be adapted to the cloud. These first controls integrate directly with the cloud infrastructure:

1. Database Activity Monitoring (DAM): Monitoring all database activity, including all SQL activity. Can be performed through network sniffing of database traffic, agents installed on the server, or external monitoring, typically of transaction logs. Many tools combine monitoring techniques, and network-only monitoring is generally not recommended. DAM tools are managed externally to the database to provide separation of duties from database administrators (DBAs). All DBA activity can be monitored without interfering with their ability to perform job functions. Tools can alert on policy violations, and some tools can block certain activity. Current DAM tools are not cloud specific, and thus are only compatible with environments where the tool can either sniff all network database access (possible in some IaaS deployments, or if provided by the cloud service), or where a compatible monitoring agent can be installed in the database instance.
2. Application Activity Monitoring: Similar to Database Activity Monitoring, but at the application level. As with DAM, tools can use network monitoring or local agents, and can alert and sometimes block on policy violations. Web Application Firewalls are commonly used for monitoring web application activity, but cloud deployment options are limited. Some SaaS or PaaS providers may offer real time activity monitoring, but log files or dashboards are more common. If you have direct access to your cloud-based logs, you can use a near real-time log analysis tool and build your own alerting policies.
3. File Activity Monitoring: Monitoring access and use of files in enterprise storage. Although there are no cloud specific tools available, these tools may be deployable for cloud storage that uses (or presents an abstracted version of) standard file access protocols. Gives an enterprise the ability to audit all file access and generate reports (which may sometimes aid compliance reporting). Capable of independently monitoring even administrator access and can alert on policy violations.

The next three tools are endpoint data security tools that are not cloud specific, but may still be useful in organizations that manage endpoints:

1. Endpoint Activity Monitoring: Primarily a traditional data security tool, although it can be used to track user interactions with cloud services. Watching all user activity on a workstation or server. Includes monitoring of application activity; network activity; storage/file system activity; and system interactions such as cut and paste, mouse clicks, application launches, etc. Provides deeper monitoring than endpoint DLP/CMF tools that focus only on content that matches policies. Capable of blocking activities such as pasting content from a cloud storage repository into an instant message. Extremely useful for auditing administrator activity on servers, assuming you can install the agent. An example of cloud usage would be deploying activity monitoring agents on all endpoints in a customer call center that accesses a SaaS for user support.
2. Portable Device Control: Another traditional data security tool with limited cloud applicability, used to restrict access of, or file transfers to, portable storage such as USB drives and DVD burners. For cloud security purposes, we only include tools that either track and enforce policies based on data originating from a cloud application or storage, or are capable of enforcing policies based on data labels provided by that cloud storage or application. Portable device control is also capable of allowing access but auditing file transfers and sending that information to a central management server. Some tools integrate with encryption to provide dynamic encryption of content passed to portable storage. Will eventually be integrated into endpoint DLP/CMF tools that can make more granular decisions based on the content, rather than blanket policies that apply to all data. Some DLP/CMF tools already include this capability.
3. Endpoint DLP: Endpoint Data Loss Prevention/Content Monitoring and Filtering tools that monitor and restrict usage of data through content analysis and centrally administered policies. While current capabilities vary highly among products, tools should be able to monitor what content is being accessed by an endpoint, any file storage or network transmission of that content, and any transfer of that content between applications (cut/paste). For performance reasons endpoint DLP is currently limited to a subset of enforcement policies (compared to gateway products) and endpoint-only products should be used in conjunction with network protection in most cases (which we will discuss in the next phase of the lifecycle).

At this time, most activity monitoring and enforcement needs to be built into the cloud infrastructure to provide value. We often see some degree of application activity monitoring built into SaaS offerings, with some logging available for cloud databases and file storage. The exception is IaaS, where you may have full control to deploy any security tool you like, but will need to account for the additional complexities of deploying in virtual environments which impact the ability to route and monitor network traffic.

Rights Management

We covered the rights management options in the Create and Store sections. They are also a factor in the this phase (Use), since this is another point where they can be actively enforced during user interaction

In the Store phase rights are applied as data enters storage, and access limitations are enforced. In the Use phase, additional rights are controlled, such as data modification, export, or more-complex usage patterns (like printing or copying).

Logical Controls

Logical controls expand the brute-force restrictions of access controls or EDRM that are based completely on who you are and what you are accessing. Logical controls are implemented in applications and databases and add business logic and context to data usage and protection. Most data-security logic controls for cloud deployments are implemented in application logic (there are plenty of other logical controls available for other aspects of cloud computing, but we are focusing on data security).

1. Application Logic: Enforcing security logic in the application through design, programming, or external enforcement. Logical controls are one of the best options for protecting data in any kind of cloud-based application.
2. Object (Row) Level Security: Creating a ruleset restricting use of a database object based on multiple criteria. For example, limiting a sales executive to only updating account information for accounts assigned to his territory. Essentially, these are logical controls implemented at the database layer, as opposed to the application layer. Object level security is a feature of the Database Management System and may or may not be available in cloud deployments (it's available in some standard DBMSs, but is not currently a feature of any cloud-specific database system).
3. Structural Controls: Using database design features to enforce security. For example, using the database schema to limit integrity attacks or restricting connection pooling to improve auditability. You can implement some level of structural controls in any database with a management system, but more advanced structural options may only be available in robust relational databases. Tools like SimpleDB are quite limited compared to a full hosted DBMS. Structural controls are more widely available than object level security, and since they don't rely on IP addresses or external monitoring they are a good option for most cloud deployments. They are particularly effective when designed in conjunction with application logic controls.

Application Security

Aside from raw storage or plain hosted database access, most cloud deployments involve enterprise applications. Effective application security is thus absolutely critical to protect data, and often far more important than any access controls or other protections. 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)

Most usage controls in SaaS deployments are enforced in the application layer, and depend on what's available from your cloud provider. The provider may also enforce additional usage controls on their internal users, and we recommend you ask for documentation if it's available. In particular, determine what kinds of activity monitoring they perform for internal users vs. cloud-based users, and if those logs are ever available (such as during the investigation of security incidents). We also often see label security in SaaS deployments.

Platform as a Service (PaaS)

Depending on your PaaS deployment, it's likely that application logic will be your best security option, followed by activity monitoring. If your PaaS provider doesn't provide the level of auditing you would like, you may be able to capture activity within your application before it makes a call to the platform, although this won't capture any potential direct calls to the PaaS that are outside your application.

Infrastructure as a Service (IaaS)

Although IaaS technically offers the most flexibility for deploying your own security controls, the design of the IaaS may inhibit deployment of many security controls. For example, monitoring tools that rely on network access or sniffing may not be deployable. On the other hand, your IaaS provider may include security controls as part of the service, especially some degree of logging and/or monitoring.

Database control availability will depend more on the nature of the infrastructure -- as we've mentioned, full hosted databases in the cloud can enforce many, if not all, of the traditional database security controls.

Endpoint-based usage controls are enforceable in managed environments, but are only useful in private cloud deployments where access to the cloud can be restricted to only managed endpoints.

–Rich

Cloud Data Security: Store (Rough Cut)

By Rich

In our last post in this series, we covered the cloud implications of the Create phase of the Data Security Cycle. In this post we're going to move on to the Store 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

Store is defined as the act of committing digital data to structured or unstructured storage (database vs. files). Here we map the classification and rights to security controls, including access controls, encryption and rights management. I include certain database and application controls, such as labeling, in rights management -- not just DRM. Controls at this stage also apply to managing content in storage repositories (cloud or traditional), such as using content discovery to ensure that data is in approved/appropriate repositories.

Steps and Controls

Access Controls

One of the most fundamental data security technologies, built into every file and management system, and one of the most poorly used. In cloud computing environments there are two layers of access controls to manage -- those presented by the cloud service, and the underlying access controls used by the cloud provider for their infrastructure. It's important to understand the relationship between the two when evaluating overall security -- in some cases the underlying infrastructure may be more secure (no direct back-end access) whereas in others the controls may be weaker (a database with multiple-tenant connection pooling).

1. DBMS Access Controls: Access controls within a database management system (cloud or traditional), including proper use of views vs. direct table access. Use of these controls is often complicated by connection pooling, which tends to anonymize the user between the application and the database. A database/DBMS hosted in the cloud will likely use the normal access controls of the DBMS (e.g., hosted Oracle or MySQL). A cloud-based database such as Amazon's SimpleDB or Google's BigTable comes with its own access controls. Depending on your security requirements, it may be important to understand how the cloud-based DB stores information, so you can evaluate potential back-end security issues.
2. Administrator Separation of Duties: Newer technologies implemented in databases to limit database administrator access. On Oracle this is called Database Vault, and on IBM DB2 I believe you use the Security Administrator role and Label Based Access Controls. When evaluating the security of a cloud offering, understand the capabilities to limit both front and back-end administrator access. Many cloud services support various administrator roles for clients, allowing you to define various administrative roles for your own staff. Some providers also implement technology controls to restrict their own back-end administrators, such as isolating their database access. You should ask your cloud provider for documentation on what controls they place on their own administrators (and super-admins), and what data they can potentially access.
3. File System Access Controls: Normal file access controls, applied at the file or repository level. Again, it's important to understand the differences between the file access controls presented to you by the cloud service, vs. their access control implementation on the back end. There is an incredible variety of options across cloud providers, even within a single SPI tier -- many of them completely proprietary to a specific provider. For the purposes of this model, we only include access controls for cloud based file storage (IaaS), and the back-end access controls used by the cloud provider. Due to the increased abstraction, everything else falls into the Application and Document Management System category.
4. Application and Document Management System Access Controls: This category includes any access control restrictions implemented above the file or DBMS storage layers. In non-cloud environments this includes access controls in tools like SharePoint or Documentum. In the cloud, this category includes any content restrictions managed through the cloud application or service abstracted from the back-end content storage. These are the access controls for any services that allow you to manage files, documents, and other 'unstructured' content. The back-end storage can consist of anything from a relational database to flat files to traditional storage, and should be evaluated separately.

When designing or evaluating access controls you are concerned first with what's available to you to control your own user/staff access, and then with the back end to understand who at your cloud provider can see what information. Don't assume that the back end is necessarily less secure -- some providers use techniques like bit splitting (combined with encryption) to ensure no single administrator can see your content at the file level, with strong separation of duties to protect data at the application layer.

Encryption

The most overhyped technology for protecting data, but still one of the most important. Encryption is far from a panacea for all your cloud data security issues, but when used properly and in combination with other controls, it provides effective security. In cloud implementations, encryption may help compensate for issues related to multi-tenancy, public clouds, and remote/external hosting.

1. Application-Level Encryption: Collected data is encrypted by the application, before being sent into a database or file system for storage. For cloud-based applications (e.g., public or private SaaS) this is usually the recommended option because it protects the data from the user all the way down to storage. For added security, the encryption functions and keys can be separated from the application itself, which also limits the access of application administrators to sensitive data.
2. Field-Level Encryption: The database management system encrypts fields within a database, normally at the column level. In cloud implementations you will generally want to encrypt data at the application layer, rather than within the database itself, due to the complexity.
3. Transparent Encryption: Encryption of the database structures, files, or the media where the database is stored. For database structures this is managed by the DBMS, while for files it can be the DBMS or third-party file encryption. Media encryption is managed at the storage layer; never by the DBMS. Transparent encryption protects the database data from unauthorized direct access, but does not provide any internal security. For example, you can encrypt a remotely hosted database to prevent local administrators from accessing it, but it doesn't protect data from authorized database users.
4. Media Encryption: Encryption of the physical storage media, such as hard drives or backup tapes. In a cloud environment, encryption of a complete virtual machine on IaaS could be considered media encryption. Media encryption is designed primarily to protect data in the event of physical loss/theft, such as a drive being removed from a SAN. It is often of limited usefulness in cloud deployments, although may be used by hosting providers on the back end in case of physical loss of media.
5. File/Folder Encryption: Traditional encryption of specific files and folders in storage by the host platform.
6. Virtual Private Storage: Encryption of files/folders in a shared storage environment, where the encryption/decryption is managed and performed outside the storage environment. This separates the keys and encryption from the storage platform itself, and allows them to be managed locally even when the storage is remote. Virtual Private Storage is an effective technique to protect remote data when you don't have complete control of the storage environment. Data is encrypted locally before being sent to the shared storage repository, providing complete control of user access and key management. You can read more about Virtual Private Storage in our post.
7. Distributed Encryption: With distributed encryption we use a central key management solution, but distribute the encryption engines to any end-nodes that require access to the data. It is typically used for unstructured (file/folder) content. When a node needs access to an encrypted file it requests a key from the central server, which provides it if the access is authorized. Keys are usually user or group based, not specific to individual files. Distributed encryption helps with the main problem of file/folder encryption, which is ensuring that everyone who needs it gets access to the keys. Rather than trying to synchronize keys continually in the background, they are provide at need.

Rights Management

The actual enforcement of rights assigned during the Create phase.

For descriptions of the technologies, please see the post on the Create phase. In future posts we will discuss cloud implementations of each of these technologies in greater detail.

Content Discovery

Content Discovery is the process of using content or context-based tools to find sensitive data in content repositories. Content aware tools use advanced content analysis techniques, such as pattern matching, database fingerprinting, and partial document matching to identify sensitive data inside files and databases. Contextual tools rely more on location or specific metadata, such as tags, and are thus better suited to rigid environments with higher assurance that content is labeled appropriately.

Discovery allows you to scan storage repositories and identify the location of sensitive data based on central policies. It's extremely useful for ensuring that sensitive content is only located where the desired security controls are in place. Discovery is also very useful for supporting compliance initiatives, such as PCI, which restrict the usage and handling of specific types of data.

1. Cloud-Provided Database Discovery Tool: Your cloud service provides features to locate sensitive data within your cloud database, such as locating credit card numbers. This is specific to the cloud provider, and we have no examples of current offerings.
2. Database Discovery/DAM: Tools to crawl through database fields looking for data that matches content analysis policies. We most often see this as a feature of a Database Activity Monitoring (DAM) product. These tools are not cloud specific, and depending on your cloud deployment may not be deployable. IaaS environments running standard DBMS platforms (e.g., Oracle or MS SQL Server) may be supported, but we are unaware of any cloud-specific offerings at this time.
3. Data Loss Prevention (DLP)/Content Monitoring and Protection (CMP) Database Discovery: Some DLP/CMP tools support content discovery within databases; either directly or through analysis of a replicated database or flat file dump. With full access to a database, such as through an ODBC connection, they can perform ongoing scanning for sensitive information.
4. Cloud-Provided Content Discovery: A cloud-based feature to perform content discovery on files stored with the cloud provider.
5. DLP/CMP Content Discovery: All DLP/CMP tools with content discovery features can scan accessible file shares, even if they are hosted remotely. This is effective for cloud implementations where the tool has access to stored files using common file sharing protocols, such as CIFS and WebDAV.

Cloud SPI Tier Implications

Software as a Service (SaaS)

As with most security aspects of SaaS, the security controls available depend completely on what's provided by your cloud service. Front-end access controls are common among SaaS offerings, and many allow you to define your own groups and roles. These may not map to back-end storage, especially for services that allow you to upload files, so you should ask your SaaS provider how they manage access controls for their internal users.

Many SaaS offerings state they encrypt your data, but it's important to understand just where and how it's encrypted. For some services, it's little more than basic file/folder or media encryption of their hosting platforms, with no restrictions on internal access. In other cases, data is encrypted using a unique key for every customer, which is managed externally to the application using a dedicated encryption/key management system. This segregates data between co-tenants on the service, and is also useful to restrict back-end administrative access. Application-level encryption is most common in SaaS offerings, and many provide some level of storage encryption on the back end.

Most rights management in SaaS uses some form of labeling or tagging, since we are generally dealing with applications, rather than raw data. This is the same reason we don't tend to see content discovery for SaaS offerings.

Platform as a Service (PaaS)

Implementation in a PaaS environment depends completely on the available APIs and development environment.

When designing your PaaS-based application, determine what access controls are available and how they map to the provider's storage infrastructure. In some cases application-level encryption will be an option, but make sure you understand the key management and where the data is encrypted. In some cases, you may be able to encrypt data on your side before sending it off to the cloud (for example, encrypting data within your application before making a call to store it in the PaaS).

As with SaaS, rights management and content discovery tend to be somewhat restricted in PaaS, unless the provider offers those features as part of the service.

Infrastructure as a Service (IaaS)

Your top priority for managing access controls in IaaS environments is to understand the mappings between the access controls you manage, and those enforced in the back-end infrastructure. For example, if you deploy a virtual machine into a public cloud, how are the access controls managed both for those accessing the machine from the Internet, and for the administrators that maintain the infrastructure? If another customer in the cloud is compromised, what prevents them from escalating privileges and accessing your content?

Virtual Private Storage is an excellent option to protect data that's remotely hosted, even in a multi-tenant environment. It requires a bit more management effort, but the end result is often more secure than traditional in-house storage.

Content discovery is possible in IaaS deployments where common network file access protocols/methods are available, and may be useful for preventing unapproved use of sensitive data (especially due to inadvertent disclosure in public clouds).

–Rich

Musings on Data Security in the Cloud

By Rich

So I've written about data security, and I've written about cloud security, thus it's probably about time I wrote something about data security in the cloud.

To get started, I'm going to skip over defining the cloud. I recommend you take a look at the work of the Cloud Security Alliance, or skip on over to Hoff's cloud architecture post, which was the foundation of the architectural section of the CSA work. Today's post is going to be a bit scattershot, as I throw out some of the ideas rolling around my head from I thinking about building a data security cycle/framework for the cloud.

We've previously published two different data/information-centric security cycles. The first, the Data Security Lifecycle (second on the Research Library page) is designed to be a comprehensive forward-looking model. The second, The Pragmatic Data Security Cycle, is designed to be more useful in limited-scope data security projects. Together they are designed to give you the big picture, as well as a pragmatic approach for securing data in today's resource-constrained environments. These are different than your typical Information Lifecycle Management cycles to reflect the different needs of the security audience.

When evaluating data security in the context of the cloud, the issues aren't that we've suddenly blasted these cycles into oblivion, but that when and where you can implement controls is shifted, sometimes dramatically. Keep in mind that moving to the cloud is every bit as much an opportunity as a risk. I'm serious -- when's the last time you had the chance to completely re-architect your data security from the ground up?

For example, one of the most common risks cited when considering cloud deployment is lack of control over your data; any remote admin can potentially see all your sensitive secrets. Then again, so can any local admin (with access to the system). What's the difference? In one case you have an employment agreement and their name, in the other you have a Service Level Agreement and contracts... which should include a way to get the admin's name.

The problems are far more similar than they are different. I'm not one of those people saying the cloud isn't anything new -- it is, and some of these subtle differences can have a big impact -- but we can definitely scope and manage the data security issues. And when we can't achieve our desired level of security... well, that's time to figure out what our risk tolerance is.

Let's take two specific examples:

Protecting Data on Amazon S3 -- Amazon S3 is one of the leading IaaS services for stored data, but it includes only minimal security controls compared to an internal storage repository. Access controls (which may not integrate with your internal access controls) and transit encryption (SSL) are available, but data is not encrypted in storage and may be accessible to Amazon staff or anyone who compromises your Amazon credentials. One option, which we've talked about here before, is Virtual Private Storage. You encrypt your data before sending it off to Amazon S3, giving you absolute control over keys and ACLs. You maintain complete control while still retaining the benefits of cloud-based storage. Many cloud backup solutions use this method.

Protecting Data at a SaaS Provider -- I'd be more specific and list a SaaS provider, but I can't remember which ones follow this architecture. With SaaS we have less control and are basically limited to the security controls built into the SaaS offering. That isn't necessarily bad -- the SaaS provider might be far more secure than you are -- but not all SaaS offerings are created equal. To secure SaaS data you need to rely more on your contracts and an understanding of how your provider manages your data.

One architectural option for your SaaS provider is to protect your data with individual client keys managed outside the application (this is actually a useful internal data security architectural choice). It's application-level encryption with external key management. All sensitive client data is encrypted in the SaaS provider's database. Keys are managed in a dedicated appliance/service, and provided temporally to the application based on user credentials. Ideally the SaaS prover's admins are properly segregated -- where no single admin has database, key management, and application credentials. Since this potentially complicates support, it might be restricted to only the most sensitive data. (All your information might still be encrypted, but for support purposes could be accessible to the approved administrators/support staff). The SaaS provider then also logs all access by internal and external users.

This is only one option, but your SaaS provider should be able to document their internal data security, and even provide you with external audit reports.

As you can see, just because you are in the cloud doesn't mean you completely give up any chance of data security. It's all about understanding security boundaries, control options, technology, and process controls.

In future posts we'll start walking through the Data Security Lifecycle and matching specific issues and control options in each phase against the SPI (SaaS, PaaS, IaaS) cloud models.

–Rich

Securing Cloud Data with Virtual Private Storage

By Rich

For a couple of weeks I've had a tickler on my to do list to write up the concept of virtual private storage, since everyone seems all fascinated with virtualization and clouds these days. Luck for me, Hoff unintentionally gave me a kick in the ass with his post today on EMC's ATMOS. Not that he mentioned me personally, but I've had "baby brain" for a couple of months now and sometimes need a little external motivation to write something up. (I've learned that "baby brain" isn't some sort of lovely obsession with your child, but a deep seated combination of sleep deprivation and continuous distraction).

Virtual Private Storage is a term/concept I started using about six years ago to describe the application of encryption to protect private data in shared storage. It's a really friggin' simple concept many of you either already know, or will instantly understand. I didn't invent the architecture or application, but, as foolish analysts are prone to, coined the term to help describe how it worked. (Not that since then I've seen the term used in other contexts, so I'll be specific in my meaning).

Since then, shared storage is now called "the cloud", and internal shared storage an "internal private cloud", while outsourced storage is some variant of "external cloud", which may be public or private. See how much simpler things get over time?

The concept of Virtual Private Storage is pretty simple, and I like the name since it ties in well with Virtual Private Networks, which are well understood and part of our common lexicon. With a VPN we secure private communications over a public network by encrypting and encapsulating packets. The keys aren't ever stored in the packets, but on the end nodes.

With Virtual Private Storage we follow the same concept, but with stored data. We encrypt the data before it's placed into the shared repository, and only those who are authorized for access have the keys. The original idea was that if you had a shared SAN, you could buy a SAN encryption appliance and install it on your side of the connection, protecting all your data before it hits storage. You manage the keys and access, and not even the SAN administrator can peek inside your files. In some cases you can set it up so remote admins can still see and interact with the files, but not see the content (encrypt the file contents, but not the metadata).

A SaaS provider that assigns you an encryption key for your data, then manages that key, is not providing Virtual Private Storage. In VPS, only the external end-nodes which access the data hold the keys. To be more specific, as with a VPN, it's only private if only you hold your own keys. It isn't something that's applicable in all cloud manifestations, but conceptually works well for shared storage (including cloud applications where you've separated the data storage from the application layer).

In terms of implementation there are a number of options, depending on exactly what you're storing. We've seen practical examples at the block level (e.g., a bunch of online backup solutions), inline appliances (a weak market now, but they do work well), software (file/folder), and application level.

Again, this is a pretty obvious application, but I like the term because it gets us thinking about properly encrypting our data in shared environments, and ties well with another core technology we all use and love.

And since it's Monday and I can't help myself, here's the obligatory double-entendre analogy. If you decide to... "share your keys" at some sort of... "key party", with a... "partner", the... "sanctity" of your relationship can't be guaranteed and your data is "open".

–Rich