Cloud Encryption and PCI thoughts

There is a lot of guidance and expertise on achieving PCI compliance. In virtualized and cloud computing environments it is trickier, yet a lot of expertise is building up there as well. Witness the venerable PCI Security Standards organization and its guideline for virtualization, which includes a section on cloud computing as well.

Yet in some areas, answers are still sketchy. Some of the most important issues are cloud encryption and key management.

Cloud encryption is obvious – or is it?

Everyone understands that achieving PCI DSS requires encryption or tokenization of sensitive data, such as credit card numbers or personal details. This is even true in physical data centers; it is certainly true for virtualized and cloud computing environments.

So cloud encryption is an obvious necessity. Case closed.

But it is not so simple.

One issue is that any encryption scheme requires encryption keys; and keeping those encryption keys secure in the cloud is not easy.

A second point is that servers working in the cloud (and providing a service) have memory in the cloud. Data in memory also needs to be secured.

Cloud key management

Where to save encryption keys? The best practice for securing encryption keys available today is split-key management. This means that every encryption key is split in two; the first part, a “master key” remains the sole possession of the application owner and is unknown to anyone else. The second part is different for each data object and is stored by a dedicated cloud key management service (read more about it in this white paper).

Such techniques provide a solution to securing the encryption keys, which provides security on a par with physical data centers.

Memory protection and users’ permissions are critical in the cloud

Protecting the RAM of a server is something that is (almost) never seen as an issue in physical data centers. In the cloud, it is increasingly discussed.

The best modern clouds allow memory access to be tightly controlled. Here are some tips on how to control access to memory.

First and most basic rule: by default, no human has permission to do anything in memory. In practical terms, this means there is no access at all to the virtual box. In techie terms, this means protocols like SSH or RDP are disabled by default.

Starting from that, you add on permissions in a very limiting way. There are three classes of people worth considering: “super” administrators, regular administrators, and end-users of the system.

“Super” administrators need not always exist (analyze your own system to decide if you need them). If they do, they should be very few, and ideally only two people together (for example, each of them knows one half of a password). “Super” admins, if they exist, can make major changes in permissions of the system. Make sure you trust them.

Most of the everyday technical work on a system is done by regular administrators. These essential people should not be all powerful. In fact, in some important ways they should be “weaker” than end- users. In particular:

• They do not have any master passwords or “root” user access; rather they access systems with admin rights which are limited in scope
• Some of the important limitations: they cannot change permissions on the system (including their own permissions), they cannot see any end-user data (e.g. in a database system, they cannot do regular ‘select’ statements)
• Every access is logged and audited
• The logging and auditing sub-system is not accessible to them (and cannot be changed by them); typically the logging and auditing sub-system will be under ”root” control, and these users do not have root access

End-users, on the other hand, do have access to their own data. In that sense they are more powerful than admins. But they do not have any access to the virtual server “box”, only to the application. They are purely application users.

The tricky issues of PCI compliance, encryption and key management in the cloud are soluble. Feel free to contact us for a deeper discussion.