by | Jan 18, 2023

NOTE: This article has been updated to include the PCI DSS Version 3.2.1 to 4.0 Summary of Changes for HPE NonStop™ Servers  

In March 2022, the PCI Security Standards Council released the new Payments Card Industry Data Security Standard version 4.0 (PCI DSS 4.0). The latest version of the standard took 4 years to develop, requiring 3 rounds of requests for comments and over 6,000 comments from the community (present company included). PCI DSS 4.0 marks the 18th year of this critical security standard and is the most comprehensive version to date, with the document expanding from 139 pages for PCI v3.2.1 to 360 pages for PCI v4.0. There are 64 new requirements, 13 of which are effective starting March 2024 when PCI DSS v3.2.1 is officially retired. The remaining 54 requirements are best practices until March 2025. That doesn’t mean you can sit back and enjoy your current compliance status for the next 2 years. On the contrary, 2023 must be used as a transition period to assess the new standard and modernize your security controls. There is a lot of work to do and very little time to spare. Do not assume because you were PCI 3.2.1 compliant that you will be PCI 4.0 compliant.

Below we break down the standard to make it less intimidating.

The Objective

Compliance has historically been a backward-looking activity. Compliance requirements are meant to prevent issues that happened in the past from happening again in the future. PCI DSS 4.0 changes that. Designed with a ZERO Trust strategy in mind to continuously meet the needs of the payment industry, the 4.0 standard now aligns with the usage of emerging technologies and takes into consideration the evolving threat landscape. You will see this in various guidelines that describe how to comply with certain requirements. Security-mature organizations now have the flexibility to design and implement controls to meet objectives. Compliance is no longer a point-in-time activity, it’s an ongoing and REAL-TIME process that is dependent on security controls and the quality of evidence.

PCI DSS 4.0 introduces two approaches for implementing and validating requirements:

    1. The traditional, prescriptive method.
    2. A new customized approach focusing on the objective of the requirement. (Not available for every PCI DSS requirement)

The Customized Approach

Businesses that employ the customized approach need to take the following into account: (1) fully understand the requirement. The PCI DSS 4.0 standard defines the requirement and gives a distinct, customized approach stating what must be handled to achieve the requirement’s goal. (2) the company must examine whether it is already adhering to the criteria as written. (3) if the traditional method is not satisfied, you should assess whether previously implemented (or planned) control processes are adequate to satisfy the requirement’s objective(s). Ultimately, the customized approach method provides a lot of flexibility in meeting the objectives of the requirement. If you’ve implemented a zero-trust strategy, there is no need to reinvent the wheel. You may already have the necessary controls, but it’s imperative to evaluate and document.

Keep the following in mind to determine if a customized approach is right for you:

  • Organizations can take a strategic approach Supports new, cutting-edge technologies with unique implementations where the traditional, defined approach may be insufficient
  • Flexibility to choose
  • Focuses on the “objective” of the PCI DSS requirement
  • Greater flexibility for evidencing a requirement is met
  • Allows for emerging technologies in Cardholder Data (CHD) environment to be evaluated
  • Greater overhead for organizations to document and demonstrate
  • Not an available option for all requirements

Requirement 3 – Protect Stored Account Data

Requirement 3 has expanded to include “Account Data” where previously it focused only on “Cardholder Data”. Account Data now includes Full track data, CVV, and PINs, which means more of your data is now in scope for PCI compliance such as additional files, subvolumes and directories, servers, email systems, and more. This may mean taking a look at your network topology to determine if the Cardholder Data Environment (CDE) needs to be expanded. Given this, the scope of Requirement 3 has changed significantly and should be properly evaluated for your organization.

Requirement 8 – Multi-Factor Authentication

One of the most significant changes that impact HPE NonStop environments is Requirement 8 and Multi-factor authentication (MFA).

Poor authentication controls are well known to be the leading cause of data breaches. Previously, requirement 8.3 applied only to remote access from untrusted networks. For example, an administrator, user, or vendor could remotely authenticate to a network using two-factor authentication, then pivot to any system within the network, including the CDE, all with just a single set of credentials. This poses a risk as it pushes security controls to the perimeter. Recent industry reports found that over 80 percent of data breaches involved weak, default, or stolen credentials.

Additionally, Virtual Private Networks (VPN) caused interesting exceptions. Some point-to-point VPN tunnels could be considered local network access, with the devices on the other end of the tunnel not requiring two-factor authentication for access to the CDE. Another common method used to meet this requirement is having system administrators use Remote Desktop technology for administrative functionality. An administrator could connect to a secure “jump server” which acts as a bastion host using two-factor authentication, then use their emulator to connect or “jump” from that server to the CDE, including the NonStop using their single set of credentials to perform their duties.

“Previously, this (requirement 8) applied only to remote access from untrusted networks,” PCI Security Standards Council CTO Troy Leach said in a statement. “A password alone should not be enough to verify the administrator’s identity and grant access to sensitive information.”

PCI-DSS 3.2 expanded requirement 8.3 to include all personnel with non-console administrator access to cardholder data and systems to use MFA. Meaning if an administrator is not physically in the data center on the keyboard, MFA for the system housing card data is a must. The requirement also changed its verbiage from “two-factor authentication” to “multi-factor authentication”. This meant local network access to servers, workstations, and network devices in the CDE must be protected with multi-factor authentication before granting administrator access to cardholder data or the systems housing them.

As expected, PCI DSS 4.0 continues to expand MFA with new requirements within 8.4

  • 4.1 MFA is implemented for all non-console access into the CDE for personnel with administrative access.
  • 4.2 MFA is implemented for all access into the CDE.
  • 4.3 MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE as follows:
    • All remote access by all personnel, both users and administrators, originating from outside the entity’s network.
    • All remote access by third parties and vendors.

Previously, remote workers connecting to the CDE through a VPN that required MFA was enough. Now MFA is required for ALL ACCESS to the CDE. In short, every attempt by any user to access the CDE must be authenticated with MFA. To comply with requirement 8.4 objectives, both 8.4.2 and 8.4.3 must be met.

XYPRO’s XYGATE User Authentication (XUA), included with all HPE NonStop servers, provides everything necessary to comply with these new MFA requirements. All HPE NonStop customers already have this capability with nothing additional to purchase. XUA supports authentication providers like RSA SecurID, RADIUS, Microsoft Active Directory, Microsoft Authenticator, Google Authenticate and will soon support PING, DUO, Delinea, and additional MFA providers.

Wireless Access

If wireless technology is used to store, process, or transmit account data (for example, wireless point-of-sale devices), or if a wireless local area network (WLAN) is part of or connected to the CDE, the PCI DSS requirements and testing procedures for securing wireless environments apply and must be performed.

Wireless detection must be performed even if wireless is not in use and even if the organization has a policy prohibiting its use. The relevant wireless requirements are listed below.

  • 3.1 Wireless vendor defaults are confirmed secure (encryption keys, passwords)
  • 2.3 Physical access to wireless access points is restricted
  • 2.1 Authorized and unauthorized wireless access points are detected and identified at least once every 3 months
    • If automated monitoring is used personnel are notified by generated alerts
  • 2.2 An inventory of authorized wireless access points is maintained, including business justification (to avoid unauthorized points mistaken for legitimate)
  • 10.5 The incident response plan includes monitoring and alert response for the detection of unauthorized wireless access points

Requirement 6: Develop and Maintain Secure Systems and Software

Requirement 6 applies to all system components, code repositories, testing platforms, and more that are used to develop, test, and secure applications that handle Account Data. There are several new requirements and updates that deal with bespoke and custom software. Commercial off the Shelf (COTS) software is not included in this requirement.

Bespoke software is software provided by a vendor or third party specifically developed to meet a single organization’s needs. The value of bespoke software is that it targets key business objectives for the company.

Commercial off the Shelf software is developed by a vendor, not tailored to a specific customer, and targeted for a mass market.

Custom software is similar to bespoke software except it’s developed internally by the business itself without the use of a third party.

  • 2.3 is a new requirement that states how enterprises must now identify and list all of their bespoke and custom software, as well as any third-party software included in their bespoke or custom software. This is to properly manage and update any vulnerabilities discovered in the third-party components. Payment software components and dependencies, including supported execution platforms or environments, third-party libraries, services, and other essential functions,” should be included in the inventory.
  • 3 Has critical components that require code reviews for bespoke and custom software. Vendors must have proof of code reviews available by someone other than the developer. All system components must also be protected from known vulnerabilities by installing applicable security patches and updates.
  • 4.1 requires public-facing websites and applications to protect against new threats and vulnerabilities and ensure these applications are protected from known attacks on an ongoing basis. As a customized approach, you can install automated technology that continually detects and prevents attacks in real-time.
  • 4.3 focuses on protecting the page scripts and other application files. This includes a method to ensure the integrity of the scripts and files and alert if they’ve been tampered with. On HPE NonStop servers, this can be accomplished with File Integrity monitoring.

File Integrity Monitoring in REQUIRED for PCI DSS 4.0 Compliance

It’s no secret, you’ve heard me say this (read) numerous times – multi-factor authentication and file integrity monitoring (FIM) give you the best cybersecurity return on investment.  You cannot be compliant with any cybersecurity framework without implementing these two controls. FIM is necessary for compliance with PCI DSS, GDPR, SOX, HIPAA, GLBA, FISMA, NIST, and more. For HPE NonStop servers, FIM is even recommended by HPE in the NonStop Hardening Guide. FIM alerts on modifications to files, objects, users, system configurations, and other critical components. FIM is even used for ransomware, malware, and virus protection. The only way to introduce a malicious payload is by copying a file or object onto your system. With FIM, as soon as that object appears, an alert is sent allowing for corrective action before a potential ransomware attack can cause damage.

PCI DSS 4.0 calls out FIM in the following requirements.

  • Requirement 10: Track and monitor all access to network resources and cardholder data
    • 3.4 Use file-integrity monitoring or change-detection mechanisms on logs to ensure that existing log data cannot be changed without generating alerts
  • Requirement 11: Regularly test security systems and processes
    • 5.2 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.
  • Requirement 12: Maintain a policy that addresses information security for all personnel
    • 10.5 Include alerts from security monitoring systems, including but not limited to intrusion-detection, intrusion-prevention, firewalls, and file-integrity monitoring systems.
  • Best Practices for Implementing PCI DSS into Business-as-Usual Processes

“Monitoring of security controls—such as firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), file-integrity monitoring (FIM), anti-virus, access controls, etc.—to ensure they are operating effectively and as intended.”

To comply with the PCI 4.0 FIM requirements, XYGATE SecurityOne (XS1) from HPE is the most complete and real-time FIM offering for HPE NonStop servers. XS1 supports both Guardian and OSS, can report on compliance in real-time as well as integrates FIM results with your enterprise SIEMS and SOARS such as SPLUNK, ELK, and others. For more information on XS1, please visit www.xypro.com

Noteworthy Changes and Requirements

The following new requirements are key to consider when planning out a PCI 4.0 implementation and XYPRO solutions from HPE provide the necessary solutions to comply with these requirements. Please see XYPRO’s “PCI DSS Version 3.2.1 to 4.0 Summary of Changes for HPE NonStop™ Servers” guide on www.xypro.com for more information on how to address these requirements.

  • 2.3.1 New Use the targeted risk analysis to define the frequency of “periodic” evaluations of systems not at risk of malware (i.e., the HPE NonStop servers)
  • 3.2.1 New Use the targeted risk analysis to define periodic malware scans
  • 3.4 Lockout user for 30 minutes after not more than 10 attempts (previously 6)
  • 3.6 New Minimum password length increased to 12 (previously 7)
  • 3.9 Password history of 4 passwords must be maintained OR previously used password cannot be used for 12 months
  • 3.9 Passwords must be changed every 90 days if NOT using MFA*
  • 6.2 New No hard-coded passwords for accounts that can be used for interactive login
  • 4.1.1 New The use of automated mechanisms for audit log reviews
  • 4.2.1 New Use targeted risk analysis for periodic log reviews
  • 10.4.1 New Regarding targeted risks analysis and frequency of periodic training

Summary

For a detailed step-by-step guide on the changes between PCI DSS 3.2.1 and PCI DSS 4.0, please see XYPRO’s “PCI DSS Version 3.2.1 to 4.0 Summary of Changes for HPE NonStop™ Servers” guide on www.xypro.com. XYPRO also provides a comprehensive PCI DSS gap assessment to identify and recommend areas that need to be addressed to ensure you pass your PCI 4.0 audit.  Now is the time to interpret the changes and determine how PCI 4.0 clarifications and added requirements impact your organization. The full summary of changes can be found on the PCI Security Standards website. See: https://listings.pcisecuritystandards.org/documents/PCI-DSS-Summary-of-Changes-v3_2_1-to-v4_0.pdf

Please visit www.xypro.com for more information.

Steve Tcherchian, CISSP, PCI-ISA, PCIP is the Chief Product Officer and Chief Information Security Officer for XYPRO Technology. Steve is on Forbes Technology Council, and the NonStop Under 40 executive board.

With over 20 years in the cybersecurity field, Steve is responsible for the strategy and innovation of XYPRO’s security product line as well as overseeing XYPRO’s risk, compliance, and security to ensure the best experience for customers in the Mission-Critical computing marketplace. 

Steve is an engaging and dynamic speaker who regularly presents on cybersecurity topics at conferences around the world.