As we all know, data security is a constantly evolving field, and it’s essential to keep up with the latest standards and requirements. And mark your calendars, because the current PCI DSS v3.2.1 is set to retire on March 31st, 2024. That’s right, the PCI Security Standards Council (SSC) has announced the release of the new and improved PCI DSS v4.0, and compliance with this updated version is mandatory for organizations to maintain data security. So, let’s get started! To learn more about the other requirements of PCI DSS, check out our comprehensive guide on the “12 requirements of PCI DSS.”
If you’re new to this field, let us explain. The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements that apply to all organizations that process, store, or transmit cardholder data. These requirements are designed to protect sensitive cardholder information and prevent data breaches.
In this blog, we’re going to dive deep into the changes introduced in Requirement 1 from v3.2.1 to v4.0. Whether you’re a seasoned professional or just starting out in this field, we’ll help you understand these updates and stay ahead in the game of data security. So, let’s get started!
Modifications to Requirement 1 in the Transition from PCI DSS v3.2.1 to PCI DSS v4.0:
Below, we present a meticulously curated list that highlights the transformations in requirements and test procedures from PCI DSS v3.2.1 to v4.0, with a specific focus on Requirement 1.
A significant update is the shift in the principal requirement title to emphasize ‘network security controls’, replacing the terms ‘firewalls’ and ‘routers’. This change accommodates a broader spectrum of technologies that meet the security objectives traditionally addressed by firewalls. This will encompass all technologies categorized under Network Security Controls, including but not limited to WAF, IPS/IDS, DAM, DLP, PIM/PAM, MFA, and so on.
Also Read: PCI DSS Requirement 2
| PCI DSS v3.2.1 | PCI DSS v4.0 | |
|---|---|---|
| Defined Approach Requirements and Testing Procedures | 1.1.1 A formal process is mandated for the approval and testing of all network connections and modifications to firewall and router configurations. • 1.1.1.a Examine documented procedures to verify the presence of a formal process for the testing and approval of all network connections and changes to firewall and router configurations. • 1.1.1.b Choose a sample of network connections, conduct interviews with the personnel responsible, and review records to confirm that these network connections were approved and tested. • 1.1.1.c Identify a sample of modifications made to firewall and router configurations, compare these with the change records, and interview the personnel responsible to ensure that these changes were approved and tested. | 1.2.2 All modifications to network connections and NSC configurations must adhere to the change control process (Requirement 6.5.1). • 1.2.2.a Confirm that changes to network connections and NSC configurations are part of the formal change control process (Requirement 6.5.1) by reviewing documented procedures. • 1.2.2.b Identify modifications made to network connections by examining network configuration settings. Verify that these changes were approved and managed according to Requirement 6.5.1 by interviewing responsible personnel and reviewing change control records. • 1.2.2.c Identify modifications made to NSC configurations by examining network configuration settings. Confirm that these changes were approved and managed as per Requirement 6.5.1 by interviewing responsible personnel and reviewing change control records. |
| Defined Approach Requirements and Testing Procedures | 1.1.5 Outline of the groups’ roles and responsibilities in network component management. • 1.1.5.a Ensure that the standards for firewall and router configurations encompass the delineation of groups, roles, and responsibilities in managing network components. • 1.1.5.b Conduct interviews with staff in charge of network component management to verify that roles and responsibilities align with documentation. | 1.1.2 Documentation, assignment, and comprehension of roles and responsibilities for activities in Requirement 1. • 1.1.2.a Review documentation to confirm that roles and responsibilities for activities in Requirement 1 are documented and assigned. • 1.1.2.b Interview personnel responsible for activities in Requirement 1 to ensure that roles and responsibilities are assigned as documented and understood. |
| Defined Approach Requirements and Testing Procedures | 1.1 Formulate and apply firewall and router configuration standards that encompass the following: (Details not provided in the document) • Examine the firewall and router configuration standards and other specified documentation and confirm that the standards are comprehensive and implemented. | 1.2.1 Configuration standards for NSC rulesets are: - Defined - Implemented - Maintained • 1.2.1.a Review the configuration standards for NSC rulesets to confirm that the standards comply with all elements specified in this requirement. • 1.2.1.b Inspect configuration settings for NSC rulesets to ensure that rulesets are implemented in line with the configuration standards. |
| Defined Approach Requirements and Testing Procedures | 1.1.6 Documentation of business justification and approval for the use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure. • 1.1.6.a Confirm that firewall and router configuration standards include a documented list of all services, protocols, and ports, along with business justification and approval for each. • 1.1.6.b Identify allowed insecure services, protocols, and ports; and verify that security features are documented for each service. • 1.1.6.c Review firewall and router configurations to confirm that the documented security features are implemented for each insecure service, protocol, and port. | 1.2.5 All allowed services, protocols, and ports are identified, approved, and have a defined business need. • 1.2.5.a Review documentation to confirm that a list of all allowed services, protocols, and ports exists, including business justification and approval for each. • 1.2.5.b Inspect configuration settings for NSCs to ensure that only approved services, protocols, and ports are in use. 1.2.6 Security features are defined and implemented for all services, protocols, and ports in use that are considered insecure, thereby mitigating the risk. • 1.2.6.a Review documentation identifying all insecure services, protocols, and ports in use to confirm that security features are defined for each to mitigate the risk. • 1.2.6.b Inspect configuration settings for NSCs to confirm that the defined security features are implemented for each identified insecure service, protocol, and port. |
| Defined Approach Requirements and Testing Procedures | 1.1.7 Requirement to review firewall and router rule sets at least every six months. • 1.1.7.a Confirm that firewall and router configuration standards necessitate a review of firewall and router rule sets at least every six months. • 1.1.7.b Review documentation related to rule set reviews and interview responsible personnel to ensure that the rule sets are reviewed at least every six months. | 1.2.7 NSC configurations are reviewed at least semi-annually to ensure their relevance and effectiveness. • 1.2.7.a Review documentation to confirm that procedures are established for semi-annual reviews of NSC configurations. • 1.2.7.b Inspect documentation of NSC configuration reviews and interview responsible personnel to ensure that reviews are conducted at least semi-annually. • 1.2.7.c Review NSC configurations to confirm that configurations no longer supported by a business justification are either removed or updated. |
| Defined Approach Requirements and Testing Procedures | 1.2.2 Secure and synchronize router configuration files. •1.2.2.a Review router configuration files to ensure they are protected from unauthorized access. •1.2.2.b Inspect router configurations to confirm they are synchronized - for instance, the running (or active) configuration aligns with the start-up configuration (used when machines are booted). | 1.2.8 Configuration files for NSCs are: - Secured from unauthorized access. - Kept consistent with active network configurations. • Review configuration files for NSCs to ensure they comply with all elements specified in this requirement. |
| Defined Approach Requirements and Testing Procedures | 1.2.1 Limit inbound and outbound traffic to what is necessary for the cardholder data environment, and explicitly deny all other traffic. • 1.2.1.a Review firewall and router configuration standards to confirm that they identify the necessary inbound and outbound traffic for the cardholder data environment. • 1.2.1.b Inspect firewall and router configurations to ensure that inbound and outbound traffic is restricted to what is necessary for the cardholder data environment. • 1.2.1.c Review firewall and router configurations to confirm that all other inbound and outbound traffic is explicitly denied, for instance, by using an explicit “deny all” or an implicit deny after allow statement. 1.3.4 Do not permit unauthorized outbound traffic from the cardholder data environment to the Internet. • Inspect firewall and router configurations to confirm that outbound traffic from the cardholder data environment to the Internet is explicitly authorized. | 1.3.1 Inbound traffic to the CDE is restricted as follows: - Only necessary traffic is allowed. - All other traffic is explicitly denied. • 1.3.1.a Review configuration standards for NSCs to ensure they define the restriction of inbound traffic to the CDE in accordance with all elements specified in this requirement. • 1.3.1.b Inspect configurations of NSCs to confirm that inbound traffic to the CDE is restricted in line with all elements specified in this requirement. 1.3.2 Outbound traffic from the CDE is restricted as follows: - Only necessary traffic is allowed. - All other traffic is explicitly denied. • 1.3.2.a Review configuration standards for NSCs to ensure they define the restriction of outbound traffic from the CDE in accordance with all elements specified in this requirement. • 1.3.2.b Inspect configurations of NSCs to confirm that outbound traffic from the CDE is restricted in line with all elements specified in this requirement. |
| Defined Approach Requirements and Testing Procedures | 1.2.3 Install perimeter firewalls between all wireless networks and the cardholder data environment, and configure these firewalls to deny unauthorized traffic or, if necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment. • 1.2.3.a Review firewall and router configurations to confirm that perimeter firewalls are installed between all wireless networks and the cardholder data environment. •1.2.3.b Confirm that the firewalls deny unauthorized traffic or, if necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment. | 1.3.3 NSCs are installed between all wireless networks and the CDE, irrespective of whether the wireless network is a CDE, such that: - All wireless traffic from wireless networks into the CDE is denied by default. - Only wireless traffic with an authorized business purpose is allowed into the CDE. • Review configuration settings and network diagrams to confirm that NSCs are implemented between all wireless networks and the CDE, in line with all elements specified in this requirement. |
| Defined Approach Requirements and Testing Procedures | 1.3 Direct public access between the Internet and any system component in the cardholder data environment is prohibited. • Review firewall and router configurations—including but not limited to the choke router at the Internet, the DMZ router and firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segment—to ensure that there is no direct access between the Internet and system components in the internal cardholder network segment. | 1.4.1 NSCs are deployed between networks classified as trusted and those deemed untrusted. • 1.4.1.a Scrutinize configuration standards and network diagrams to affirm that NSCs are delineated between networks identified as trusted and untrusted. • 1.4.1.b Review network configurations to ascertain that NSCs are established between trusted and untrusted networks, in alignment with the documented configuration standards and network diagrams. |
| Defined Approach Requirements and Testing Procedures | 1.3.1 Establish a DMZ to confine inbound traffic to only those system components that offer authorized publicly accessible services, protocols, and ports. • Review firewall and router configurations to ensure that a DMZ is set up to restrict inbound traffic to only those system components that offer authorized publicly accessible services, protocols, and ports. 1.3.2 Restrict inbound Internet traffic to IP addresses located within the DMZ. • Inspect firewall and router configurations to confirm that inbound Internet traffic is confined to IP addresses within the DMZ. 1.3.5 Allow only “established” connections into the network. • Review firewall and router configurations to ensure that the firewall allows only established connections into the internal network and rejects any inbound connections not linked with a previously established session. | 1.4.2 Inbound traffic from untrusted networks to trusted networks is limited to: - Communications with system components authorized to provide publicly accessible services, protocols, and ports. - Stateful responses to communications initiated by system components in a trusted network. - All other traffic is denied. • Review vendor documentation and configurations of NSCs to confirm that inbound traffic from untrusted networks to trusted networks is restricted in line with all elements specified in this requirement. |
| Defined Approach Requirements and Testing Procedures | 1.3.6 Position system components that store cardholder data (like a database) within an internal network zone, isolated from the DMZ and other untrusted networks. • Review firewall and router configurations to confirm that system components storing cardholder data are located within an internal network zone, segregated from the DMZ and other untrusted networks. | 1.4.4 System components that store cardholder data are not directly accessible from untrusted networks. • 1.4.4.a Inspect the data-flow diagram and network diagram to ensure that it is documented that system components storing cardholder data are not directly accessible from untrusted networks. • 1.4.4.b Review configurations of NSCs to confirm that controls are in place such that system components storing cardholder data are not directly accessible from untrusted networks. |
| Defined Approach Requirements and Testing Procedures | 1.4 Install personal firewall software or equivalent functionality on any portable computing devices (including those owned by the company and/or employee) that connect to the Internet when outside the network (for example, employee-used laptops), and which are also used to access the CDE. Configurations for the firewall (or equivalent) include: • Defined specific configuration settings. • Active running of the personal firewall (or equivalent functionality). • Non-alterability of the personal firewall (or equivalent functionality) by users of the portable computing devices. 1.4.a Review policies and configuration standards to confirm: • The requirement of personal firewall software or equivalent functionality for all portable computing devices (including those owned by the company and/or employee) that connect to the Internet when outside the network (for example, employee-used laptops), and which are also used to access the CDE. • Defined specific configuration settings for the personal firewall (or equivalent functionality). • Active running configuration of the personal firewall (or equivalent functionality). • Configuration of the personal firewall (or equivalent functionality) to be non-alterable by users of the portable computing devices. 1.4.b Inspect a sample of company and/or employee-owned devices to verify: • Installation and configuration of the personal firewall (or equivalent functionality) as per the organization’s specific configuration settings. • Active running of the personal firewall (or equivalent functionality). • Non-alterability of the personal firewall (or equivalent functionality) by users of the portable computing devices. | 1.4.4 System components that store cardholder data are not directly accessible from untrusted networks. • 1.4.4.a Inspect the data-flow diagram and network diagram to ensure that it is documented that system components storing cardholder data are not directly accessible from untrusted networks. • 1.4.4.b Review configurations of NSCs to confirm that controls are in place such that system components storing cardholder data are not directly accessible from untrusted networks. 1.5.1 Security controls are implemented on any computing devices, including those owned by the company and/or employee, that connect to both untrusted networks (including the Internet) and the CDE as follows: • Specific configuration settings are defined to prevent threats from being introduced into the entity’s network. • Security controls are actively running. • Security controls are not alterable by users of the computing devices unless specifically documented and authorized by management on a case-by-case basis for a limited period. 1.5.1.a Review policies and configuration standards and conduct interviews with personnel to confirm that security controls for computing devices that connect to both untrusted networks and the CDE are implemented in accordance with all elements specified in this requirement. 1.5.1.b Inspect configuration settings on computing devices that connect to both untrusted networks and the CDE to ensure settings are implemented in line with all elements specified in this requirement |
You can also watch the video on PCI DSS Requirement 1
Conclusion:
We hope you have gained a comprehensive understanding of the changes in requirements. If you have any queries, we recommend visiting the official PCI DSS website for a more thorough understanding. At VISTA InfoSec, we strive to provide value by conducting in-depth research and incorporating these changes seamlessly. You can find more information about the changes in requirements in the subsequent sections. Thank you for reading.
Lets us help you
Need help navigating PCI DSS v4.0? We have been active in the PCI DSS space since 2008 and even certify payment brand. Our PCI DSS services provide assurance on card security controls, with offerings for both product platform and backend services attestation.
We have a dedicated team of auditors and a separate team for consulting/advisory assignments to even help our esteemed clients to define processes and achieve compliance.
We have completed multiple PCI DSS 4.0 certifications too right from scoping to Readiness Assessment, Advisory and Final Certification.
We are vendor neutral and have a strict no-outsourcing policy. We can also assist you with the technical assessments needed for PCI DSS Compliance – Vulnerability Assessment, Penetration Testing, Network Segmentation Testing, Network Architecture Review, Firewall Assessment, Secure Configuration Assessment, Web and Mobile Application Security Assessment, and Secure Code Review.
