[PCI-DSS] 3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control mechanisms (for example, by not using local user account databases). Decryption keys must not be tied to user accounts.
[ul]
[li]3.4.1.a If disk encryption is used, verify that logical access to encrypted file systems is implemented via a mechanism that is separate from the native operating systems mechanism (for example, not using local user account databases).[/li][li]3.4.1.b Verify that cryptographic keys are stored securely (for example, stored on removable media that is adequately protected with strong access controls).[/li][li]3.4.1.c Verify that cardholder data on removable media is encrypted wherever stored.[/li][/ul] Note: Disk encryption often cannot encrypt removable media, so data stored on this media will need to be encrypted separately.
I am currently researching options for implementing disk/device encryption. The hardware appliances I’ve been looking at will encrypt data transparently as it passes through the device to the allocated LUN on the SAN. The LUN will present to the server – how do I implement a non native operating system access mechanism to control access to the visible LUN on the server? If userid/password and permissioning don’t count?
First, try to not store any track data beyond authorization.
Secure key management is a challenging issue when implementing encryption. One of the easier way to become 3.4.1 compliant is to use Trucrypt or PGP disk volume using encryption key + strong passpharase to store credit card data needed for transaction authorization. Once the transaction has been processed, truncate or mask PAN per PCI requirements. (e.g. maximum first 6 and last 4 digits) if stored past authorization.
We’re not storing anything. Clients are sending us pgp encrypted files. In order to process the transactions, we need to decrypt the file to disk in a transient file that gets deleted immediately. I am told that the disk to which we decrypt the transient file must be encrypted. Is this the case?
We’re on a Solaris platform, so PGP disk volume and Truecrypt are not options for us (neither of them support Solaris). We’re looking at a fabric switch to handle the encryption transparently on the SAN. But access to the encrypted disk volume would be managed by the native OS mechanism – users would be authenticated to the local server with a userid and password and access to the file system is managed by permissions. This seems to be in direct contradiction to the 3.4.1 standard. So my question is, how do you manage the authentication to the disk? It is, necessarily, visible at the native OS level.
If you are temporarily storing the decrypted PGP file then you are storing the data and it must either be encrypted or otherwise rendered unreadable. Why store it at all? Why not just decrypt and hand the data directly to the payment processing application without using the file system?
And yes, using whole disk encryption and then just using the OS for access control is not allowed.
Command line PGP doesn’t give us the option to decrypt into RAM – it creates an output file. And decrypting into RAM doesn’t prevent you from writing to the disk anyway, given swap. So it looks like we’re required to have device/disk encryption.
If we can’t use native OS authentication, how do we handle the presentation of the LUN then, which happens at the OS level? What would the definition a non-native OS authentication mechanism include?
You could look at GPG and/or use a separate box that supports Inter-Process Communication via RPC, or stores in a database with row-level encryption and your Solaris application pulls it over the wire via SSL. Or set up a virutal disk and encrypt with GPG or even command-line PGP.
Yes, swap is an issue that many don’t consider. There is a version of Solaris that has overwrite on all sensitive areas to clean up after their use (it used to be called Trusted Solaris). The issue is can someone harvest sensitive cardholder data (PAN, expiration date, name, CVV) from a file on the disk (including the swap)? If yes, then you have a problem. Try putting in a known card number and then grep on the swap file to see if it’s there. Log files are another prime source for harvesting data. Again, submit a known card number and grep the entire disk to see if it gets written anywhere else. A good PCI auditor will look for this and in fact is required to look. Your actual mileage may vary.
I don’t understand your comment about the cardholder data being submitted at the OS level - can you describe that in some more detail?
Examples of a separate system would be a data base with access controls inside the DB that are separate from the OS controls, or a PKI with access controls based on entries in a directory server, or a hardware device with controls in the box itself. What they don’t want is the ability for someone to compromise the OS, get access to the file system, and that’s all they need to harvest sensitive card holder data.
Our clients are sending us the files encrypted with PGP. I don’t see us asking 400+ clients to change their encryption software – it’s a B2B issue.
We are storing the credit card numbers in a database that is integrated with a hardware appliance to handle all of the encryption and manage the keys. But we have to get the card holder data from the encrypted file to the database. In order for us to process the file that the client has sent us, we have to decrypt it to extract the credit card numbers (and other txn info) and insert it into the database. The temporary decrypted files are deleted after the file is processed. But they live for a fraction of a second, unencrypted, so that we can get the data into the encrypted database fields. I don’t see how an IPC is going to solve the problem – wouldn’t we just be moving the unencrypted data to yet another server and wind up with an issue on that server? Wherever we do this, RAM or disk, we will wind up with the unencrypted data. And so the solution of decrypting the file to an encrypted disk, and we wind up squarely in the 3.4.1 scope.
It’s the encrypted disk that is presented by the OS, not the card holder data. We’re designated a LUN on our SAN to be encrypted, using a hardware appliance to transparently encrypt on write and decrypt on read. The device has smart cards to handle the encryption keys. The device has an integrated firewall to restrict traffic to and from the LUN. However, the LUN has to be mounted to the server for the application to be able to decrypt the file to it, which means you necessarily are using an OS mechanism of access control to determine who can read and write to the volume. Does this satisfy the requirement, if the hardware device itself has additional access controls?
I’d have to look at the technical manual for the product. As you describe it, it would not satisfy PCI because OS access control is used to allow access to the encrypted content.
Roger – Can you give a bit more detail on this? It seems to me that the only access control that matters when using encrypted volumes is file system access control.
For example, even if you had all sorts of non-filesystem access control layers built into the application or database, if the data is written to the encrypted volume without any additional encryption, then access to that volume thwarts all the higher layers.
As a result, I don’t see how ACLs built into the DB, or PKI and directory servers, or any of that really matters when using encrypted volumes: the only thing that matters is whether or not the user can actually access the files in that encrypted volume. Once the volume has been mounted into the file system, the only protection it has is file system encryption.
That said, something like TrueCrypt requires a password to mount into the system in the first place. So even though file system ACLs are the last line of defense against a hacker with root access to a live system after the volume has been mounted (pretty much the worst case scenario), TrueCrypt seems a very effective protection against someone stealing the hard drive or backup tape and popping it into a computer at their evil lair (which seems much more common in practice).
What they don’t want is the ability for someone to compromise the OS, get access to the file system, and that’s all they need to harvest sensitive card holder data.
Do you mean to say the intent of 3.4.1a is “prevent the root user from being able to access plaintext PANs”? That seems really strict: the root user can see every byte in RAM, physically on disk, or mounted into the file system. How can volume encryption (or, indeed, any non-column/HSM encryption) protect against an evil root user?
There are many clients are not using disk encryption, but in SAQ or the audit procedures is not permitted the “Not Applicable” indication. So, what is the best option? a) check as compliant b) check as not compliant and write a comment on the “Special*” field.
we are using NetAPP Decru Solution which is encrypting the Disks presented to the servers from HP EVA Storage …
controlling the encryption and the accessing is being done by the Decru administrators who are using System Cards and username/password to access the decru system …
is this comply with Req. 3.4.1 ?
If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native
operating system access control mechanisms (for example, by not using
local system or Active Directory accounts). Decryption keys must not be tied to user accounts.
From what I understand, DeCru’s solution does not encrypt hard drives. It’s a transparent solution that goes in front of the protected resource/NAS and encrypts network/application traffic in transit.
I did look at their website, but unfortunately precise architecture or detailed deployment examples do not appear.
You still need to encrypt local hard drives to meet 3.4.1, to mitigate the risk of theft and unauthorized local access.
DeCru still adds value in ensuring you can only access the data at rest by using encryption keys that the DeCru appliance manages and perhaps you could compensate your way around 3.4.1 with stricter local access policies and physical security.
Note that as DeCru encrypts everything going to and from the protected resource, you will need a backup system that supports this. You can’t get around it with a locally attached encryption solution as this could still be storing cardholder data in clear text.
can someone please help me explain what control should be put in place for this requirment. what does it mean by logical access to encrypted filr systems is implemented via a mechanism that is seperate from the native operating systems mechanism.
Hello tmcarr,
PGP Command Line does have an option to decrypt to STDOUT which can then be “piped” into another process without having the data written to disk. To output the decrypted data to STDOUT you can use the argument -o/–output with a dash (-) instead of a filename.
e.g. pgp --decrypt --input encrypted.pgp --output -