Encryption in the cloud
Posted by peter on Jun 6, 2012 in Portfolio | 0 commentsThere is no way around it, cloud computing is here to stay. And, while cloud’s scalability and flexibility represent a host of new opportunities for businesses of all sizes, the increasingly popular operating model also shines a bright light on the need to address potentially dangerous security implications. After all, as organizations add cloud services to the IT mix, it extends the vulnerability surface of any enterprise to include providers’ risks.
“Fortunately, proper encryption addresses the issue, but businesses today must look beyond standard protocol,” says Mushegh Hakhinian, CISSP, a security architect at IntraLinks Inc., New York, U.S.A. “Instead, customer data must be encrypted both at-rest and in-transit.”
ESTABLISHING EXPECTATIONS
Depending on the maturity of the service, providers must have in-use protection options for highly sensitive documents, explains Hakhinian. “This is required to ensure that users cannot have unencrypted copies of those documents cached on their end devices,” he says, such as laptops, tablets, etc. “Some providers require that their customers maintain an encryption key that can be used to decrypt their data. This is a great framework if the customer has the expertise and resources to properly manage the key, and the provider has a secure key-exchange mechanism.”
While most cloud vendors offer encryption of the virtual image, physical hard disk encryption and encryption of backups, most lack offerings around encryption of unstructured or structured data, explains Gary Loveland, principal and national security leader at PricewaterhouseCoopers (PwC) LLC, headquartered New York, U.S.A. “This is important because companies often have requirements around encryption of sensitive information in files and databases,” he says. “Before moving this data into the cloud, a company must evaluate how to integrate their encryption solution [such as RSA] onto a virtualized cloud image. Alternatively, they can rely on the inherent database encryption capabilities of MS SQL and Oracle.”
For either public or private cloud offerings, SSL/TLS should be a standard offering for the management of the servers, explains Loveland. “The dedicated private cloud adds another layer of protection since the traffic is not routed over the public Internet,” he says. “Encryption in-flight is the most standard and mature offering, and the encryption of the data-at-rest is where it gets interesting. Ideally, IT would like to have the same controls and reporting that exist in-house when migrating data into the cloud. However, the challenge is in integrating the in-house security tools that can be deployed to the cloud with the security offerings of the cloud vendor—for the right costs, of course.”
IT should also have the right to demand business – class implementation of cryptography to protect its data, explains Hakhinian. “Proper encryption means strong and vetted algorithms, reasonably long keys [randomly generated to the full length] and a multilayer key management system,” he says. “Consumer-oriented systems may not have these stringent requirements, but given the natural tendency of IT consumerization, the market will reward forward-thinking vendors who make the investment to implement encryption the right way.”
KEY CONCERNS
In a cloud environment, the number of layers makes it difficult to compile a definitive list of everyone with administrative access who could potentially have access to both the data and/or the encryption keys, explains Loveland. “This information would be needed for a variety of audit and compliance activities such as PCI,” he says. “Because of the connected system provision in the standard, one must take great care in architecting any solution that puts cardholder information on the cloud because of the potential for everything to be a connected system.”
Another challenge that is further complicated in the cloud environment is the management of the encryption keys. For instance, if the provider allows for encrypting the file system of each virtualized image, the key management procedures would need to be clearly defined in the service-level agreement (SLA). “This brings up a number of questions you need to address up front,” says Loveland. “How do they manage the key for each system? How do they keep it separate from all their other clients? How often [is it even possible] to revoke/rotate keys?”
Challenges also exist around monitoring the access to data within a cloud provider, explains Loveland. “With in-house solutions, it is possible to hook in monitoring solutions. When moving to the cloud, there has to be an investigation into the compatibility of the solutions,” he says. “It can’t be assumed that just because data is encrypted, it is safe. Monitoring is a key piece of protecting the data.”
In this scenario, Hakhinian also recommends securing assurances that vendor employees can only access customer data in a number of well-defined, limited cases, and even then only with the customer’s express consent. “If this clause is absent or there is language present such as to provide better service support, personnel may access customer data. Without a way to prohibit that access, it should raise a red flag in the customer’s mind,” he says. An alternative is to manage all the encryption components in-house before sending the data to the cloud provider. In this architecture, there would be an encryption appliance that sits on the corporate network responsible for encrypting all database information.
“This would require the dedicated network cloud option because the encryption appliance should not be exposed to the Internet,” says Loveland. “All database queries would be routed through this appliance so that even when the data is at rest on the cloud provider’s systems, it would still be encrypted. The challenge here is the need to rearchitect the database to accommodate encrypted data [nonstandard character set and expanded field size].”
PROPER PERSPECTIVE
While encryption is an obvious technology solution to include in how organizations develop and implement their information security program, many companies have not authored their internal security management programs with the flexibility to move between internal controls and controls that must be installed and used on a distributed platform (such as that which cloud-based service providers deliver to their clients), explains Jeffrey Ritter, founder and CEO of the Ritter Academy, Reston, Va., U.S.A. “Much of information security is still oriented toward defending the castle. What is required is a reorientation to the multidimensional, multilocational nature of 21st century computing, in which many resources are contracted, not owned or employed,” Ritter says. “As a result, the security program must be architected toward managing all of those resources. So, encryption has always been important, but now we have to engineer into its management the flexibility to adapt to cloud services.”
Sidebar: Six Steps to SLA Success
Unfortunately, SLAs are often drafted and finalized without the realization that they are part of the overall commercial agreement between the parties. “As a result, the SLA’s technical features are not connected well to the overall content of the legal agreement,” says Jeffrey Ritter, founder and CEO of the Ritter Academy. “The agreements themselves are often antiquated, drafted by lawyers to focus on adverse events and defaults, rather than emphasizing the collaborative governance of an interdependent relationship.”
To help ensure effective, enforceable SLAs, Ritter provides the following six-step, rules-based design:
WHO IS THE ACTOR? The rule must clearly identify who needs to take action, or refrain from prohibited conduct. Today, that actor may be an employee or service provider, so the rule must be flexible enough that it applies to both.
WHAT ARE THE CONDITIONS, AND WHEN DO THE RULES APPLY? For encryption, there are many branching scenarios. As such, it’s crucial to investigate and map each avenue.
WHAT IS THE ACTION? Every rule tells someone to do something with some asset. This level of precision is necessary for rules to be capable of meeting the remaining steps.
HOW DO YOU MEASURE ACTIONS? Thoroughly establish what represents success and failure—and what type of data both parties are utilizing.
HOW DO YOU MANAGE MEASURED PERFORMANCE? So often, companies author rules without contemplating the resources needed to manage performance. By answering this question, security is asking what resources are required to provide effective management. For managing cloud providers, many companies overlook the practical reality that this task requires resources. When the resources are not allocated, including taking action on the reports of performance, service errors are not effectively addressed.
HOW WILL PERFORMANCE BE REWARDED OR SANCTIONED? Most rules, especially in legal contracts, only focus on termination or default. Yet, in reality, most service relationships are not easily terminated. It is far more effective to fix service errors and continue on. And, you should still reward or sanction performance, either by providing bonuses or chargebacks. When the agreement and SLA fail to make the carrot and the stick visible, driving consistent performance is almost impossible.
“For implementing encryption, these six steps not only improve internal management, but also enable the portfolio of encryption rules to be more effectively shared across cloud service providers,” Ritter says.
Initially appeared in Infosecurity Professional Issue 18