The reason PCI DSS applies to any organization is the presence of CHD (Cardholder Data).
PCI Data includes CHD and SAD, as defined henceforth:
- CHD = Acronym for "Cardholder Data"; consists of the PAN, cardholder name, card expiration date, and sometimes service code
- PAN = Acronym for "Primary Account Number"; the card number printed on the front of the card.
- SAD = Acronym for "Sensitive Authentication Data", it includes the magnetic track information, the PIN or PIN block, as well as the Card-not-present authorization value which we will refer to as CVV2 but can take any of the following acronyms: CAV2/CVC2/CVV2/CID.
PCI mandates data retention and disposal policies and procedures (3.1). The retention policy is often included within the data classification policy, or at least references it. The(se) policy(ies) should define time limits for retention with proper justification (mostly laws and regulations), and specifically cover retention requirements for cardholder data. They must also include a process which could be manual or automated, that runs at least quarterly (every 3 months) to identify and delete cardholder data that has passed retention time. This approach is consistent with standard Information Lifecycle Management practices.
Requirement 3.2 and its sub-requirements cover SAD after authorization. The only entity that can keep SAD is the issuer for its own issued cards, and those must be adequately protected. SAD pre-authorization data (see section 2.3 and FAQ 1154) can be kept, but it should be encrypted securely as defined for the PAN in requirement 3.4. SAD includes track data from the magnetic stripe (3.2.1), card verification codes or values (three-digit or four-digit number printed on the front or back of a payment card) (3.2.2), the PIN or PIN-block (3.2.3).
The next two requirements cover presentation and storage of the PAN.
When displaying the PAN, unless you absolutely need the full number (and can justify this as a documented business need), it should be masked (3.3) displaying, at a maximum, the first 6 digits and last 4 digits (something like 4444 44* *** 1234).
Requirement 3.4 requires that we "render the PAN unreadable", or not valuable to the attacker. Four ways are identified as acceptable:
- One-way hashes (see section 188.8.131.52 in the Encryption Primer of volume 3) - an option that I think should no longer be used as it can likely be brute-forced.
- Truncation (a screen capture of a masked PAN per 3.3 becomes truncated) - truncation is non-reversible.
- Index tokens (tokenisation) - where tokens with unpredictable values replace the PAN - see section 184.108.40.206 of volume 2 for more detail on tokenisation.
- Strong cryptography - encryption requirements described further in section 220.127.116.11 of volume 3 "Encryption of Stored Data" below.
In all cases, for the method to be acceptable, it must be impossible for an attacker to reconstitute the PAN.
Getting back to "strong encryption". If cardholder data (PAN or SAD) is to be stored encrypted, then multiple requirements must be met. Encryption could be performed at the database table or field level (recommended), file level, or the media can also be fully encrypted, as is the case with some hard drive or tape backup encryption. In the case of encryption performed at the media level (disk or tape), keys must not be associated or managed by the operating system authentication (which would make breaking that layer a single point of failure) but must be managed separately and independently from the local authentication. This means that the user would likely have to enter a passphrase (a type of key-encrypting key) manually after logon to get access to the encryption media.
Encryption is only as secure as the protection given to its encryption keys, which is why requirement 3.5.* mandates developing (and documenting) procedures to protect encryption keys.
Requirement 3.6.* mandates development and documentation of all the relevant key-management processes and procedures for cryptographic keys used for encryption of cardholder data.