Safeguarding Cardholder Data: A Deep Dive into PCI DSS Requirements 3 and 4.

PCI-DSS ESSENTIALS, TERMINOLOGY CLARIFICATIONS

The PCI-DSS uses certain abbreviations and terms that are important to clarify before moving further. These can be related to data, networks, systems, and other elements.

Key terms in the PCI-DSS documentation include:

• The CDE, or Card Data Environment. This is the set of networks and systems where cardholder data (CHD) is stored or transmitted, as opposed to the non-CDE.For example, you have 2 WiFi networks. Only one is used for payments. That one is in the CDE. The other isn’t;
• Then, the CHD, or Cardholder Data. This is account numbers, expiration dates, and other card data;
• CHD must be secured in storage and transit;

In terms of CHD, it’s important to go deeper and clarify what is the type of cardholder data that can be stored. There are usually two categories of data in a credit/debit card:

- The CHD is the data usually on the front of the card:

• The full card number (known as the PAN, or Personal Account Number);
• The expiration date;
• The cardholder name, tier, other elements;

- The SAD (Sensitive Authentication Data) is usually the data on the back of the card:

• The 3-digit card security number (CVV, CVV2, etc);
• The magnetic stripe (or PIN);
• SAD cannot be stored at all under PCI-DSS;

This was a brief review of the subject, let us dive into PCI DSS v4 and see what the standards stipulate.

PCI DSS is intended for all entities that

• store,
• process, or
• transmit

cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data environment (CDE).

This includes all entities involved in payment card account processing —

including merchants, processors, acquirers, issuers and other service providers.

Defining Account Data, Cardholder Data, and Sensitive Authentication Data

Cardholder data and sensitive authentication data are considered account data and are defined as follows:

Account Data

Cardholder Data includes:

?Primary Account Number (PAN)

?Cardholder Name

?Expiration Date

?Service Code

Sensitive Authentication Data includes:

?Full track data (magnetic-stripe data or equivalent on a chip)

?Card verification code

?PINs/PIN blocks

If an entity stores, processes, or transmits PAN, then a CDE exists to which PCI DSS requirements will apply.

Some requirements may not be applicable, for example if the entity does not store PAN, then the requirements relating to the protection of stored PAN in Requirement 3 will not be applicable to the entity.

Even if an entity does not store, process, or transmit PAN, some PCI DSS requirements may still apply.

Consider the following:

-If the entity stores SAD, requirements specifically related to SAD storage in Requirement 3 will be applicable.

-If the entity engages third-party service providers to store, process or transmit PAN on its behalf, requirements related to the management of service providers in Requirement 12 will be applicable.

-If the entity can impact the security of a CDE because the security of an entity’s infrastructure can affect how cardholder data is processed (for example, via a web server that controls the generation of a payment form or page) some requirements will be applicable.

-If cardholder data is only present on physical media (for example paper), requirements relating to the security and disposal of physical media in Requirement 9 will be applicable.

-Requirements related to an incident response plan are applicable to all entities, to ensure that there are procedures to follow in the event of a suspected or actual breach of the confidentiality of cardholder data.

Use of Account Data, Sensitive Authentication Data, Cardholder Data, and Primary Account Number in PCI DSS PCI DSS includes requirements that specifically refer to account data, cardholder data, and sensitive authentication data.

It is important to note that each of these types of data is different and the terms are not interchangeable. Specific references within requirements to account data, cardholder data, or sensitive authentication data are purposeful, and the requirements apply specifically to the type of data that is referenced.

You can read more about scoping and CDE - https://www.dhirubhai.net/pulse/unraveling-mysteries-pci-dss-scoping-cde-segmentation-kamran-nagiyev-1e/?trackingId=EEmrQPweTMyzk5nHQDyNJQ%3D%3D

Elements of Account Data and Storage Requirements

The table below identifies the elements of the cardholder and sensitive authentication data, whether storage of each data element is permitted or prohibited, and whether each data element must be rendered unreadable—for example, with strong cryptography—when stored.

This table is not exhaustive and is presented to illustrate only how the stated requirements apply to the different data elements.

If PAN is stored with other elements of cardholder data, only the PAN must be rendered unreadable according to PCI DSS Requirement 3.5.1.

Sensitive authentication data must not be stored after authorization, even if encrypted. This applies even to environments where there is no PAN present.

Scope of PCI DSS Requirements

PCI DSS requirements apply to:

- The cardholder data environment (CDE), which is comprised of:

– System components, people, and processes that store, process, and transmit cardholder data and/or sensitive authentication data,

and,

–System components that may not store, process, or transmit CHD/SAD but have unrestricted connectivity to system components

that store, process, or transmit CHD/SAD.

AND

- System components, people, and processes that could impact the security of the CDE.

“System components” include network devices, servers, computing devices, virtual components, cloud components, and software.

Examples of system components include but are not limited to:

• Systems that store, process, or transmit account data (for example, payment terminals, authorization systems, clearing systems, payment middleware systems, payment back-office systems, shopping cart and storefront systems, payment gateway/switch systems, fraud monitoring systems).
• Systems that provide security services (for example, authentication servers, access control servers, security information and event management (SIEM) systems, physical security systems (for example, badge access or CCTV), multi-factor authentication systems, anti-malware systems).
• Systems that facilitate segmentation (for example, internal network security controls).
• Systems that could impact the security of account data or the CDE (for example, name resolution, or e-commerce (web) redirection servers).
• -Virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors.
• Cloud infrastructure and components, both external and on premises, and including instantiations of containers or images, virtual private clouds, cloud-based identity and access management, CDEs residing on premises or in the cloud, service meshes with containerized applications, and container orchestration tools.
• Network components, including but not limited to network security controls, switches, routers, VoIP network devices, wireless access points, network appliances, and other security appliances.
• Server types, including but not limited to web, application, database, authentication, mail, proxy, Network Time Protocol (NTP), and Domain Name System (DNS).
• End-user devices, such as computers, laptops, workstations, administrative workstations, tablets, and mobile devices.
• Printers, and multi-function devices that scan, print, and fax.
• Storage of account data in any format (for example, paper, data files, audio files, images, and video recordings).
• Applications, software, and software components, serverless applications, including all purchased, subscribed (for example, Software-as-a-Service), bespoke and custom software, including internal and external (for example, Internet) applications.
• Tools, code repositories, and systems that implement software configuration management or for deployment of objects to the CDE or to systems that can impact the CDE.

Encrypted Cardholder Data and Impact on PCI DSS Scope

Encryption of cardholder data with strong cryptography is an acceptable method of rendering the data unreadable according to PCI DSS Requirement 3.5.

However, encryption alone is generally insufficient to render the cardholder data out of scope for PCI DSS and does not remove the need for PCI DSS in that environment. The entity’s environment is still in scope for PCI DSS due to the presence of cardholder data. For example, in a merchant card-present environment, there is physical access to the payment cards to complete a transaction and there may also be paper reports or receipts with cardholder data. Similarly, in merchant card-not-present environments, such as mail-order/telephone-order and e-commerce, payment card details are provided via channels that need to be evaluated and protected according to PCI DSS.

The following are each in scope for PCI DSS:

• Systems performing encryption and/or decryption of cardholder data, and systems performing key management functions,
• Encrypted cardholder data that is not isolated from the encryption and decryption and key management processes,
• Encrypted cardholder data that is present on a system or media that also contains the decryption key,
• Encrypted cardholder data that is present in the same environment as the decryption key,
• Encrypted cardholder data that is accessible to an entity that also has access to the decryption key.

PCI DSS v.4 requirements regarding CHD and CDE (or elements) are the following

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. This bullet is a best practice until its effective date; refer to Applicability Notes below for details.
• 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.

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.

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

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

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

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

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. This bullet is a best practice until its effective date; refer to Applicability Notes below for details.

3.4.Access to displays of full PAN and the 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

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.

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

3.5.1.1 Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) are keyed cryptographic hashes of the entire PAN, with associated key-management processes and procedures in accordance with Requirements 3.6 and 3.7.

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 that meets Requirement 3.5.1.

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

3.6.Cryptographic keys used to protect stored account data are secured.

subject of a separate article

4.2 PAN is protected with strong cryptography during transmission

4.2.1 Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks:

• Only trusted keys and certificates are accepted.
• Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked. This bullet is a best practice until its effective date; refer to applicability notes below for details.
• The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations.

The encryption strength is appropriate for the encryption methodology in use.

4.2.1.1 An inventory of the entity’s trusted keys and certificates used to protect PAN during transmission is maintained.

4.2.1.2 Wireless networks transmitting PAN or connected to the CDE use industry best practices to implement strong cryptography for authentication and transmission

4.2.2 PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies.

Conclusion: Ensuring Cardholder Data Security

In conclusion, a meticulous understanding of PCI DSS Requirements 3 and 4 is crucial for entities handling cardholder data. These requirements, encapsulating the protection of Cardholder Data (CHD) and the Card Data Environment (CDE), establish stringent measures. Entities, spanning from merchants to service providers, must adhere to these standards to fortify the security of the payment card ecosystem. The delineation of account data, encryption practices, and careful scope considerations underscore the multifaceted approach required.

In essence, the journey through PCI DSS Requirements 3 and 4 illuminates the path to securing cardholder data from storage to transmission.

As the financial landscape evolves, compliance with these measures becomes paramount in maintaining trust and security in the digital realm.