Encryption Reading Time: 6 minutes

PCI Compliance Specification

Payment Card Industry Data Security Standards (PCI DSS) provides a total of 12 requirements for securing cardholder data which can be stored, processed and transmitted by organizations. The standard provides a large amount of information about security – which can be complicated for organizations to prioritize their points of compliance. 

In this article, we will provide a Prioritized approach recommended by PCI Security standards which will help organizations understand where they should start, and how to reduce risk in the compliance process.

What is Prioritized approach?

The prioritized approach provides 6 major security milestones that will help organizations secure high risk factors and escalating threats while being PCI DSS compliant.

Milestones for Prioritized approach

The Prioritized Approach provides six milestones. The table below summarizes the high-level goals and intentions of each milestone. 

MilestoneObjective
1

Remove sensitive authentication data and limit data retention.

If an organization doesn’t need sensitive authentication data and other cardholder data, they can simply remove it which will greatly decrease the risk of compromise.

2

Protecting systems and networks, and being prepared to respond to a system breach.

In this objective, organizations should focus on access points and processes of responding.

3

Securing Payment Card Applications.

In this objective, organizations should focus on control of the application, application processes, and servers. Weakness and vulnerability to these areas would provide an easy way to access cardholder data and other information

4

Monitor and access control to systems.

Organizations should focus on who, what, when, and how something or someone accesses the card holder information, network and data environments.

5

Protecting stored cardholder data.

Organizations must properly protect cardholder data which may include Primary Account Numbers, Milestone Five targets, and key protection mechanisms for that stored data.

6

Finalizing remaining compliance efforts, and ensure all controls are in place.

This objective intends to complete PCI DSS requirements, and finalize the remaining policies, procedures and processes which are needed to properly protect cardholder environment.

Milestone

123456

PCI DSS Requirements

Requirement 1

Install and maintain a firewall configuration to protect cardholder data

  1. Establish and implement firewall and router configuration standards that include the following:
    1. A formal process for approving and testing all network connections and changes to the firewall and router configurations
    2. Current network diagram that identifies all connections between the cardholder data environment and other networks, including any wireless networks
    3. Current diagram that shows all cardholder data flows across systems and networks
    4. Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone
    5. Description of groups, roles, and responsibilities for management of network components
    6. Documentation of business justification and approval for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.
    7. Requirement to review firewall and router rule sets at least every six months
  2. Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.
    1. Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic.
    2. Secure and synchronize router configuration files.
    3. Install perimeter firewalls between all wireless networks and the cardholder data environment, and configure these firewalls to deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment.
  3. Prohibit direct public access between the Internet and any system component in the cardholder data environment.
    1. Implement a DMZ to limit inbound traffic to only system components that provide authorized, publicly accessible services, protocols, and ports.
    2. Limit inbound Internet traffic to IP addresses within the DMZ.
    3. Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network.
    4. Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.
    5. Permit only “established” connections into the network.
    6. Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.
    7. Do not disclose private IP addresses and routing information to unauthorized parties.
  4. Install personal firewall software or equivalent functionality on any portable computing devices that connects to the Internet when outside the network, which are also used to access the CDE. Firewall (or equivalent) configurations include:
    1. Specific configuration settings are defined.
    2. Personal firewall (or equivalent functionality) is actively running.
    3. Personal firewall (or equivalent functionality) is not alterable by users of the portable computing devices.
  5. Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.

Requirement 2

Do not use vendor-supplied defaults for system passwords and other security parameters.

  1. Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network
    1. For wireless environments connected to the cardholder data environment or transmitting cardholder data, change ALL wireless vendor defaults at installation, including but not limited to default wireless encryption keys, passwords, and SNMP community strings
  2. Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards. Sources of industry-accepted system hardening standards may include, but are not limited to:
    1. Center for Internet Security (CIS)
    2. International Organization for Standardization (ISO)
    3. SysAdmin Audit Network Security (SANS) Institute
    4. National Institute of Standards Technology (NIST)
      1. Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server.
      2. Enable only necessary services, protocols, daemons, etc., as required for the function of the system.
      3. Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.
      4. Configure system security parameters to prevent misuse.
      5. Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.
  3. Encrypt all non-console administrative access using strong cryptography.
  4. Maintain an inventory of system components that are in scope for PCI DSS.
  5. Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties.
  6. Shared hosting providers must protect each entity’s hosted environment and cardholder data.

Requirement 3

Protect Stored cardholder data

  1. Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures, and processes that include at least the following for all cardholder data (CHD) storage:
    • Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements.
    • Specific retention requirements for cardholder data.
    • Processes for secure deletion of data when no longer needed.
    • A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention.
  2. Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process.
    It is permissible for issuers and companies that support issuing services to store sensitive authentication data if:
    • There is a business justification and
    • The data is stored securely.
  3. Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere) after authorization. This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.
  4. Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card used to verify card-not-present transactions) after authorization.
  5. Do not store the personal identification number (PIN) or the encrypted PIN block after authorization.
  6. Mask PAN when displayed (the first six 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 first six/last four digits of the PAN.
  7. Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:
    • One-way hashes based on strong cryptography, (hash must be of the entire PAN)
    • Truncation (hashing cannot be used to replace the truncated segment of PAN)
    • Index tokens and pads (pads must be securely stored)
    • Strong cryptography with associated key-management processes and procedures.
    • If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts.
  8. Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse:
    • Additional requirement for service providers only: Maintain a documented description of the cryptographic architecture that includes:
      1. Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date
      2. Description of the key usage for each key.
      3. Inventory of any HSMs and other SCDs used for key management
    • Restrict access to cryptographic keys to the fewest number of custodians necessary
    • Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times:
      1. 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
      2. Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of-interaction device)
      3. As at least two full-length key components or key shares, in accordance with an industry-accepted method
      4. Store cryptographic keys in the fewest possible location.
      5. Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.

Conclusion

This article is part 1 of PCI Compliance specifications. We guide you to achieve proper PCI Compliance and prioritize the requirements while focusing on each task based on a particular milestone. This will help organizations secure cardholder data and environment and also achieve PCI compliance.

To learn more, visit our website: www.encryptionconsulting.com/

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

About the Author

Anish Bhattacharya's profile picture

Anish Bhattacharya is a Consultant at Encryption Consulting, working with PKIs, HSMs, creating Google Cloud applications, and working as a consultant with high-profile clients.

Explore the full range of services offered by Encryption Consulting.

Feel free to schedule a demo to gain a comprehensive understanding of all the services Encryption Consulting provides.

Request a demo