Regulated Cloud Data: A Day in the Life

Like America’s love of tennis, the cloud economy is growing exponentially. As organizations aggressively push cloud adoption, more sensitive and regulated data ends up in the hands of outside service providers and solutions like SaaS application systems. As a result, recent survey findings show most IT security professionals believe they don’t have full visibility into where all their organization’s sensitive data truly resides.
It’s important to note that cloud data has a three-phase life-cycle. And the journey carries many new risks. Today’s data privacy and compliance practitioners increasingly embrace the idea that safeguards must be in place during all three phases – In-motion; at-rest and, in-use – regardless of where it physically exists (e.g., within the company or in outsourced cloud systems).
As many in the nation tune in to the U.S. Open (and track reams of player data via sophisticated analytics), let’s take a look at why so many enterprises are making such a racket (sorry!) about cloud – and the major concepts and considerations they must consider when it comes to gaining visibility into and control over data during its daily journey to, from, and within public cloud environments.
Here are five tennis moves that map to the three-phase lifecycle of regulated cloud data:
1) The Serve:
The serve initiates every point in the match. By rule, you can opt to serve any way you see fit. But tossing the ball straight up high above the head is the proven way to go. In the case of sensitive or regulated cloud data, such as patient information entered on a hospital admission system screen, when it’s served up it needs to be properly safeguarded to prevent a third party from eavesdropping on a conversation on the wire.
Pro Tip: Cryptographic protocols, such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS), are typically used for protecting data in motion by establishing an encrypted and authenticated transport channel.
2) The Return:
Here we compare data in flight to a tennis ball sailing over the net. Data in motion is protected by the enterprise’s network security infrastructure until it bypasses the firewall (or net, in our analogy) on its way to the cloud. At this point, it is protected only by an SSL “wrapper.” SSL and TLS protocols, which have recently come under scrutiny recently because of some design flaws and successful hacks, provide an encryption wrapper that surrounds a document or data inside the transport tunnel. If someone can get through the wrapper, the data now belongs to him or her.
Pro Tip: Note the data payload inside the transportation layer is still in the clear so enterprises should seriously evaluate the feasibility of encrypting the data itself before it crosses the net versus (or in addition to) simply encrypting the wrapper.
3) The Volley:
Once data has entered the cloud provider’s network, it moves as it gets processed within the cloud – just like pros volleying across the tennis court. In general, this in-use data is in the clear while being processed in the cloud and typically is not protected by techniques such as in-cloud-based encryption that solely protects data while it is sitting at rest within a cloud service provider’s (CSP’s) infrastructure.
Pro Tip: A new category of technologies focusing on data protection – dubbed by Gartner as cloud access security brokers (CASB) – is a solution enterprises could explore. These solutions encrypt data before it leaves the enterprise to provide protection during the data in-use phase, as well as the other data lifecycle phases. These solutions also deliver visibility to who is accessing your cloud environment and the actions they are taking. Enterprises considering these technologies must ensure they evaluate them closely to identify any impact they may have on the use of their cloud applications.
4) Tennis Elbow:
No athlete wants to be sidelined by injury just as no IT security pro wants to suffer from Heartbleed. Heartbleed is a good example of a growing trend of new attack vectors that specifically target data in use. In this example, Heartbleed exploited a vulnerability in OpenSSL, which allowed attackers to directly access the memory space of the affected process, leaking sensitive data in use such as usernames and passwords.
Pro Tip: Remember that the Cloud application actually needs to decrypt data from its encrypted at rest state in order to perform any and all required application processing within the CSP datacenter. So seek out security products that can protect your data at all phases of its lifecycle.
5) Changing Ends:
Tennis action temporarily pauses for opponents to switch sides of the court and take a short breather. Like these tennis pros, cloud data rests. To protect it during its at-rest state, CSPs’ database solutions offer a variety of tools for encryption operations such as transparent data encryption (which encrypts the database blocks on disk) or column encryption (which directly encrypts the column values). Moreover, there are several techniques that encrypt file contents including encrypted file systems and block level encryption techniques.
Pro Tip: You should note a big concern regarding the encryption of data at rest in a cloud environment is who owns the keys and where the keys physically reside. The benefits of data at rest protection are somewhat weakened if the data and the key used to encrypt the data are both stored in a less trusted security zone, such as the CSP’s environment. In response, some CSPs are developing techniques whereby the enterprise, not the cloud service provider, can at least virtually own the keys securing data at rest (even though they still will physically reside elsewhere, which is a show stopper for many enterprises). Unfortunately this solution does not help with data in-use or data in-motion.
As cloud adoption pushes greater volumes of sensitive and regulated data into cloud-based SaaS applications, it’s more important than ever for security and compliance professionals to ask the right questions about where cloud data flows at all times, who has access to it, and what protection mechanisms IT departments and CSPs can be put in place to mitigate risks.
Disclaimer: This article was written by a guest contributor in his/her personal capacity. The opinions expressed in this article are the author’s own and do not necessarily reflect those of