There are a lot of security professionals and lay people that seem to believe that encryption is encryption and that is simply not the case. Worse yet, vendors play into this misconception and obfuscate the issue with lots of words and phrases discussing seemingly complicated encryption key management procedures and the like that are actually meaningless when it comes to protecting data on running systems. As a result, it is time to clarify all of this misunderstanding.
First things first, we need to discuss how whole disk encryption works. As its name implies, whole disk encryption encrypts an entire disk drive. When a file on the whole disk encrypted drive is accessed, the encryption solution decrypts the file necessary using the decryption key provided at system startup and the rest of the drive remains encrypted. That way if a system failure occurs or the system is shutdown deliberately, the drive is always protected.
That is the key concept of whole disk encryption. The drive is technically only encrypted when the system is shutdown. If the system is running, the encryption is technically not in place because the operating system has the decryption key to access the disk at will. This is why whole disk encryption is great for devices like notebooks and the like that are shutdown at some point.
This is also why whole disk encryption is meaningless when applied to a server. When is a server shut down? Never. When using whole disk encryption on a running server, the only control that protects data is access controls, not encryption.
So using this definition, let us examine requirement 3.4.1 in the PCI DSS. That requirement states:
“If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts.”
The first statement that throws people is “logical access must be managed separately and independently of native operating system authentication and access control mechanisms”. In short, whole disk encryption cannot rely only on the operating system’s authentication process.
The best example of this is Microsoft BitLocker. BitLocker has a number of modes under which it can operate. It can integrate with Active Directory (AD), it can rely on a trusted platform module (TPM) chip in the computer or it can operate stand-alone.
In stand-alone mode, BitLocker requires the user to provide the BitLocker key by either manually keying it in or providing it on a USB device that stores the BitLocker key in order to boot the system. If that key is not provided, the system will not even offer the user to logon. This form of BitLocker meets the requirements set forth in requirement 3.4.1.
But then the requirement goes on and say, “Decryption keys must not be associated with user accounts”.
In stand-alone mode, the BitLocker key is not associated with the user’s credentials so it also meets this part of 3.4.1.
However, in the AD or TPM modes, BitLocker operates behind the scenes and the end user never knows that their disk is encrypted and the user still logs onto the system as always using their Windows credentials. These modes do not meet the independence requirement in 3.4.1 because all that is protecting the data is the user’s Windows credentials. And in the case of AD mode, BitLocker also does not meet the user credential disassociation requirement because the BitLocker decryption key is tied to the user’s Windows credentials.
But if people would fully read the Guidance column for requirement 3.4.1 they would read the following at the end of the guidance for 3.4.1 where the Council states:
“Full disk encryption helps to protect data in the event of physical loss of a disk and therefore may be appropriate for portable devices that store cardholder data.”
BINGO!
Whole disk encryption helps protect data in the event of physical loss of a disk. Period.
So with a server that never shuts down, if a drive in a SAN or NAS fails, the failed disk with whole disk encryption will be encrypted when it is pulled from the array. But if things are running just fine, whole disk encryption does nothing to protect the data.
So do not be baffled by the statements from those vendors trying to convince you that whole disk encryption on your server is going to protect your data while the server is running. That is not true.
Now you know.
PCI Guru 
What is your take on SAN encryption, where the organization is battling with encryption at a layer higher in the stack (Application, Database, File etc.) but want to implement it on the SAN layer, considering the vendors of these products claim their SAN solutions are PCI compliant often time with an acceptable key management implementation? still the SAN is automatically decrypted to all users.
Most SANs are shipped these days with RAID5 and encrypted at their base level so that when a HDD/SDD is replaced the vendor never has access to whatever is stored on the disk. Customers then lay out their disk on top of that base. It is that initial base that is compliant with requirement 3.4.1 but does not protect data which the customer’s applications and users have access. It is up to the customer to implement their own encryption to protect the data used by their applications and users.
This is my thinking: In summary SAN HCI Encryption/D@RE satisfies 3.4.1, the moment user and application data comes into play then other requirements like access (requirement 7) will require more controls such as access restrictions or logical separation to avoid unauthorized access.
Yes, that satisfies 3.4.1, but does NOT protect the data unless the SAN disk is removed. So the other encryption requirements are NOT covered just because you met 3.4.1.
Hi, would like to clarify a few things:
Q1. In version 3.2 requirement 3.4.1 stated that “If disk encryption is used (rather than file- or column-level database encryption)”, and at the guideline it mentioned “The intent of this requirement is to address the acceptability of disk-level encryption for rendering cardholder data unreadable”. To me it read like it is some kind of alternative protection to PAN while file & column level database encryption NOT implemented, and it address the acceptability for rendering cardholder data unreadable (requirement 3.4).
So my question is, can I claim compliance of requirement 3.4 as long as I fulfill requirement 3.4.1?
Q2. “Full disk encryption helps to protect data in the event of physical loss of a disk and therefore may be appropriate for portable devices that store cardholder data.”
Does this statement make the protection inappropriate for non-portable devices (e.g. Server or SAN)?
Thanks
Q1 – Nope! Whole disk encryption ONLY protects PAN when a device is NOT running. When exactly is a server NOT running? Hardly ever. You still need to encrypt the PAN or just get rid of it all together using tokens.
Q2 – See my answer to Q1 What whole disk encryption protects is if a drive crashes in a SAN or NAS.
Hi, interesting topic. But I have one question. If I use a disk encryption system that do not mmet the req. 3.4.1, do I need to have a CCW in place?
Any feedback would be appreciated. Thanks
Requirement 3.4.1 might be not applicable. I would have to know a LOT more about what we are talking about before I could provide any definitive guidance.
I definitely share Jeff’s opinion about disk encryption applicability to physical loss of HDD. Transparent Disk Encryption does not mitigate CHD exfiltration if the server gets compromised; from a QSA standpoint and in many audits I have conducted if the company keeps CHD safe by rending it unreadable using any of the four methods provided in 3.4 I mark as not applicable 3.4.1
“And in the case of AD mode, BitLocker also does not meet the user credential disassociation requirement because the BitLocker decryption key is tied to the user’s Windows credentials.”
Not strictly true. With the right GPOs in place, the bitlocker key is written back to AD for safe keeping. This key is written to the computer object. Not the user object.
Regardless of method, the AD integration method is still not approved because if the attacker has the device, the only thing that is protecting the encryption are the user’s credentials because there is no prompt for a passphrase for BitLocker when it is integrated with AD.
In a scenario where CHD is not stored, it is simply processed/transmitted via web transaction and POS devices, is 3.4.1 applicable?
As long as you have confirmed what you are saying, then 3.4.1 is not applicable.
Thank you.
Great article. Thank you very much for that interesting point of view. Does the similar train of thoughts apply for TDE encryption mechanisms for databases?
TDE (transparent data encryption) is done at the file level, not the whole disk level. TDE works great when only the application is the “user” that can decrypt. Not so good when individual users can decrypt. That is because if a user can decrypt, they have access to all data that they have views for which likely can include sensitive data.
But TDE implementation could be compliant with 3.4.1 if and only if defined user is only for the application itself? what about DBAs?
DBAs are where TDE usually is not enforced because they are DBAs and need to see the raw data to address any problems. Same could also be said of developers that may also have the same access as DBAs.
Sure, for DBA’s makes sense that TDE is not enforced, nevertheless, every CHD accessed by DBAs should be logged and audit trails must be in place. For developers, according to requirement 6, they can not have access to production data. Thanks again PCIGuru.
But developers do occasionally end up “looking” at production and should be handled the same as DBAs. Just saying. 😉
😂 Well… in theory they do not! but coming from a developers perspective myself, we “ocassionally” take a peek at production data. Cheers!
A “peek”? I know of developers that take much more than a “peek”. LOL!
Interesting reading – i am looking for file level encryption – similair to EFS in a windows SAN/NAS environment – my client wants all their SAN/NAS data encrypted, we have offered D@RE (Disk At Rest) from the EMC SAN level , but this looks just like Bitlocker – ie. only encrypted when disk is removed.
They currently use EFS – but i have told them that this is not really secure as there are 3rd party companies selling products that can decrypt the files without the keys
(https://www.elcomsoft.com/aefsdr.html)
So the client still wants the file level encryption and i have no idea what to offer in an enterprise environment – AES Crypt / VeraCrypt ???
EFS is not secure? I use Elcomsoft’s products and Elcomsoft would have to run a brute force attack against a properly generated EFS key. So it would take quite a while (probably more than a lifetime) to break a EFS key if it is properly generated.
And that is the real key to encryption (no pun intended), key management. Keys must be strong (long – 32 characters or more, and complex), properly secured (encrypted) and stored away (key server) from the objects they secure. Proper key management will ensure that tools such as Elcomsoft do not have a chance at breaking EFS.
If you are still concerned about EFS, look at Symantec’s file encryption solutions for another commercial solution.
So why would Elcomsoft provide a product thats mentions —
” Advanced EFS Data Recovery decrypts the protected files, and works in all versions of Windows 2000, XP, 2003, Vista, Windows 7, Windows 8, Windows 8.1, Windows Server 2008, Windows Server 2012. The recovery is still possible even when the system damaged, is not bootable, or when some encryption keys have been tampered with.
Advanced EFS Data Recovery recovers EFS-encrypted data that becomes inaccessible because of system administration errors such as removing users and user profiles, misconfiguring data recovery authorities, transferring users between domains, or moving hard disks to a different PC.
–
Advanced EFS Data Recovery locates the encrypted files as well as the available encryption keys, and decrypts the protected files. The direct access to the file system allows Advanced EFS Data Recovery to recover encrypted files in the most difficult cases even if the disk with data is only available without a valid user account to login into system, or when some encryption keys have been tampered with.”
==================
EFS is not secure?
I was on a MS course and talking about encryption access etc – i mentioned accessing EFS files and the whole class nearly fell over laughing .. the lecturer mentioned that it was not secure/certified – Govt dosnt approve it etc.. he mentioned using AD RMS instead
What has not been approved is the use of EFS as a whole disk encryption solution. However as a file/folder solution, it has been my understanding that EFS is sufficient as long as you use AES as your algorithm and also proper key management processes.
Thanks for the article, just one question – at first we are saying that 3.4.1 is not met when using AD to access the encrypted drive. The guidance makes it clear this requirement is meant to help protect data in the event of physical loss. Does that mean using AD is ok while the server is running, or does there still need to be a separate access mechanism for the encrypted drive while the server is running?
Any feedback would be appreciated.
Whole disk encryption is only protecting data when a device is shutdown. In the case of a server, whole disk encryption only provides protection when a disk is removed, never while the server and disk are running. Therefore, if you want to protect stored data such as a PAN, you need to use a different encryption method such as file level, folder level or column level encryption in addition to access controls. Those access controls could be provided by Active Directory (AD) or by the application.
So, does anyone have an example of a product that would meet this requirement? Most of the products that I have looked at integrate with the operating system. Either local accounts or through AD.
I was able to use non-OS/AD accounts on an older version of symantec pgp. The newer versions use the local user database.
Symantec and ESET are the only vendors I am aware that have Enterprise whole disk encryption solutions similar to AD/Bitlocker but independent of the operating and authentication systems.
So does this mean that if I pull the disk out on a running computer and hook it up to another comuter via a usb doc will it be unencripted
If you have implemented whole disk encryption properly, no you will not be able to read the disk unless you have the encryption key.
Reblogged this on oogenhand.
Can we then conclude that requirement 3.4.1 sole objective is disk theft or loss ?
Meaning, that is the risk to cover, either in applying directly the control or by demonstrating an adequacy in a risk analysis
I think that it is safe to say that 3.4.1 is all about the physical loss of HDD/SDD.
Nicely explained