How PCI DSS 4.0 Impacts Human and NHI Identity Security

Share

The intersection of PCI DSS compliance and identity access has become crucial for protecting sensitive payment data. In today's digital landscape, where cloud environments dominate enterprise infrastructure, the convergence of PCI DSS compliance and identity access also faces a new complexity: the proliferation of non-human identities (NHIs).

PCI DSS requirements emphasize the principle of least privilege across all identity types, making it crucial to meticulously manage access rights for human and non-human entities accessing cardholder data. While organizations implement robust authentication measures, the precise control and governance of user access rights often determine the difference between security and vulnerability. PCI DSS emphasizes the principle of least privilege, requiring organizations to meticulously manage who has access to cardholder data and what they can do with it.

PCI 4.0 introduced new requirements that all organizations must take into account. 

What is PCI DSS 4.0

The Payment Card Industry Data Security Standard (PCI DSS) is a comprehensive information security framework designed to ensure the secure handling of payment card data worldwide. Version 4.0, released as a major update to the standard, introduces enhanced security controls and flexibility in implementation approaches. This framework not only governs the protection of payment card data but also establishes robust guidelines for securing related information assets, network infrastructure, and access controls. Organizations that handle credit card information must comply with these standards to maintain secure payment processing environments and protect consumer financial data.

PCI DSS v3.2.1 remained active from March 2022 until March 31, 2024, to give organizations enough time to review the changes in v4.0, update their reporting templates and forms, and implement new controls to meet the new requirements.

Key Changes in Version 4.0

PCI DSS 4.0 introduces several significant changes:

  • Key objectives to meet modern payment security needs: 
    • Enhanced multi-factor authentication requirements 
    • Strengthened password requirements
    • New protections against e-commerce threats and phishing attacks
  • Emphasis on security as an ongoing process: 
    • Clear definition of roles and responsibilities for each requirement 
    • Enhanced guidance for implementing and maintaining security measures
  • Greater flexibility in security implementation: 
    • Support for managing group, shared, and generic accounts 
    • Risk-based approach to determine security activity frequencies
    • Customized implementation options for meeting requirements through innovative methods
  • Streamlined validation process: 
    • Improved alignment between compliance reports, self-assessments, and attestations

PCI DSS 4.0 also introduces new requirements

  • Enhanced Password Security:
    • Minimum password length increased to 12 characters
    • Mandatory combination of numeric and alphabetic characters
    • Periodic password changes based on risk analysis
  • Advanced Security Monitoring:
    • Comprehensive audit logging of administrative actions
    • Detection and prevention of covert malware communication channels (for service providers)
    • Automated protection for public-facing web applications
  • System Account Protection:
    • Regular password rotation based on risk assessment
    • Enhanced complexity requirements for system accounts
    • Immediate password updates upon suspected compromise

Human Identity & NHI PCI DSS Requirements

The following is an overview of all PCI requirements that relate to human identities and non-human identities (NHI). 

Human Identities

  1. Environment-based Access Control: The environment type (such as production or pre-production) of cloud accounts should be identified, and human identities must have tailored access to each environment based on their risk and position within the organization. This risk can then guide privilege management decisions. (Req 6.5.3)
  2. Least Privileged Access to Cardholder Data: Regarding cardholder data, the access control model for human identities should grant permissions based on job roles and business needs while following the principle of least privilege—ensuring users receive only the minimum access required for their specific functions. (Req 7.2.1)
  3. User Access Reviews: Human identities, especially those of third-party vendors, must undergo a comprehensive review every six months to verify their access privileges align with current job functions. During these reviews, management must address any inappropriate access and formally acknowledge that all remaining access privileges are appropriate. (Req 7.2.4)
  4. Stale Identities: Access for terminated users is immediately revoked (Req 8.2.5)
  5. Inactive Identities: Inactive user accounts are removed or disabled within 90 days of inactivity. (Req 8.2.6)
  6. Shared Identities: Shared authentication credentials for human identities require exceptional circumstances with management approval and written justification for access. When granted, access is time-limited and all actions must be traceable to specific users who have verified their identity. (Req 8.2.2)
  7. Just-in-time Access: External Human identities are enabled only during the required time period and disabled when not in use, with all activity being monitored for any unexpected behavior. (Req 8.2.7)
  8. Authentication Posture: All human identities need to be authenticated, whether through a password, smartcard, or biometric verification. For single-factor authentication via passwords, organizations are required to either update them every 90 days or adopt dynamic security assessments that grant access in real-time based on the account's security status. When passwords are employed, they must be initially set to a unique value and reset thereafter. Users are mandated to change passwords immediately after their initial use. (Req 8.3.1, 8.3.5, 8.3.9)
  9. Logging: Audit logs capture all actions taken by any individual with administrative access, including any interactive use of application or system accounts. (Req 10.2.1.2)

Non-human Identities

  1. Inactive Identities: Inactive external Non-human Identities(NHIs) are identified and deleted or disabled. (Req 2.2.2 )
  2. Least Privilege Policy: Application and system accounts must follow the principle of least privilege, with access strictly limited to essential systems and processes required for operation - this requirement becomes mandatory after March 31, 2025. (Req 7.2.5)
  3. NHI Access Reviews: Application and system accounts, and access privileges must undergo periodic reviews based on the organization's risk analysis schedule. During these reviews, it must be verified that the NHI access remains appropriate for its operational function, any inappropriate access is promptly addressed, and management must formally acknowledge the appropriateness of existing access privileges. This requirement becomes mandatory after March 31, 2025. (Req 7.2.5.1)
  4. Shared Identities for NHI: Shared credentials or roles for NHIs are strictly prohibited unless required under exceptional circumstances, which must have management approval and written justification for access. (Req 8.2.2)
  5. Console Access for NHI: Interactive login for system/application accounts is strictly prohibited and only allowed in exceptional cases with time restrictions, documented justification, and management approval. User identity verification is required, and all actions must be traceable to specific users. (Req 8.6.1)
  6. Password and key rotation: Passwords for application and system accounts must be changed regularly and immediately if compromise is suspected or confirmed. These credentials must be created with complexity levels appropriate to their change frequency. This requirement remains a best practice until March 31, 2025, after which it becomes mandatory and must be fully evaluated during PCI DSS assessments. (Req 8.6.3)
  7. Logging: Audit logs capture all actions taken by any individual with administrative access, including any interactive use of application or system accounts. (Req 10.2.1.2)

Ensuring PCI DSS compliance in identity security requires a proactive approach to access management for both human and non-human identities. Andromeda Security can help you gain complete visibility and inventory across your entire identity ecosystem,  strengthen your controls to enforce least privilege, provide the context your teams need to make intelligent access decisions and automate Just in Time access, and meet your compliance requirements.

 As cyber threats evolve, Andromeda Security can help you align your identity security with PCI requirements to safeguard your payment data and maintain customer trust.

The intersection of PCI DSS compliance and identity access has become crucial for protecting sensitive payment data. In today's digital landscape, where cloud environments dominate enterprise infrastructure, the convergence of PCI DSS compliance and identity access also faces a new complexity: the proliferation of non-human identities (NHIs).

PCI DSS requirements emphasize the principle of least privilege across all identity types, making it crucial to meticulously manage access rights for human and non-human entities accessing cardholder data. While organizations implement robust authentication measures, the precise control and governance of user access rights often determine the difference between security and vulnerability. PCI DSS emphasizes the principle of least privilege, requiring organizations to meticulously manage who has access to cardholder data and what they can do with it.

PCI 4.0 introduced new requirements that all organizations must take into account. 

What is PCI DSS 4.0

The Payment Card Industry Data Security Standard (PCI DSS) is a comprehensive information security framework designed to ensure the secure handling of payment card data worldwide. Version 4.0, released as a major update to the standard, introduces enhanced security controls and flexibility in implementation approaches. This framework not only governs the protection of payment card data but also establishes robust guidelines for securing related information assets, network infrastructure, and access controls. Organizations that handle credit card information must comply with these standards to maintain secure payment processing environments and protect consumer financial data.

PCI DSS v3.2.1 remained active from March 2022 until March 31, 2024, to give organizations enough time to review the changes in v4.0, update their reporting templates and forms, and implement new controls to meet the new requirements.

Key Changes in Version 4.0

PCI DSS 4.0 introduces several significant changes:

  • Key objectives to meet modern payment security needs: 
    • Enhanced multi-factor authentication requirements 
    • Strengthened password requirements
    • New protections against e-commerce threats and phishing attacks
  • Emphasis on security as an ongoing process: 
    • Clear definition of roles and responsibilities for each requirement 
    • Enhanced guidance for implementing and maintaining security measures
  • Greater flexibility in security implementation: 
    • Support for managing group, shared, and generic accounts 
    • Risk-based approach to determine security activity frequencies
    • Customized implementation options for meeting requirements through innovative methods
  • Streamlined validation process: 
    • Improved alignment between compliance reports, self-assessments, and attestations

PCI DSS 4.0 also introduces new requirements

  • Enhanced Password Security:
    • Minimum password length increased to 12 characters
    • Mandatory combination of numeric and alphabetic characters
    • Periodic password changes based on risk analysis
  • Advanced Security Monitoring:
    • Comprehensive audit logging of administrative actions
    • Detection and prevention of covert malware communication channels (for service providers)
    • Automated protection for public-facing web applications
  • System Account Protection:
    • Regular password rotation based on risk assessment
    • Enhanced complexity requirements for system accounts
    • Immediate password updates upon suspected compromise

Human Identity & NHI PCI DSS Requirements

The following is an overview of all PCI requirements that relate to human identities and non-human identities (NHI). 

Human Identities

  1. Environment-based Access Control: The environment type (such as production or pre-production) of cloud accounts should be identified, and human identities must have tailored access to each environment based on their risk and position within the organization. This risk can then guide privilege management decisions. (Req 6.5.3)
  2. Least Privileged Access to Cardholder Data: Regarding cardholder data, the access control model for human identities should grant permissions based on job roles and business needs while following the principle of least privilege—ensuring users receive only the minimum access required for their specific functions. (Req 7.2.1)
  3. User Access Reviews: Human identities, especially those of third-party vendors, must undergo a comprehensive review every six months to verify their access privileges align with current job functions. During these reviews, management must address any inappropriate access and formally acknowledge that all remaining access privileges are appropriate. (Req 7.2.4)
  4. Stale Identities: Access for terminated users is immediately revoked (Req 8.2.5)
  5. Inactive Identities: Inactive user accounts are removed or disabled within 90 days of inactivity. (Req 8.2.6)
  6. Shared Identities: Shared authentication credentials for human identities require exceptional circumstances with management approval and written justification for access. When granted, access is time-limited and all actions must be traceable to specific users who have verified their identity. (Req 8.2.2)
  7. Just-in-time Access: External Human identities are enabled only during the required time period and disabled when not in use, with all activity being monitored for any unexpected behavior. (Req 8.2.7)
  8. Authentication Posture: All human identities need to be authenticated, whether through a password, smartcard, or biometric verification. For single-factor authentication via passwords, organizations are required to either update them every 90 days or adopt dynamic security assessments that grant access in real-time based on the account's security status. When passwords are employed, they must be initially set to a unique value and reset thereafter. Users are mandated to change passwords immediately after their initial use. (Req 8.3.1, 8.3.5, 8.3.9)
  9. Logging: Audit logs capture all actions taken by any individual with administrative access, including any interactive use of application or system accounts. (Req 10.2.1.2)

Non-human Identities

  1. Inactive Identities: Inactive external Non-human Identities(NHIs) are identified and deleted or disabled. (Req 2.2.2 )
  2. Least Privilege Policy: Application and system accounts must follow the principle of least privilege, with access strictly limited to essential systems and processes required for operation - this requirement becomes mandatory after March 31, 2025. (Req 7.2.5)
  3. NHI Access Reviews: Application and system accounts, and access privileges must undergo periodic reviews based on the organization's risk analysis schedule. During these reviews, it must be verified that the NHI access remains appropriate for its operational function, any inappropriate access is promptly addressed, and management must formally acknowledge the appropriateness of existing access privileges. This requirement becomes mandatory after March 31, 2025. (Req 7.2.5.1)
  4. Shared Identities for NHI: Shared credentials or roles for NHIs are strictly prohibited unless required under exceptional circumstances, which must have management approval and written justification for access. (Req 8.2.2)
  5. Console Access for NHI: Interactive login for system/application accounts is strictly prohibited and only allowed in exceptional cases with time restrictions, documented justification, and management approval. User identity verification is required, and all actions must be traceable to specific users. (Req 8.6.1)
  6. Password and key rotation: Passwords for application and system accounts must be changed regularly and immediately if compromise is suspected or confirmed. These credentials must be created with complexity levels appropriate to their change frequency. This requirement remains a best practice until March 31, 2025, after which it becomes mandatory and must be fully evaluated during PCI DSS assessments. (Req 8.6.3)
  7. Logging: Audit logs capture all actions taken by any individual with administrative access, including any interactive use of application or system accounts. (Req 10.2.1.2)

Ensuring PCI DSS compliance in identity security requires a proactive approach to access management for both human and non-human identities. Andromeda Security can help you gain complete visibility and inventory across your entire identity ecosystem,  strengthen your controls to enforce least privilege, provide the context your teams need to make intelligent access decisions and automate Just in Time access, and meet your compliance requirements.

 As cyber threats evolve, Andromeda Security can help you align your identity security with PCI requirements to safeguard your payment data and maintain customer trust.