As most security practitioners know by now, securing enterprise cloud usage can be quite a challenge. Because it...
can spring up unexpectedly, security teams often learn about the adoption of cloud services after the fact. And despite pleas from security administrators, business pressures make the implementation of additional security controls challenging, since executives understandably loathe seeing anticipated cost savings eaten away.
This challenge becomes even more complicated when talking specifically about securing data in a cloud context. This is because one of the primary benefits of cloud is data availability, especially the promise that data can be accessed across multiple devices and geographic locations. Unanticipated availability concerns resulting from cloud data security measures (for example, should those controls fail) can understandably make organizations wary. As a result, it's not surprising to see statistics like Georgia Institute of Technology's recent report, Emerging Cyber Threats Report for 2014, suggest that organizations rely too heavily on the security measures implemented by a cloud services provider (CSP) without employing additional security mechanisms of their own.
The truth is that "self-managed" data protection mechanisms can be quite beneficial. By this, self-managed means controls that operate directly on the data itself and are implemented, maintained and controlled by the cloud customer. In practice, this refers most often to the encryption of data (assuming the customer has the keys), but, depending on context, it could also refer to tokenization scenarios or even certain access control measures (though this is, of course, subject to implementation). By using these mechanisms, customers not only help insulate their data from security failures at a CSP but, given that there's some data suggesting that certain risks are decreased in a cloud environment, can also give a cloud customer the best of both worlds. It increases resilience to certain attacks (made possible because of a CSP's economies of scale) without sacrificing "point control" against unwanted data proliferation.
It goes without saying that not every enterprise environment needs these self-managed controls (more to come on that). However, even if a situation doesn't call for them now, having a working knowledge of when the use of self-managed controls may be appropriate can help an organization secure future usage scenarios should they arise.
The value of extra cloud data security
Examining why additional data protection might be desired first requires some understanding about the baseline security environment at the CSP in question, as well as a fairly detailed understanding of how the services are to be used within the enterprise. Believe it or not, the knowledge of these two things is not always a given; the lack of time or resources for pre-deployment vetting can limit knowledge of what security mechanisms a CSP has in place, while shadow IT adoption and post-deployment proliferation of usage can make it hard to keep a handle on the use of services.
To start, it's important to understand that CSPs tend to build a security environment that meets the majority of their customers' needs. Since it's a truism that what's useful for one (even if that one is the majority) isn't useful for all, this could well mean that security measures that make sense for a given organization (but aren't required by the majority) don't come in a stock offering. Be sure to check with the CSP, though, because the service you need might be available at an additional cost.
Second, it's important to understand the economics of support at a CSP. Not everything that's a good idea security-wise can be supported in an economic fashion. While it's true that CSPs can efficiently provide some services that are out of reach for a particular client on its own (again because of economies of scale), there's also a corollary to that. Specifically, if a feature can't be scaled, a service provider can't economically maintain default services that include it. Again, this doesn't preclude a customer implementing it on its own or a CSP making it available at an extra cost.
Lastly, usage and context matter: A cloud customer has certain responsibilities on its side to ensure the service is used and operated securely. For example, posting an administrator password on Facebook will trump any security a provider might add.
The point is, there are many good reasons why organizations might decide to implement additional controls above and beyond their providers' default offerings. But not every situation requires it. This is where the knowledge of enterprise usage comes in. Just like an internal technology deployment, an enterprise must evaluate its usage against the risks. Sound familiar? It should. It's what security pros have been doing for decades: risk management.
In the case of cloud data security, it's not much different. Usage dictates what threats there might be as well as the impact of an exploitation. Examining these in light of what the provider supplies should highlight any gap between the offering and where the customer wants to be. To fill the gap, organizations may wish to evaluate additional protections and controls.
For example, consider a situation when bursting is used to support extra capacity or cycles for accounting during an enterprise's end-of-month crunch. In this case, usage (the processing of important financial records or extra resources for accounting applications) might dictate the need for extra protection (i.e., extra access controls beyond those that would be appropriate for a less sensitive use case).
If after a usage evaluation it is clear that additional security measures must be implemented, organizations must figure out where to add them. While this is a complicated question to answer, enterprises should determine where data is before it gets to the cloud. Doing this offers several advantages. First, the approach is possible, whereas examination once data gets to the provider might not be.
Recall that the underlying technology implementation in the cloud is opaque from a customer point of view. After all, the application stack -- more or less of it depending on if you're using Software as a Service (SaaS), Platform as a Service (PaaS) or Infrastructure as a service (IaaS) -- is outside direct customer control. For example, operating on the data itself via encryption before it enters the application stack in the first place means the data stays protected no matter what happens later (e.g., should usage change, data stays encrypted). Compare this to data encryption implemented in the OS level (for example in IaaS) or in the application (in PaaS). In these scenarios, if the usage changes later on, enterprises will need to revisit the implementation. But if the data was encrypted or tokenized beforehand, it might not have to.
Note that implementation of this varies depending on the type of cloud deployment. For example, a SaaS deployment might use proxy technologies to "inject" security into the application stream (for example, to encrypt or tokenize data in an application-agnostic manner). In addition, if they're available, you could leverage "callback" application programming interfaces from the SaaS vendor to apply encryption on data via a Web service (note that this requires a SaaS service provider that supports that in the first place).
The point is, cloud customers have options. Though not every cloud use case requires -- or every customer will need or want -- additional self-managed data protection controls, there are some cloud instances for which it could be very useful. The fact that the data suggests self-managed controls are not well implemented and not used often enough means this could be an area more cloud customers might wish to consider.
About the author:
Ed Moyle is the director of emerging business and technology at ISACA. He previously worked as senior security strategist at Savvis Inc. and as senior manager at Computer Task Group. Prior to that, he served as vice president and information security officer at Merrill Lynch Investment Managers.