PCI DSS · Domain 2
Protect Cardholder Data
About 20% of the exam
Cardholder data versus authentication data
- Cardholder data
- PAN, name, expiry, service code
- PAN
- the number that defines scope
- Storing cardholder data
- allowed if justified and protected
- Authentication data
- track data, card codes, PINs
- Storing authentication data
- never after authorization completes
- Encrypted authentication data
- still forbidden after authorization
- Issuers
- may store it with business need
Nothing makes stored authentication data acceptable after authorization, and encrypting it does not create an exception
Requirement 3, protecting stored data
- Keep data only with business justification
- Define retention periods and delete afterwards
- A quarterly process removes expired data
- Render the PAN unreadable wherever stored
- Display masked to the minimum needed
- Maximum shown is first six, last four
- Keyed hashing required for hashed PANs
- Disk encryption alone is rarely sufficient
Version 4.0 requires hashes of the PAN to be keyed, because an unkeyed hash of a card number can be brute forced
Rendering a PAN unreadable
- Strong encryption
- paired with proper key management
- Truncation
- digits removed permanently
- Tokenization
- surrogate value, vault holds the original
- Keyed hash
- one way with a secret key
- Combinations
- hash and truncation together need care
- Masking
- display control, not storage protection
Requirement 4, data in transit
- Strong cryptography over open public networks
- Only trusted keys and certificates accepted
- Certificate validity confirmed, not assumed
- Insecure protocol versions rejected
- Inventory of trusted keys maintained
- PAN never sent by end user messaging
Key management duties
- Keys held in the fewest possible locations
- Key encrypting key at least as strong
- Keys stored apart from the data
- Crypto period defined and enforced
- Weakened keys retired or replaced
- Split knowledge and dual control for manual keys
- Custodians acknowledge responsibilities in writing
Where PANs hide
- Debug and application error logs
- Database exports and support tickets
- Email inboxes and chat threads
- Browser cache on virtual terminals
- Backups and archived file shares
- Discovery scans exist to find them
Cryptography vocabulary
- Symmetric
- one key encrypts and decrypts
- Asymmetric
- a public and private pair
- Crypto period
- how long a key may live
- Crypto agility
- changing algorithms without redesign
- Hardware security module
- tamper resistant device holding keys
- Key rotation
- replacing a key on schedule
Tokenization versus encryption
- Encryption is reversible with the key
- Tokens map back only in the vault
- Tokens can remove systems from scope
- The vault itself stays firmly in scope
- Format preserving tokens ease integration
Transport security in practice
- Modern protocol versions only
- Weak cipher suites disabled
- Downgrade attacks blocked by configuration
- Strict transport security on web endpoints
- Inspection devices protect the decrypted traffic
Data lifecycle under requirement 3
- Capture
- Justify the need
- Classify and locate
- Protect at rest
- Restrict who sees it
- Retention period ends
- Secure deletion
- Verify deletion
- Retention driven by legal and business need
- Data you never store cannot leak
- Deletion verified, not merely scheduled
- Media destroyed beyond any reconstruction
Protection failures
- Keys stored on the encrypted server
- Full track data kept for chargebacks
- Card codes captured in call recordings
- Test data containing real card numbers
- Truncated and hashed values held together
- Retention policy written but never executed
- Masking applied on one screen only
Cloud and shared responsibility
- Customer encrypts data in infrastructure services
- Provider secures physical and hypervisor layers
- Key custody decides who can decrypt
- Provider managed keys still need governance
- Responsibility matrix agreed and documented
- Cross region copies inherit the same rules
Rapid recall: what may be stored
- PAN
- yes, rendered unreadable
- Cardholder name
- yes, protected as cardholder data
- Expiration date
- yes, protected as cardholder data
- Service code
- yes, protected as cardholder data
- Full track data
- never after authorization
- Card verification code
- never after authorization
- PIN or PIN block
- never after authorization
Masking rules
- Show only what the job needs
- First six and last four maximum
- A legitimate business need can justify more
- Masking is display, storage rules still apply
- Copying PAN to remote devices restricted
Reference strip: data types, storage, transit, keys, deletion
Data types
- PAN, name, expiry, service code
- Track data, card code, PIN
- The second group is never stored
Storage
- Justify, then minimize
- Encrypt, truncate, tokenize or key hash
- Mask on display separately
Transit
- Strong cryptography on public networks
- Trusted certificates verified
- No card numbers in messaging
Keys
- Stored apart, fewest locations
- Crypto periods enforced
- Split knowledge for manual handling
Deletion
- Retention schedule enforced quarterly
- Deletion verified afterwards
- Media destroyed irreversibly
Quick exam traps
- Trap: Encrypted card verification codes may be stored for disputes
- Trap: Full disk encryption satisfies the stored PAN requirement on its own
- Trap: An unkeyed hash is an acceptable way to protect a PAN
- Trap: Masking the PAN on screen also protects it in the database
- Trap: Tokenization puts the token vault out of scope
- Trap: Storing the encryption key beside the data is fine if access is limited
- Trap: Cardholder name must always be encrypted when stored
cybercertprep.com · original revision sheet written from the public body of knowledge