Data Compliance and Cloud Computing Collide: Key Questions

Forrester has been putting out really interesting reports on cloud computing lately. I discussed one of them in a recent post entitled "Cloud Computing: Whose Crystal Ball is Correct," which addressed the topic of private clouds. In that post, I examined Forrester's James Staten's point that implementing private cloud computing requires far more than buying vSphere and a few add-on modules—it requires standardization, process re-engineering, and organizational alignment.

This week brought another excellent report from Forrester, "Compliance with Cloud: Caveat Emptor," written by Dr. Chenxi Wang, exploring the challenges raised by the collision between data compliance requirements and cloud computing real-world offerings.

As Dr. Wang notes, most data compliance laws and regulation are written with an assumption that the liable party controls the infrastructure data is stored on as well as the placement decision about where that storage is located. Practically none of the laws and regulations recognize that a service provider may hold the data on behalf of the liable organization. Therefore, most compliance situations assign all of the responsibility to the user of a cloud computing environment despite the manifest fact that much of the control of the data is out of the hands of the user.

Several things about Dr. Wang's analysis stood out to me:

1. It may be easier to learn where an IaaS provider's data centers (and therefore, data storage location) are than for an SaaS provider. Google (GOOG) is identified in the report as not being able to state, definitively, where one's data is hosted or that its location will be restricted to any given region. Obviously, any opaqueness about location causes a real problem for users to ascertain if they are in compliance with applicable laws and regulations.

2. Only one law is identified as specifically recognizing the role of a service provider—HITECH for HIPAA. All other laws and regulations leave all of the responsibility with the user. At HyperStratus, we refer to this situation as asymmetric risk —despite the fact that compliance is a shared responsibility, most or all of the risk falls upon the user.

3. Those who trumpet that cloud providers accept responsibility for legal compliance measures overlook an obvious difficulty—cloud providers often don't know what data is being stored in their infrastructure and can't know what legal conditions apply to the data.

For a company like Amazon, the fact that someone can begin executing a cloud-based application with nothing more than a credit card and an account id means that it has no way to validate (or indeed, even understand) an application's compliance requirement. This is worth repeating—absent a discussion, there is no way for a cloud provider to have any idea what measures should be taken for compliance reasons—so insisting the cloud provider step up and meet compliance requirements may be unrealistic.

Continue Reading

http://www.cio.com/article/612063/Data_Compliance_and_Cloud_Computing_Collide_Key_Questions?source=rss_cloud_computing


Join Us: http://bit.ly/joincloud

Cloud Computing: Would PCI Compliance Help or Hurt Security?

Can cloud computing environments meet PCI compliance standards? Security experts say they can't answer that question yet. But the bigger question is whether meeting PCI standards would actually improve cloud security.

These days it's not that great a compliment to say something's as safe as banks, let alone credit cards or those swipe-card readers at the convenience store.

Still, the possibility—raised in the press and on user forums—that cloud security would be included in the most recent update of the ubiquitous Payment Card Industry's Data Security Standards (PCI DSS) sparked debates on whether requirements designed to protect credit-card data would actually make cloud services less secure.
"PCI can give you a baseline of things you can use to measure security, and some people overuse it for that, according to Josh Corman, analyst at The 451 Group. "The problem is the requirements are specific, but only for the parts of your system that you use to process credit cards. If I were shot dead in an alley but the mugger couldn't get my credit cards, the PCI standards would be satisfied."

Every merchant in the U.S. that accepts credit cards must comply with PCI requirements, which become more stringent as the volume of transactions rises. The rules cover 12 major categories, including encryption of credit-card data at the point of sale, during transmission to clearinghouses, and physical security of data centers where credit-card data are stored.

PCI Lacks Virtualization Specifics

Even PCI-compliant merchants don't like the standard much, however, according to a 2009 study from the Ponemon Institute, which found only 29 percent consider it a strategic initiative. 44 percent think it improves security and 60 percent lack the budget to be fully compliant, according to Ponemon's data.
Small- and mid-sized companies actually improve security moving to clouds, which are professionally managed and secured, concluded a September study from the Fraunhofer Institute for Secure Information Technology.
Today, there is literally no way to know if even a secure system could pass a PCI audit if it were based in a cloud, because there are no specific standards for virtual environments of any kind, Corman says.
The PCI Security Standards Council is indeed releasing updates to its standards, including more detailed guidance on how to secure contactless payments using EMV chips in credit cards.
However, the council will not offer much help defining how to secure credit-card or any other data on virtual infrastructures or cloud environments, according to Bob Russo, general manager of the council.
The council does have a group working on virtualization "of which cloud computing is one type," but "at this time the Council does not have plans to release separate guidance on cloud computing," Russo says in an e-mail responding to questions.

Continue Reading

Join Us: http://bit.ly/joincloud

What's Wrong with the PCI Security Standard

The security standard used to protect credit cards isn't up to the task and upgrades that are planned for this fall do virtually nothing to improve it, a security expert told Interop attendees this week.

Not only that, the so called payment card industry data security standard (PCI DSS) is driving what businesses spend their security money on, which is not necessarily the same set of things they would do to best protect their assets, said Josh Corman, research director in the enterprise security practice of The 451 Group.

One of the glaring shortcomings of PCI DSS is that it doesn't address cloud computing at all, leaving businesses interested in the cost savings promised by the cloud unable to use it in a way that complies. And the draft of the changes that go into effect this fall that Corman has seen don't address cloud, either, he said.

The problem is that with pinched budgets, CIOs and CISOs are forced to limit their security budgets. Since PCI DSS is mandatory for anyone handling credit card data, its requirements are being met, often at the expense of other measures, Corman said.

"PCI has created budgets where there were none," Corman said. A common belief is that IT security is recession proof, but PCI compliance has forced much of the spending that might have been cut otherwise. "It's probably more accurate to say compliance made [security] recession proof," he said.

PCI DSS may or may not do a good job of protecting credit card data, but it definitely doesn't do the best job of protecting all corporate assets based on their value to the corporation, Corman said. "PCI is not meant to protect [your business], it's meant to protect the data you have become responsible for," he said. "The [qualified security assessor] isn't protecting the herbs and spices for the colonel; he protects the credit cards."

The impression within the industry, though, is that PCI DSS is a standard that if applied to any business network will adequately secure it. And since PCI DSS is mandated for many businesses, it sets the bar – perhaps not a very high one – for adequate security, Corman said. Many security executives he talks to say much of their spending is driven by making sure the business can pass a PCI DSS security audit, not that the riskiest assets are protected. "We now fear the auditor more than the attacker. Is that a good thing?" Corman said.

Original Article - CIO.com

Join Us: http://bit.ly/joincloud

Cloud Balancing, Reverse Cloud Bursting, and Staying PCI-Compliant

One of the concerns with cloud bursting specifically for the use of addressing seasonal scaling needs is that cloud computing environments are not necessarily PCI-friendly. But there may be a solution that allows the application to maintain its PCI-compliance and still make use of cloud computing environments for seasonal scaling efficiency. 

Cloud bursting, a.k.a. overdraft protection, is a great concept but in some situations, such as those involving PCI-compliance, it can be difficult if not impossible to actually implement. The financial advantages to cloud bursting for organizations requiring additional capacity on only a seasonal basis are well understood, but the regulatory issues that surround such implementations hinder adoption of this method to address cost-effective capacity increases when necessarily only for short periods of time.

But what if we architected a solution based on cloud bursting that offers the same type of advantages without compromising compliance with regulations and guidelines like PCI-DSS?

---

REVERSE CLOUD BURSTING and CLOUD BALANCING 

---

The ability to implement such an architecture would require that the PCI-compliant portions of a web application are separated (somehow, perhaps as SOA services or independently accessible RESTful services) from the rest of the application.
The non-PCI related portions of the application are cloned and deployed in a cloud environment. The PCI-related portions stay right where they are. As the PCI related portions are likely less heavily stressed even by seasonal spikes in demand, it is assumed that the available corporate compute resources will suffice to maintain availability during a spike, mainly because the PCI compliant resources have at their disposal all local resources. It is also possible –and likely – that the PCI-related portions of the application will not consume all available corporate compute resources, which means there is some capacity available to essentially reverse cloud burst into the corporate resources if necessary.

In a very simple scenario, the global server load balancer basically "reverses" the priority of data centers when answering queries during the time period in which you expect to see spikes. So all application requests are directed to the cloud computing provider's instance first except for queries that require the PCI-compliant portion, which are always directed to the corporate (cloud computing perhaps) instance. This is basically a "cloud balancing" scenario: distributing application requests intelligently between two cloud computing environments.

The variations on this theme can become more complex and factor in many more variables. For example, you could set a threshold of capacity on the corporate data center instance that allows enough corporate compute resources available to handle the highest expected transaction rate and only burst into the cloud if the corporate capacity reaches that level. That's traditional "cloud bursting." You could also reverse the burst by dipping into corporate compute resources based on thresholds designated at the cloud computing provider's instance to minimize the financial impact of utilizing a cloud computing provider as the primary delivery mechanism for the application. That would be "reverse cloud bursting." The key is to ensure that no matter where the compute resources are coming from for the primary application components it does not negatively impact the availability and performance of the PCI-compliant processes executing in the corporate cloud environment.

---

THE KEY IS FLEXIBILITY IN ARCHITECTURE

---

Without the flexibility to deploy individual components of an application (a.k.a. services) into different environments these scenarios simply don't work. Applications developed based on tightly-coupled frameworks and principles will never truly be capable of taking advantage of cloud balancing, bursting, or any architecture that relies upon specific components residing in a specific location because of regulatory issues or other concerns.

This is one of the core principles of SOA – separation of not only interface from implementation, but location-agnosticism. There are many ways to achieve this kind of location-agnosticism including on-demand generation of WSDL for client consumption that specifies end-point location based on the context of the initial request and the use of global server load balancing combined with context-aware application delivery. What's vitally important, though, is the flexibility of the underlying application architecture and the ability to separate components in a way that makes it possible to distribute across multiple locations in the first place.
If that means SOA is the answer, then SOA is the answer. If that means a well-designed set of RESTful components, so be it. Whatever is going to fit into your organizational development and architectural practices is the right answer, as long as the answer includes "location agnosticism" and loosely-coupled applications. Once you've got that down the possibilities for how to leverage external and internal cloud computing environments is limited only by your imagination and, as always, your budget.