Requirement 3: Protect Stored Account Data

Protection methods such as encryption, truncation, masking, and hashing are critical components of account data protection. If an intruder circumvents other security controls and gains access to encrypted account data, the data is unreadable without the proper cryptographic keys and is unusable to that intruder. Other effective methods of protecting stored data should also be considered as potential risk-mitigation opportunities. For example, methods for minimizing risk include not storing account data unless necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies such as e-mail and instant messaging.

Requirement 3: Protect Stored Account Data

3.1 Processes And Mechanisms For Protecting Stored Account Data Are Defined And Understood

3.1.1 All security policies and operational procedures that are identified in Requirement 3 are: • Documented • Kept up to date • In use • Known to all affected parties

It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle.

3.1.2 Roles and responsibilities for performing activities are documented, assigned, and understood

Roles and responsibilities may be documented within policies and procedures or maintained within separate documents.

As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities.

3.2 Storage Of Account Data Is Kept To A Minimum

3.2.1 Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that include at least the following: • Coverage for all locations of stored account data • Coverage for any sensitive authentication data (SAD) stored prior to completion of authorization • Limiting data storage amount and retention time to that which is required for legal or regulatory, and/or business requirements • Specific retention requirements for stored account data that defines length of retention period and includes a documented business justification • Processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy • A process for verifying, at least once every three months, that stored account data exceeding the defined retention period has been securely deleted or rendered unrecoverable

When identifying locations of stored account data, consider all processes and personnel with access to the data, as data could have been moved and stored in different locations than originally defined. Storage locations that are often overlooked include backup and archive systems, removable data storage devices, paper-based media, and audio recordings.

To define appropriate retention requirements, an entity first needs to understand its own business needs as well as any legal or regulatory obligations that apply to its industry or to the type of data being retained. Implementing an automated process to ensure data is automatically and securely deleted upon its defined retention limit can help ensure that account data is not retained beyond what is necessary for business, legal, or regulatory purposes.

Methods of eliminating data when it exceeds the retention period include secure deletion to complete removal of the data or rendering it unrecoverable and unable to be reconstructed. Identifying and securely eliminating stored data that has exceeded its specified retention period prevents unnecessary retention of data that is no longer needed. This process may be automated, manual, or a combination of both.

The deletion function in most operating systems is not “secure deletion” as it allows deleted data to be recovered, so instead, a dedicated secure deletion function or application must be used to make data unrecoverable.

Remember, if you don’t need it, don’t store it!

3.3 Sensitive Authentication Data (SAD) Is Not Stored After Authorization

3.3.1 SAD is not retained after authorization, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the authorization process

SAD is very valuable to malicious individuals as it allows them to generate counterfeit payment cards and create fraudulent transactions. Therefore, the storage of SAD upon completion of the authorization process is prohibited.

3.3.1.1 The full contents of any track are not retained upon completion of the authorization process

If full contents of any track (from the magnetic stripe on the back of a card if present, equivalent data contained on a chip, or elsewhere) is stored, malicious individuals who obtain that data can use it to reproduce payment cards and complete fraudulent transactions.

3.3.1.2 The card verification code is not retained upon completion of the authorization process

If card verification code data is stolen, malicious individuals can execute fraudulent Internet and mail-order/telephone-order (MO/TO) transactions. Not storing this data reduces the probability of it being compromised.

3.3.1.3 The personal identification number (PIN) and the PIN block are not retained upon completion of the authorization process

PIN and PIN blocks should be known only to the card owner or entity that issued the card. If this data is stolen, malicious individuals can execute fraudulent PIN-based transactions (for example, in-store purchases and ATM withdrawals). Not storing this data reduces the probability of it being compromised.

3.3.2 SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography

Entities should consider encrypting SAD with a different cryptographic key than is used to encrypt PAN. Note that this does not mean that PAN present in SAD (as part of track data) would need to be separately encrypted.

3.3.3 Additional requirement for issuers and companies that support issuing services and store sensitive authentication data Any storage of sensitive authentication data is: • Limited to that which is needed for a legitimate issuing business need and is secured • Encrypted using strong cryptography

Entities should consider encrypting SAD with a different cryptographic key than is used to encrypt PAN. Note that this does not mean that PAN present in SAD (as part of track data) would need to be separately encrypted.

3.4 Access To Displays Of Full PAN And Ability To Copy Cardholder Data Are Restricted

3.4.1 PAN is masked when displayed (the BIN and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the BIN and last four digits of the PAN

Applying access controls according to defined roles is one way to limit access to viewing full PAN to only those individuals with a defined business need.

The masking approach should always display only the number of digits needed to perform a specific business function. For example, if only the last four digits are needed to perform a business function, PAN should be masked to only show the last four digits. As another example, if a function needs to view to the bank identification number (BIN) for routing purposes, unmask only the BIN digits for that function.

3.4.2 When using remote-access technologies, technical controls prevent copy and/or relocation of PAN for all personnel, except for those with documented, explicit authorization and a legitimate, defined business need

Copying and relocation of PAN should only be done to storage devices that are permissible and authorized for that individual.

3.5 Primary Account Number (PAN) Is Secured Wherever It Is Stored

3.5.1 PAN is rendered unreadable anywhere it is stored by using any of the following approaches: • One-way hashes based on strong cryptography of the entire PAN • Truncation (hashing cannot be used to replace the truncated segment of PAN). If hashed and truncated versions of the same PAN, or different truncation formats of the same PAN, are present in an environment, additional controls are in place such that the different versions cannot be correlated to reconstruct the original PAN • Index tokens • Strong cryptography with associated key-management processes and procedures

The removal of cleartext stored PAN is a defense in depth control designed to protect the data if an unauthorized individual gains access to stored data by taking advantage of a vulnerability or misconfiguration of an entity’s primary access control.

Secondary independent control systems (for example governing access to, and use of, cryptography and decryption keys) prevent the failure of a primary access control system leading to a breach of confidentiality of stored PAN. If hashing is used to remove stored cleartext PAN, by correlating hashed and truncated versions of a given PAN, a malicious individual can easily derive the original PAN value. Controls that prevent the correlation of this data will help ensure that the original PAN remains unreadable.

3.5.1.1 Hashes used to render PAN unreadable are keyed cryptographic hashes of the entire PAN, with associated key-management processes and procedures

A hashing function that incorporates a randomly generated secret key provides brute force attack resistance and secret authentication integrity.

3.5.1.2 If disk-level or partition-level encryption (rather than file-, column-, or field-level database encryption) is used to render PAN unreadable, it is implemented only as follows: • On removable electronic media OR • If used for non-removable electronic media, PAN is also rendered unreadable via another mechanism

Disk-level and partition-level encryption typically encrypts the entire disk or partition using the same key, with all data automatically decrypted when the system runs or when an authorized user requests it. For this reason, disk-level encryption is not appropriate to protect stored PAN on computers, laptops, servers, storage arrays, or any other system that provides transparent decryption upon user authentication.

3.5.1.3 If disk-level or partition-level encryption is used (rather than file-, column-, or field–level database encryption) to render PAN unreadable, it is managed as follows: • Logical access is managed separately and independently of native operating system authentication and access control mechanisms • Decryption keys are not associated with user accounts • Authentication factors (passwords, passphrases, or cryptographic keys) that allow access to unencrypted data are stored securely

Full disk encryption helps to protect data in the event of physical loss of a disk and therefore its use is best limited only to removable electronic media storage devices.

3.6 Cryptographic Keys Used To Protect Stored Account Data Are Secured

3.6.1 Procedures are defined and implemented to protect cryptographic keys used to protect stored account data against disclosure and misuse that include: • Access to keys is restricted to the fewest number of custodians necessary • Key-encrypting keys are at least as strong as the data-encrypting keys they protect • Key-encrypting keys are stored separately from data-encrypting keys • Keys are stored securely in the fewest possible locations and forms

Having a centralized key management system based on industry standards is recommended for managing cryptographic keys.

3.6.1.1 Additional requirement for service providers only: A documented description of the cryptographic architecture is maintained that includes: • Details of all algorithms, protocols, and keys used for the protection of stored account data, including key strength and expiry date • Preventing the use of the same cryptographic keys in production and test environments • Description of the key usage for each key • Inventory of any hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices (SCDs) used for key management, including type and location of devices

Having an automated reporting mechanism can assist with maintenance of the cryptographic attributes.

3.6.1.2 Secret and private keys used to encrypt/decrypt stored account data are stored in one (or more) of the following forms at all times: • Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key • Within a secure cryptographic device (SCD), such as a hardware security module (HSM) or PTS-approved point-of-interaction device • As at least two full-length key components or key shares, in accordance with an industry-accepted method

Where data-encrypting keys are stored in an HSM, the HSM interaction channel should be protected to prevent interception of encryption or decryption operations.

3.6.1.3 Access to cleartext cryptographic key components is restricted to the fewest number of custodians necessary

Only personnel with defined key custodian responsibilities (creating, altering, rotating, distributing, or otherwise maintaining encryption keys) should be granted access to key components.

Ideally this will be a very small number of people.

3.6.1.4 Cryptographic keys are stored in the fewest possible locations

Storing any cryptographic keys in the fewest locations helps an organization track and monitor all key locations and minimizes the potential for keys to be exposed to unauthorized parties.

3.7 Where Cryptography Is Used To Protect Stored Account Data, Key Management Processes And Procedures Covering All Aspects Of The Key Lifecycle Are Defined And Implemented

3.7.1 Key-management policies and procedures are implemented to include generation of strong cryptographic keys used to protect stored account data

Use of strong cryptographic keys significantly increases the level of security of encrypted account data.

3.7.2 Key-management policies and procedures are implemented to include secure distribution of cryptographic keys used to protect stored account data

Secure distribution or conveyance of secret or private cryptographic keys means that keys are distributed only to authorized custodians and are never distributed insecurely.

3.7.3 Key-management policies and procedures are implemented to include secure storage of cryptographic keys used to protect stored account data

Data encryption keys can be protected by encrypting them with a key-encrypting key.

Keys can be stored in a Hardware Security Module (HSM).

Secret or private keys that can decrypt data should never be present in source code.

3.7.4 Key management policies and procedures are implemented for cryptographic key changes for keys that have reached the end of their cryptoperiod, as defined by the associated application vendor or key owner, and based on industry best practices and guidelines, including the following: • A defined cryptoperiod for each key type in use • A process for key changes at the end of the defined cryptoperiod

Changing encryption keys when they reach the end of their cryptoperiod is imperative to minimize the risk of someone obtaining the encryption keys and using them to decrypt data.

3.7.5 Key management policies procedures are implemented to include the retirement, replacement, or destruction of keys used to protect stored account data, as deemed necessary when: • The key has reached the end of its defined cryptoperiod • The integrity of the key has been weakened, including when personnel with knowledge of a cleartext key component leaves the company, or the role for which the key component was known • The key is suspected of or known to be compromised • Retired or replaced keys are not used for encryption operations

Archived cryptographic keys should be used only for decryption/verification purposes.

The encryption solution should provide for and facilitate a process to replace keys that are due for replacement or that are known to be, or suspected of being, compromised. In addition, any keys that are known to be, or suspected of being, compromised should be managed in accordance with the entity’s incident response plan.

3.7.6 Where manual cleartext cryptographic key-management operations are performed by personnel, key-management policies and procedures are implemented include managing these operations using split knowledge and dual control

Where key components or key shares are used, procedures should ensure that no single custodian ever has access to sufficient key components or shares to reconstruct the cryptographic key. For example, in an m-of-n scheme (for example, Shamir), where only two of any three components are required to reconstruct the cryptographic key, a custodian must not have current or prior knowledge of more than one component. If a custodian was previously assigned component A, which was then reassigned, the custodian should not then be assigned component B or C, as this would give the custodian knowledge of two components and the ability to recreate the key.

3.7.7 Key management policies and procedures are implemented to include the prevention of unauthorized substitution of cryptographic keys

The encryption solution should not allow for or accept substitution of keys from unauthorized sources or unexpected processes.

Controls should include ensuring that individuals with access to key components or shares do not have access to other components or shares that form the necessary threshold to derive the key.

3.7.8 Key management policies and procedures are implemented to include that cryptographic key custodians formally acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities

This process will help ensure individuals that act as key custodians commit to the key-custodian role and understand and accept the responsibilities. An annual reaffirmation can help remind key custodians of their responsibilities.

3.7.9 Additional requirement for service providers only: Where a service provider shares cryptographic keys with its customers for transmission or storage of account data, guidance on secure transmission, storage and updating of such keys is documented and distributed to the service provider’s customers

Providing guidance to customers on how to securely transmit, store, and update cryptographic keys can help prevent keys from being mismanaged or disclosed to unauthorized entities.

Let’s Understand With An Example

This image is borrowed from the Cybersecurity Labs. Assume it represents your work environment and cardholder data is sitting on the server dz-win10.

Requirement 3.1

It’s all about defining policies and procedures. Then, allocate the responsibilities.

Requirement 3.2

This requirement can be summed up in one sentence ‘If you don’t need it, don’t store it!’. It includes the implementation of data retention and disposal policies on dz-win10. It also includes periodic verification at least once every three months.

Requirement 3.3

Assume we process the card verification code or personal identification number, which is sensitive authentication data (SAD), it should not be retained after authorization, even if encrypted. Store the SAD for a very limited time with strong encryption and purge it asap on dz-win10.

Requirement 3.4

It’s not an infrastructure requirement but an app requirement. The PAN should be masked at the application e.g. BLX****22N.

Requirements 3.5, 3.6 And 3.7

It suggests using strong encryption to store the PAN. The removal of cleartext stored PAN is a defense in depth control. The encryption requires key management and one of the best practices is to not store the keys with the data, in our example, it’s dz-win10, dsin-dangerzone and the jump-server.