If you missed the recent RSA Conference--that annual Woodstock for security professionals worldwide--all you need to do is put the words cloud, security and compliance in a sentence with just about any verb and you can pretend you were there.
The cloud is all the rage in corporate computing, and with good reason: It promises to significantly reduce your IT infrastructure investment and operating costs while improving availability. The issue for merchants is how to maintain security and validate PCI compliance in this brave new world of cloud computing. Are PCI and the cloud incompatible? Maybe the best place to start answering that question is by asking two more: What is so new about the cloud, and is it secure? But the ultimate question is, What does it do to my PCI scope?
The concept behind cloud computing is not new. It takes advantage of shared resources to give you, the user, the most bang for your computing buck. The cloud is like an updated version of 1970s timesharing, when users had dumb terminals connected over phone lines to remote mainframe computers that stored their data and applications.
The computing pendulum swung away from the centralized model toward desktop computing in the 1980s, with the acceptance of personal computers and the client/server model. With the spread of the Internet, cloud computing is moving us back to a centralized computing model--but one where the network, data and applications are all remote, that is, in the “cloud.” Other than the technology, there is not a lot new here.
If the cloud is not new, neither is the issue of security. If you consider the top security threats from cloud computing, you will find that they sound pretty familiar: improper use; insecure applications; malicious insiders; shared technology (for example, virtualization) vulnerabilities; data loss; and account hijacking. So the questions are the same. What has changed is the context.
CIOs need to assess the security of cloud packages as they evaluate what to move and when to move it to the cloud. The biggest security hurdle seems to be the transparency, interoperability and auditability of the cloud provider. That is, do you as CIO understand fully how and where your data are stored, what you will do if your cloud provider goes out of business, and whether you can adequately audit its performance?
Unfortunately, we have no reliable third-party seal of approval or assessment of cloud providers. And marketing hype is not going to fill that gap.
From a PCI compliance perspective, it all comes down to scope. That is, although the technology--primarily virtualization--may be new, the compliance concerns you need to address (see above) are the same. You need (hopefully together with your QSA) to tell the story of how you are meeting PCI requirements in the cloud.
What will you move to the cloud? It might be cardholder data, a payment application or another application that uses the cardholder data. Possibly your development system or even network will be in the cloud. Your decision will greatly determine what part of your PCI scope is in the cloud. It also helps to know what kind of cloud you are using: public, private or some combination of the two.The PCI Council is still addressing virtualization and its role in PCI-compliant approaches. As such, there may be some uncertainty about the ultimate acceptance of cloud computing. That uncertainty should be lifted soon, hopefully no later than the announcement of the revised PCI DSS this fall (or May for Participating Organizations).
Once your scope is addressed, you can tackle the other PCI questions, like separation of duties, encryption, key management, governance and the ability to conduct forensic investigation. You also will need to include due diligence of your cloud provider in your procedures for engaging a new service provider (Requirement 12.8). Personally, I’d like to know who else is sharing “my” cloud.
Again, the PCI compliance questions are the same. It is only the context, and maybe the technology of the answer, that will change.
When you look at the cloud, keep your security expectations realistic. Don’t expect 100 percent security. You don’t have 100 percent security anywhere, so don’t expect it in the cloud. What you want is the same, hopefully very high, level of security you have now or maybe a little higher.
At RSA, I heard one speaker make the argument that cardholder data might actually be more secure in the cloud because all the sensitive data would be in one place, albeit a cloud, and not spread across the enterprise as we often see today. He reasoned that the data would, therefore, be easier to monitor and manage. This is an intriguing argument, and with proper controls and auditability I can see how it might make some sense. Then again, it's also creating an extremely tempting target.
Going beyond PCI, I would want to have a service level agreement (SLA) that includes notification of any security or data breach of the cloud provider. It may not affect your own data (or network or application or development platform) directly, but the SLA should ensure that you know about any breach promptly. I also suggest you make sure that if the authorities subpoena or even confiscate an entire server to get the records for another company sharing the cloud with you (it has happened!), your business will not be interrupted.
The cloud might be the ultimate form of outsourcing, and outsourcing is a good way to reduce your PCI scope. On one level, cloud computing is an updated, Internet-based version of the old timesharing model. Certainly there are risks.
Regardless of whether the cloud is new or not, the PCI and security questions you have to address remain the same. It is just the context in which you answer these questions that is different and perhaps a bit challenging. In many ways, the users are ready. It is the cloud providers that need to get their security and compliance act together.
Are you “in the cloud” yet? Are you considering it? What data, applications or activities would you put there? I’d like to hear your thoughts. Either leave a comment or E-mail me at [email protected].