PCI Series: Requirement 3 – Protect Stored Cardholder Data

Welcome to another post dedicated to the use of Identity Management (IdM) and related technologies in addressing the Payment Card Industry Data Security Standard (PCI DSS). This specific post is related to requirement three (i.e. the requirement to protect stored cardholder data). In case you're new to the series - the outline and mapping of individual articles to the requirements can be found in the overarching post that started the series.

Section three of the PCI DSS standard talks about storing cardholder data in a secure way. One of the technologies that can be used for secure storage of cardholder data is

disk encryption called LUKS. But LUKS keys also need to be managed (as mentioned in requirement 3.6.3). One potential solution: IdM's Vault – a secret store that can be used to escrow disk encryption passwords and implement policies and conditions for the recovery of such passwords (or keys). While in a Vault, the keys and passwords do not need to be in any way related to keys and passwords used by users that access the cardholder services; requirement 3.4.1 is thus fully met by this solution.

Requirement 3.5.3 creates a challenge demanding separation of keys. This usually leads to the need to involve a user to unlock their key to start a process. For example, a system volume can be encrypted but in case of a reboot an administrator has to come over and enter a password to continue the boot process. A new technology called Network Bound Disk Encryption addresses this problem by placing a special server on the network. While this technology is not currently included with Red Hat Enterprise Linux - here is a pointer to a demo.

Questions about how Identity Management relates to requirement three?  Reach out using the comments section (below).