PCI - Data at rest encryption and 3.4.1

Even if the encryption stuff is still the most discussed issue on PCI, I still have concerns about the correct interpretation of 3.4.1. There is even some attempt of clarification in the PCI SSC FAQ about that, but IMHO it doesn't accomplish anything close to "clarify" the issue. From the FAQ:

"The intent of this requirement is to address the acceptability of disk encryption for rendering cardholder data unreadable. Disk encryption encrypts data stored on a  computer's mass storage and automatically decrypts the information when an authorized user requests it. Disk-encryption systems intercept operating system read and write operations and carry out the appropriate cryptographic transformations without any special action by the user other than supplying a password or pass phrase at the beginning of a session. Based on these characteristics of disk encryption, to be compliant with this requirement, the disk encryption method cannot have:

1) A direct association with the operating system, or

2) Decryption keys that are associated with user accounts."

It seems to me that the intent of the requirement is to protect the data from being directly accessed from the media (hard drives); otherwise, disk encryption wouldn't be enough even if it is completely managed out of the OS.

If the intent is to use encryption as an additional access control and segregation of duties mechanism, disk encryption would never be useful even if it's done out of the OS and without linking the keys to user accounts; take, for instance, SAN based encryption. It's completely independent of the OS and the keys are not linked to user accounts; so, it meets the requirement. However, it doesn't accomplish much in terms of risk reduction (besides protecting data in the media), as the control of who can access the data in clear is still entirely managed by the Operating System (the data is presented in clear by the underlying SAN system to the OS).

It's funny to see that file or application level encryption vendors defend that only those approaches can meet the requirement, while storage vendors say exactly the opposite.

There is the general instruction to consider the requirement's intent. Again, I'm not sure there's enough clarity around the intent of requirement 3.4.1 - Does it try to protect against bypassing the Operating System controls logically (by getting administrator/root level access at the box containing the data) or physically (getting physical access to the media/disks containing the data)?

The implications from saying one or the other are quite big. Storage based encryption won't protect against someone getting root access on the OS, as the data is being provided in clear from the Storage system to the OS, so the attacker has open access to it. However, it still protects against someone grabbing (or getting physical access to) a hard drive (or even the whole array, depending on how the encryption is implemented by the storage system).

SAN based encryption is not performed by the OS and the keys are not linked to user accounts. In a crude interpretation, it meets the requirement. However, does it meet the original intent?

The PCI Council usually replies to questions with "work together with your QSA". That's great, but there are some requirements that are being interpreted by QSAs in completely opposite ways, such as this one. For some cases some additional guidance has been provided by the Council, such as for IP telephony systems and virtualization. I believe the encryption at rest requirement requires (the requirement requires...funny wording :-)) additional clarification too. The last version of PCI also requires a risk management program, so one could argue that the chosen solution should be aligned to the results of the risk management process. I’m not sure the PCI Council wants to leave such sensitive issue subject to decisions based on the organization’s risk appetite. As we know, the economics of payment card data security usually put the risk appetite of the organization and cardholder data security at opposite corners.

(there’s a very good document produced by the Securosis guys about this; you can find it here.)