The second part of our PCI DSS v4.0 Analysis series will look at requirements 1 and 2 of the standard, which is a part of the "Build and Maintain a Secure Network and Systems" group, focused on the monitoring and control of incoming and outgoing network traffic, as well as the configuration of system components or hardening. 

 

Click here to read Analysis of PCI DSS v4.0 Part I: Introduction

Analysis of PCI DSS v4.0 - Part 2: Requirements 1 & 2

Figure 1. Changes in the names of PCI DSS requirements 1 and 2

 

As pointed out in the part 1 Introduction analysis, these requirements have been renamed in version 4.0 to adapt to technological changes in security controls and to broaden the scope of their applicability. 

Requirement 1: Install and Maintain Network Security Controls

Advantio PCI DSS V4 Blog__10

The widespread use of virtualization technologies (including Software Defined Networks or SDN) and containers, as well as network infrastructures provided by cloud service providers, have had a significant impact on the first PCI DSS requirement. In fact, this change is evident in the renaming of the requirement and the removal of the term "firewall",  which has been in the standard since its inception.  

This change came as no surprise since the PCI SSC had already advanced some of these in its Information Supplement - Cloud Computing Guidelines, published in April 2018. This document examined a range of technical security considerations in multi-tenant cloud environments and emerging architectures such as the Internet of Things (IoT) or Fog Computing, as well as technologies such as Software Defined Networking (SND), containers, and Virtual Desktop Infrastructure (VDI). These technological changes are accompanied by new threats and new risks that were not managed correctly or were not fully adapted to the criteria of PCI DSS version 3.2.1.   

This is why in PCI DSS version 4.0 the traditional concept of "firewall" has been replaced by Network Security Controls (NSCs), a much broader concept that encompasses not only the firewalls mentioned above but also any other network technology that enables network traffic to be controlled between two or more logical or physical network segments to be controlled according to predefined rules or policies. 

Analysis of PCI DSS v4.0 - Part 2: Requirements 1 & 2Figure 2. Difference between the concept of "Firewall" and "Network Security Control"

 

This requirement retains the same organization of controls as PCI DSS v3.2.1, but some of them have been modified to fit the concept of NSCs. The most significant changes include: 

  • Configuration standards required for NSC filtering rules (1.2.1)
  • Changes to network connections and NSC’s configurations (1.2.2) must be implemented following the PCI DSS change management methodology specified in Requirement 6

  • In the case of network diagrams (1.2.3), best practices have been added, including labeling of network segments, identification of security controls that provide segmentation and their details (control name, model, version, etc.), the inclusion of all components in the scope, labeling of out-of-scope areas and document change information (date of last update, the person responsible for the change, the approver of the change, and an explanatory legend of the diagram)
  • In the case of data-flow diagrams (1.2.4), it is indicated that this diagram complements the network diagram and it is recommended to include all processes (authorization, capture, settlement, chargeback, refunds, etc.) and card data flows, including those involving physical media
  • Only identified, approved services, protocols, and ports with a defined business need (1.2.5) will be allowed, including additional controls for those considered insecure (1.2.6).
  • A semiannual review of the configuration of the NSCs should be conducted to confirm that they are relevant and effective (1.2.7)
  • If the NSCs use configuration files, these must be protected against unauthorized access and consistent with the active network configuration (1.2.8)

Likewise, the terminology of the network segments to be protected has been clarified, aligning it with the criteria described in the document Information Supplement - Guidance for PCI DSS Scoping and Network Segmentation.  The intention is to deploy a Network Security Control (NSC) between environments with different levels of trust (including internal networks). Based on this perspective, there are two main components of a network: 

  • Trusted networks: Any network that is under the control or management of the entity and complies with applicable PCI DSS requirements. This category includes the CDE and systems connected to or that may impact the security of the CDE.
  • Untrusted networks: Any network outside the control of the entity, including the Internet, dedicated communication channels, wireless networks, Internet Service Provider (ISP) networks, including mobile networks, and third-party networks. It is also clarified that if a network is outside the scope of the PCI DSS, it should be considered an untrusted network.  

This being so, the traffic filtering rules to be implemented by the NSCs should follow the following criteria: 

Analysis of PCI DSS v4.0 - Part 2: Requirements 1 & 2Figure 3. Criteria to follow in NSC policies or rules

 

An interesting issue in this version of the standard is that the requirement to implement a Demilitarized Network (DMZ) as a network segment to limit inbound traffic access (1.3.1 in PCI DSS 3.2.1) has disappeared, although it is now recommended as a best practice. However, if a DMZ is implemented and this segment processes or transmits payment card data, it should then be considered as part of the CDE. 

Requirement 2: Apply Secure Configurations to All System Components

Analysis of PCI DSS v4.0 - Part 2: Requirements 1 & 2

This requirement was renamed to make the applicability of secure configuration controls more flexible, emphasizing that not only default values must be changed, but also unnecessary software, functions, and accounts must be removed, and unnecessary services must be disabled or removed. It is also emphasized that this requirement applies not only to "traditional" systems but to any other system accessed through a cloud subscription service. 

Among the changes applied to this requirement are the following: 

  • The development of secure configuration standards is required for all system components (2.2.1), including cloud systems. Thus, as a reference, it is also added to the Cloud Security Alliance (CSA)
  • Vendor default accounts are allowed, as long as their default password is changed (2.2.2). Otherwise, these accounts must be removed or deleted. This is a major change from PCI DSS v3.2.1, as in that version of the standard these default accounts simply had to be removed or deleted and any exceptions had to be managed through compensating controls
  • The applicability of the concept of "primary function" (2.2.3) is clarified, allowing the coexistence of different primary functions with different security levels in the same system as long as they are isolated from each other or as long as they are all secured to the same level as the one with the highest security level. This concept had already been discussed previously in the Information Supplement - PCI DSS Virtualization Guidelines of June 2011, which focused on virtualization technologies, but in PCI DSS version 4.0 it has now been explicitly included
  • Only allow services, protocols, daemons, and other functions that are necessary, removing or disabling all others (2.2.4), justifying and adding additional controls to those that are considered insecure (2.2.5)
  • Only non-console administrative access will be allowed as long as it is encrypted using strong cryptography. This includes not only traditional (browser-based) administrative interfaces but also access through Application Programming Interfaces (APIs)
  • Additional controls are added to the process of secure configuration of wireless environments (2.3.1), including changing encryption keys of wireless networks transmitting card data or connected to the CDE if any person with knowledge of them leaves the company or if the key is compromised or suspected
  • Finally, the component inventory control (2.4 in PCI DSS v3.2.1) has been moved to requirement 12, a location more congruent with its objective
  • The following article will discuss PCI DSS requirements 3 and 4, which address the security of card data during storage and transmission

Missed reading the Introduction to PCI DSS v4.0? Click here to read now. Also, stay tuned for the next part in this series. 


Analysis of PCI DSS v4.0 - Part 2: Requirements 1 & 2

References

  • Information Supplement - Cloud Computing Guidelines https://www.pcisecuritystandards.org/pdfs/PCI_SSC_Cloud_Guidelines_v3.pdf  
  • Information Supplement - Guidance for PCI DSS Scoping and Network Segmentation Information Supplement - Guidance for PCI DSS Scoping and Network Segmentation
  • Information Supplement - PCI DSS Virtualization Guidelines Information Supplement - PCI DSS Virtualization Guidelines 
Column Header Text Column Header Text Column Header Text

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Discover More

Advantio_Blog_DNS_Diagram_V1 Image caption goes here. This is HTML text.

I am the Senior Security Consultant in Advantio. I have more than 15 years of experience, working both in South America and Europe. My information security background includes consultancy and audit, training, implementation of security technologies and design and policy development among others.

Certifications: CISSP, CISM, CISA, CRISC, CEH, CHFI, PCI QSA, QSA (P2PE), 3DS Assessor

Schedule a call with an expert