Take the lead in data protection best practices with our unified SIEM solution!
Disclaimer: This guide has been created with reference to official documents on the PCI DSS published by relevant government authorities. It is intended to provide a clear and comprehensive explanation of PCI DSS Requirement 1. The contents are for informational purposes only and should not be considered as legal advice. Organizations should consult with a qualified PCI DSS consultant to ensure compliance.
PCI DSS Requirement 1: Install and maintain a firewall configuration to protect cardholder data
PCI DSS Requirement 1 mandates the installation and maintenance of a secure network, the cornerstone of any robust payment card processing system. This requirement encompasses the deployment of firewalls to protect cardholder data, especially between the internet and internal networks, and the restriction of direct public access between the internet and any system components that handle cardholder data.
It necessitates the creation of internal network zones to segregate cardholder data from other networks, implementing stringent access control measures, and regularly updating system configurations to mitigate security vulnerabilities. Additionally, this requirement stresses the importance of documenting network architecture and maintaining a comprehensive inventory of authorized hardware and software, ensuring an accurate understanding of the network's security posture and facilitating efficient responses to potential security incidents.
PCI DSS Requirement 1.1: Processes and mechanisms for installing and maintaining network security controls are defined and understood
This requirement is divided into sub-requirements 1.1.1 and 1.1.2. Let's explore these in detail.
PCI DSS Requirement 1.1.1: Manage security policies and procedures (for network security)
This requirement emphasizes the crucial aspects of managing security policies and procedures defined in Requirement 1 (install and maintain network security controls). It ensures that these policies are not merely created but effectively implemented and maintained for robust network security.
Definitions
- Security policy: A high-level document outlining the organization's overall security objectives and principles regarding network security.
- Operational procedure: A detailed document describing specific steps, controls, methods, and processes for carrying out network security activities in a consistent and compliant manner.
Business implication
Reduced risk of security incidents: By having documented, up-to-date, and well-understood security policies and procedures, you establish a clear framework for network security practices within your organization. This can significantly reduce the risk of security incidents stemming from human error or a lack of awareness.
Best practices to meet this requirement
- Document policies and procedures: Develop and document comprehensive security policies and operational procedures that address all the network security controls specified in Requirement 1.
- Maintain up-to-date documentation: Regularly review and update your security policies and procedures to reflect any changes in your network environment, technologies, or security threats. Don't wait for a specific review cycle; update them promptly whenever changes occur.
- Implement and enforce policies: Ensure that your documented policies and procedures are actively implemented and enforced within your organization.
- Communicate and train: Effectively communicate your security policies and procedures to all relevant personnel, including new hires. Conduct training sessions to ensure everyone understands their roles and responsibilities in maintaining network security.
How to meet this compliance requirement
Here's a table outlining how compliance with Requirement 1.1.1 will be verified during a PCI DSS assessment:
Requirement | Actions required | How the assessment is done |
1.1.1 | Examine documentation and interview personnel. | The assessor will: *Review your documented security policies and operational procedures to verify they address all network security controls defined in Requirement 1. *Interview relevant personnel to assess their awareness and understanding of the documented policies and procedures. |
PCI DSS Requirement 1.1.2: Define and communicate roles and responsibilities (for network security)
This requirement focuses on establishing clear roles and responsibilities for personnel involved in implementing and maintaining network security controls as outlined in Requirement 1 (install and maintain network security controls). It ensures everyone understands their part in safeguarding the network environment.
Definitions
- Roles: Defined functions or positions within an organization with specific network security tasks and duties.
- Responsibilities: The specific tasks, duties, and accountabilities assigned to individuals within their designated roles.
Business implication
Enhanced accountability and efficiency: By clearly defining and communicating roles and responsibilities for network security, you ensure everyone understands their specific tasks and ownership. This fosters accountability, promotes efficient management of security activities, and reduces the risk of gaps or missed tasks.
Best practices to meet this requirement
- Develop role definitions: Document clear descriptions of each role involved in network security activities outlined in Requirement 1. These descriptions should specify the responsibilities and authorities associated with each role.
- Assign responsibilities: Assign specific network security tasks and duties to individuals based on their roles and expertise. This can be done through a responsibility assignment matrix (RACI matrix) or similar mechanisms.
- Communicate expectations: Effectively communicate the defined roles and responsibilities to all relevant personnel. This can be achieved through training sessions, policy documents, or internal communication channels.
- Obtain acknowledgement: Consider having personnel acknowledge their understanding and acceptance of their assigned roles and responsibilities. This can be done through electronic signatures or written confirmation.
How to meet this compliance requirement
Here's a table outlining how compliance with Requirement 1.1.2 will be verified during a PCI DSS assessment:
Requirement | Actions required | How the assessment is done |
1.1.2.a | Examine documentation for roles and responsibilities. | The assessor will review your documented security policies, procedures, or separate documents to verify they define and assign roles and responsibilities for performing activities in Requirement 1. |
1.1.2.b | Interview personnel responsible for network security. | The assessor will interview personnel responsible for network security activities to verify: *Their assigned roles and responsibilities match documented definitions. *They understand their specific duties and how they contribute to overall network security. |
PCI DSS Requirement 1.2: Network security controls are configured and maintained.
This requirement is further divided into 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6, 1.2.7, and 1.2.8. Let's explore these in detail.
PCI DSS Requirement 1.2.1: Define and maintain network security configuration standards
This requirement focuses on establishing and maintaining documented configuration standards for network security controls (NSCs). These standards ensure consistent and secure configuration of firewalls, routers, and other network devices that control traffic flow within your network environment.
Definitions
- NSCs: Hardware and software components that enforce security policies on a network, such as firewalls, routers with access control lists (ACLs), and cloud virtual network security groups.
- Configuration standards: Documented guidelines that define the acceptable configurations for NSCs within your network. These standards specify permitted protocols and ports, and specific security settings for your network devices.
Business implication
Reduced risk of misconfigurations: By defining and enforcing configuration standards for your NSCs, you significantly reduce the risk of accidental misconfigurations that could create vulnerabilities in your network. This helps safeguard sensitive cardholder data and maintain compliance.
Best practices to meet this requirement
- Develop configuration standards: Create comprehensive documented standards that outline the acceptable configurations for all NSCs within your network. These standards should address:
- Permitted protocols and ports.
- Specific security settings for firewalls, routers, and other network devices.
- Configuration elements that are not allowed or considered insecure.
- Implement and maintain standards: Ensure that your NSC configurations are implemented and maintained according to your documented standards. This may involve automated configuration management tools or periodic manual reviews.
- Regularly review and update standards: Regularly review and update your configuration standards to reflect changes in your network environment, security threats, or industry best practices.
How to meet this compliance requirement
Here's a table outlining how compliance with Requirement 1.2.1 will be verified during a PCI DSS assessment:
Requirement | Actions required | How the assessment is done |
1.2.1.a | Examine configuration standards for NSC rulesets. | The assessor will review your documented configuration standards for NSCs to verify they address all elements specified in the requirement, including permitted protocols, ports, and security settings. |
1.2.1.b | Examine configuration settings for NSC rulesets. | The assessor will examine the actual configurations of your NSCs (firewalls, routers, etc.) to verify they are implemented according to the documented configuration standards. |
PCI DSS Requirement 1.2.2: Manage network changes through change control (for network security)
This requirement emphasizes the importance of managing changes to network connections and configurations of NSCs through a formal change control process defined in Requirement 6.5.1 (implement a change control process). This ensures that all network modifications are reviewed, approved, documented, and implemented securely.
Definitions:
- NSCs: Hardware and software components that enforce security policies on a network, such as firewalls, routers with ACLs, and cloud virtual network security groups.
- Change control process: A documented process that defines how changes to the IT infrastructure, including network components and configurations, are proposed, reviewed, approved, implemented, and verified.
Business implication
Reduced risk of security incidents: By managing network changes through a formal change control process, you significantly reduce the risk of unauthorized or poorly planned modifications that could introduce vulnerabilities or disrupt network security.
Best practices to meet this requirement
- Include network changes in change control: Ensure that your documented change control process explicitly includes changes to network connections and configurations of NSCs. This means defining the types of changes requiring approval, the approval workflow, and documentation requirements.
- Review changes for security impact: During the change control process, involve personnel with appropriate security expertise to review proposed network changes and assess their potential impact on network security.
- Implement changes securely: Once approved, implement network changes in a controlled and documented manner. This may involve using configuration management tools or predefined scripts to minimize the risk of errors.
- Verify changes and update documentation: After implementing a network change, verify its effectiveness and ensure it functions as intended without introducing security weaknesses. Update your network documentation to reflect the approved changes.
How to meet this compliance requirement
Here's a table outlining how compliance with Requirement 1.2.2 will be verified during a PCI DSS assessment:
Requirement | Actions required | How the assessment is done |
1.2.2.a | Examine documented change control procedures. | The assessor will review your documented change control process to verify it includes network connections and NSC configuration changes as part of its scope. |
1.2.2.b & 1.2.2.c | Examine network configurations and interview personnel. | The assessor will: *Examine network configurations to identify recent changes in network connections and NSC configurations.*Interview personnel responsible for network changes and review change control records.*Verify that identified changes were formally proposed, reviewed, approved, and implemented according to your documented change control process (Requirement 6.5.1). |
PCI DSS Requirement 1.2.3: Maintain accurate network diagrams
This requirement mandates maintaining accurate and up-to-date network diagrams that depict all connections between the cardholder data environment (CDE) and other networks, including any wireless networks.
Definitions
- CDE: The physical, logical, and virtual environment where cardholder data is stored, processed, or transmitted.
- Network diagram: A visual representation of a computer network, illustrating devices, connections, and how they interact.
Business implication
Enhanced security visibility and management: By maintaining accurate network diagrams, you gain a clear understanding of your network topology, including connections to the CDE. This improved visibility helps identify and address potential security gaps, manage network segmentation effectively, and simplify PCI DSS scope definition.
Best practices to meet this requirement
- Develop accurate diagrams: Create detailed and accurate network diagrams that illustrate:
- All connections to and from the CDE, including trusted and untrusted networks.
- Different network segments.
- Security controls like firewalls, intrusion detection/prevention systems (IDSs/IPSs), and web application firewalls (WAFs).
- All in-scope system components within the CDE, such as servers, databases, payment applications, and security tools.
- Out-of-scope areas clearly marked.
- Legends or keys explaining symbols and notations used.
- Maintain diagram updates: Regularly update your network diagrams to reflect any changes in your network environment, such as new devices, connections, or security controls added or removed.
- Define update process: Establish a clear process for updating your network diagrams. This process should include:
- Identifying personnel authorized to make updates.
- Procedures for documenting changes and obtaining approvals.
- Version control to track changes over time.
How to meet this compliance requirement
Here's a table outlining how compliance with Requirement 1.2.3 will be verified during a PCI DSS assessment:
Requirement | Actions required | How the assessment is done |
1.2.3.a | Examine diagrams and network configurations. | The assessor will: *Review your network diagrams to verify they accurately represent all connections between the CDE and other networks, including wireless networks. *Compare the network diagrams to actual network configurations to ensure consistency. |
1.2.3.b | Examine documentation and interview personnel. | The assessor will:*Review your documentation to understand your process for maintaining and updating network diagrams. *Interview personnel responsible for network diagrams to verify the update process is followed and diagrams are kept current. |
PCI DSS Requirement 1.2.4: Maintain accurate data flow diagrams
This requirement mandates maintaining accurate and up-to-date data flow diagrams that illustrate the movement of cardholder data across your network environment. This includes identifying how account data enters your systems, flows between components, and exits your network.
Definitions
- Account data: Any data that relates to a cardholder, including the full magnetic stripe or chip data, card verification value (CVV), expiration date, and service code.
- Data flow diagram: A visual representation of a system that shows the flow of data between its components.
Business implication
Enhanced data security and compliance: By clearly understanding how cardholder data moves within your network, you can identify potential security gaps and implement targeted controls to safeguard sensitive information. This helps reduce the risk of data breaches and simplifies PCI DSS compliance efforts.
Best practices to meet this requirement
- Develop detailed data flow diagrams: Create comprehensive diagrams that illustrate:
- All entry and exit points for cardholder data within your network environment.
- The flow of account data between different systems and network segments.
- Processing activities involving cardholder data, such as authorization, capture, settlement, and chargebacks.
- Different data acceptance channels, including card-present, card-not-present, and e-commerce.
- All methods of data transmission and storage, including electronic and physical forms (paper documents).
- The source and destination of all account data received or shared with third parties.
- Date of last update and personnel responsible for maintaining the data flow diagram.
- Maintain and update diagrams: Regularly update your data flow diagrams to reflect changes in your environment, such as new applications, network connections, or data processing workflows.
- Align with network diagrams: Ensure your data flow diagrams complement and align with your network diagrams, providing a comprehensive view of your network security posture and data flow patterns.
How to meet this compliance requirement
Here's a table outlining how compliance with Requirement 1.2.4 will be verified during a PCI DSS assessment:
Requirement | Actions required | How the assessment is done |
1.2.4.a | Examine data flow diagrams and interview personnel. | The assessor will: *Review your data flow diagrams to verify they depict all account data flows across systems and networks as specified in the requirement. *Interview personnel responsible for data flow diagrams and data security to ensure they understand the flow of cardholder data within your environment. |
1.2.4.b | Examine documentation and interview personnel. | The assessor will: *Review your documentation to understand your process for maintaining and updating data flow diagrams.*Interview personnel responsible for data flow diagrams to verify the update process is followed and diagrams are kept current. |
PCI DSS Requirement 1.2.5: Identify and approve allowed services, protocols, and ports
This requirement emphasizes identifying, documenting, and approving all services, protocols, and ports allowed on your network. It ensures that only essential network communication methods are enabled within the CDE and other network segments.
Definitions
- Services: Programs or applications that provide specific functionalities over a network (e.g., web server service, remote login service).
- Protocols: Defined set of rules that govern how data is formatted and transmitted over a network (e.g., TCP/IP, HTTP).
- Ports: Logical channels within a network connection used to differentiate between different services or applications (e.g., port 80 for web traffic, port 22 for Secure Shell[SSH]).
- CDE: The physical, logical, and virtual environment where cardholder data is stored, processed, or transmitted.
Business implication
Reduced attack surface: By identifying and disabling unnecessary services, protocols, and ports, you significantly reduce the attack surface of your network. This minimizes potential entry points for attackers and enhances the overall security posture of your CDE.
Best practices to meet this requirement:
- Develop an allowlist: Create a documented list of all approved services, protocols, and ports allowed on your network. This list should include a clear business justification for each allowed element.
- Perform risk assessments: Regularly assess the security risks associated with each allowed service, protocol, and port. Consider factors like inherent vulnerabilities and potential misuse scenarios.
- Implement strong approval processes: Establish a formal process for approving additions or changes to the allowlist. This process should involve personnel with appropriate security expertise and exclude those directly managing network configurations to avoid conflicts of interest.
How to meet this compliance requirement
Here's a table outlining how compliance with Requirement 1.2.5 will be verified during a PCI DSS assessment:
Requirement | Actions required | How the assessment is done |
1.2.5.a | Examine documentation for allowed services, protocols, and ports. | The assessor will review your documented list of allowed services, protocols, and ports. They will verify that: *The list includes all allowed elements. *Each entry has a documented business justification. *The approval process is defined and documented. |
1.2.5.b | Examine NSC configurations. | The assessor will examine the configurations of your firewalls, routers, and other NSCs to verify that only approved services, protocols, and ports are allowed to operate in your network. |
PCI DSS Requirement 1.2.6: Mitigate risks of insecure services, protocols, and ports
This requirement addresses the potential security risks associated with using insecure services, protocols, and ports on your network. It mandates identifying these elements, assessing their risks, and implementing compensating controls to mitigate those risks.
Definitions
- Insecure services, protocols, and ports: Services, protocols, and ports with known vulnerabilities or weaknesses that could be exploited by attackers to gain unauthorized access to your network or steal sensitive data (e.g., Telnet, FTP, unused high-numbered ports).
- Compensating controls: Security measures implemented to address weaknesses in a system or process, reducing the likelihood of a successful attack.
Business implication
Reduced risk of network compromise: By identifying and mitigating the risks associated with insecure network elements, you significantly reduce the probability of successful attacks that could disrupt your operations, damage your reputation, and lead to financial losses.
Best practices to meet this requirement
- Identify insecure elements: Maintain a documented list of all services, protocols, and ports currently used on your network. Regularly review this list and industry security resources to identify any elements considered insecure.
- Perform risk assessments: For each identified insecure element, conduct a risk assessment to understand the potential consequences of its exploitation. Consider factors like the likelihood of an attack, the value of targeted data, and the potential impact on your business.
- Implement mitigating controls: Based on your risk assessments, implement compensating controls to mitigate the risks associated with using insecure elements. These controls could include:
- Disabling unnecessary insecure services or protocols.
- Restricting access to insecure ports using firewalls.
- Implementing strong authentication and encryption measures for insecure services.
- Regularly patching and updating insecure services and protocols with the latest security fixes.
- Document justifications: Clearly document the business justifications for using any insecure elements and the compensating controls implemented to mitigate their risks.
How to meet this compliance requirement
Here's a table outlining how compliance with Requirement 1.2.6 will be verified during a PCI DSS assessment:
Requirement | Actions required | How the assessment is done |
1.2.6.a | Examine documentation for insecure elements and controls. | The assessor will review your documentation to verify: *You have a list of all services, protocols, and ports in use.*Insecure elements are identified within the list. *Risk assessments are performed for each identified insecure element.*Justifications are documented for using insecure elements. *Defined security features are documented to mitigate risks. |
1.2.6.b | Examine NSC configurations. | The assessor will examine the configurations of your firewalls and other NSCs to verify that the defined security features are implemented for each identified insecure service, protocol, and port. |
PCI DSS Requirement 1.2.7: Regularly review NSC configurations
This requirement mandates that you regularly review the configurations of your NSCs to ensure they remain relevant, effective, and aligned with your current business needs. These reviews should be conducted at least once every six months.
Definitions
- NSCs: Hardware and software components that enforce security policies on a network, such as firewalls, routers with ACLs, and cloud virtual network security groups.
- Business justification: A documented explanation for why a specific service, protocol, port, or network access rule is necessary for your business operations.
Business implication
Reduced risk of unauthorized access: By regularly reviewing NSC configurations, you identify and remove outdated rules or configurations that might allow unauthorized access to your network. This helps maintain a secure network environment and minimize the risk of data breaches.
Best practices to meet this requirement
- Develop a review process: Establish a formal process for reviewing NSC configurations at least every six months. This process should include:
- Defining the scope of the review (which NSCs and configurations will be reviewed).
- Defining the review methodology (manual, automated, or a combination).
- Documentation of review findings and actions taken.
- Assigning roles and responsibilities for conducting reviews.
- Perform reviews: Conduct thorough reviews of your NSC configurations according to your defined process. Verify that:
- All rules and configurations are relevant and have a current business justification.
- Outdated or unnecessary rules are removed or disabled.
- Configurations align with your documented allowed services, protocols, and ports (Requirement 1.2.5).
- Any discrepancies or uncertainties about a rule or configuration are documented and escalated for resolution.
- Consider more frequent reviews: If your network environment experiences high volumes of changes, consider conducting NSC configuration reviews more frequently than every six months to ensure ongoing security effectiveness.
How to meet this compliance requirement
Here's a table outlining how compliance with Requirement 1.2.7 will be verified during a PCI DSS assessment:
Requirement | Actions required | How the assessment is done |
1.2.7.a | Examine documentation for review procedures. | The assessor will review your documented process for reviewing NSC configurations. They will verify that: *The process is defined and documented. *The scope of the review is clearly defined. *The review frequency is at least once every six months. |
1.2.7.b | Examine review documentation and interview personnel. | The assessor will: *Review documentation of past NSC configuration reviews. *Interview personnel responsible for conducting reviews to verify they occur at least every six months. |
1.2.7.c | Examine NSC configurations for outdated rules. | The assessor will examine your NSC configurations to verify that configurations identified as no longer having a current business justification have been removed or updated. |
PCI DSS Requirement 1.2.8: Secure and maintain consistency of NSC configurations
This requirement emphasizes the importance of securing your NSC configuration files and ensuring they accurately reflect the active network configurations. This safeguards against unauthorized modifications and ensures your NSCs operate as intended.
Definitions
- NSCs: Hardware and software components that enforce security policies on a network, such as firewalls, routers with ACLs, and cloud virtual network security groups.
- Configuration files: Any file, setting, script, code, or parameter used to define or modify the behavior of NSCs. This includes both active configurations currently in use and backups or archived versions.
Business implication
Reduced risk of security misconfiguration: By securing NSC configuration files and maintaining consistency with active configurations, you minimize the risk of unauthorized changes or accidental misconfigurations. This helps ensure your NSCs function effectively to protect sensitive data and business operations.
Best practices to meet this requirement
- Secure configuration files: Implement controls to safeguard NSC configuration files from unauthorized access. This could include:
- Strong access controls on file servers and storage locations.
- Encryption of configuration files at rest and in transit.
- User activity monitoring to detect suspicious attempts to access or modify configuration files.
- Maintain configuration consistency: Establish a process to ensure your NSC configuration files accurately reflect the actual network configuration. This could involve:
- Version control systems for tracking changes to configuration files.
- Automated configuration deployment tools to ensure consistent implementation across all NSCs.
- Regular reviews to compare configuration files with active network settings and identify any discrepancies.
- Implement change management: Enforce a formal change management process for modifying NSC configurations. This process should include:
- Clear approval procedures for proposed configuration changes.
- Documentation of changes made and the rationale behind them.
- Testing of changes in a non-production environment before deployment.
How to meet this compliance requirement
Here's a table outlining how compliance with Requirement 1.2.8 will be verified during a PCI DSS assessment:
Requirement | Actions required | How the assessment is done |
1.2.8 | Examine configuration files and interview personnel. | The assessor will: *Review your security controls for protecting NSC configuration files. *Verify that access controls are implemented to restrict unauthorized access. *Interview personnel responsible for managing NSCs to understand your process for maintaining configuration consistency and change management. |
PCI DSS Requirement 1.3: Network access to and from the CDE is restricted
This requirement is further divided into 1.3.1, 1.3.2, and 1.3.3. Let's explore these in detail.
PCI DSS Requirement 1.3.1: Restrict inbound traffic to the CDE
This requirement mandates restricting inbound traffic to your CDE to only the traffic essential for business operations. All other attempts to access the CDE from unauthorized sources, protocols, or ports must be explicitly denied.
Definitions
- CDE: The physical, logical, and virtual environment where cardholder data is stored, processed, or transmitted.
- NSCs: Hardware and software components that enforce security policies on a network, such as firewalls, routers with ACLs, and cloud virtual network security groups.
Business implication
Reduced risk of data breaches: By restricting inbound traffic to the CDE, you significantly reduce the attack surface for malicious actors. This minimizes the risk of unauthorized access attempts and potential data breaches that could disrupt your operations, damage your reputation, and incur financial penalties.
Best practices to meet this requirement
- Implement restrictive rules: Configure your NSCs to enforce a deny-all policy by default. This blocks all inbound traffic to the CDE unless explicitly allowed through defined rules.
- Define allowed traffic: Create specific rules within your NSCs to permit only authorized inbound traffic to the CDE. This includes:
- Traffic from trusted sources with a legitimate business need to access the CDE (e.g., payment processors, internal applications).
- Specific protocols and ports required for authorized communication (e.g., HTTPS for secure web traffic).
- Regularly review traffic rules: Periodically review your NSC configurations to ensure inbound traffic rules remain accurate and reflect current business needs. Remove outdated rules or deny access for any unauthorized connections.
- Monitor for anomalies: Implement network traffic monitoring tools to detect suspicious or unusual inbound traffic patterns that could indicate potential attacks.
How to meet this compliance requirement
Here's a table outlining how compliance with Requirement 1.3.1 will be verified during a PCI DSS assessment:
Requirement | Actions required | How the assessment is done |
1.3.1.a | Examine NSC configuration standards. | The assessor will review your documented standards for configuring NSCs. They will verify that the standards mandate restricting inbound traffic to the CDE according to PCI DSS requirements. |
1.3.1.b | Examine NSC configurations. | The assessor will examine the actual configurations of your firewalls and other NSCs to verify that they are configured to restrict inbound traffic to the CDE as per your documented standards and PCI DSS requirements. |
PCI DSS Requirement 1.3.2: Restrict outbound traffic from the CDE
This requirement mandates restricting outbound traffic originating from your CDE to only the traffic essential for legitimate business operations. All other attempts to communicate with unauthorized external destinations must be explicitly denied.
Definitions
- CDE: The physical, logical, and virtual environment where cardholder data is stored, processed, or transmitted.
- NSCs: Hardware and software components that enforce security policies on a network, such as firewalls, routers with ACLs, and cloud virtual network security groups.
Business implication
Reduced risk of data exfiltration: By restricting outbound traffic from the CDE, you minimize the risk of sensitive data being exfiltrated by malicious actors or compromised systems within your network. This helps protect cardholder data and prevents potential data breaches that could lead to financial penalties and reputational damage.
Best practices to meet this requirement
- Implement restrictive rules: Configure your NSCs to enforce a deny-all policy by default for outbound traffic from the CDE. This blocks all outbound communication unless explicitly allowed through defined rules.
- Define allowed traffic: Create specific rules within your NSCs to permit only authorized outbound traffic from the CDE. This could include:
- Traffic destined for trusted external services required for business operations (e.g., payment processors, fraud analysis tools).
- Specific protocols and ports required for authorized communication (e.g., HTTPS for secure data transmission).
- Regularly review traffic rules: Periodically review your NSC configurations to ensure outbound traffic rules remain accurate and reflect current business needs. Remove outdated rules or deny access for any unauthorized connections.
- Monitor for anomalies: Implement network traffic monitoring tools to detect suspicious or unusual outbound traffic patterns that could indicate potential data exfiltration attempts.
How to meet this compliance requirement
Here's a table outlining how compliance with Requirement 1.3.2 will be verified during a PCI DSS assessment:
Requirement | Actions required | How the assessment is done |
1.3.2.a | Examine NSC configuration standards. | The assessor will review your documented standards for configuring NSCs. They will verify that the standards mandate restricting outbound traffic from the CDE according to PCI DSS requirements. |
1.3.2.b | Examine NSC configurations. | The assessor will examine the actual configurations of your firewalls and other NSCs to verify that they are configured to restrict outbound traffic from the CDE as per your documented standards and PCI DSS requirements. |
PCI DSS Requirement 1.3.3: Secure wireless network access to the CDE
This requirement mandates securing all wireless networks that connect to the CDE. NSCs must be implemented between these wireless networks and the CDE to restrict access. By default, all wireless traffic from these networks is denied entry into the CDE. Only specifically authorized wireless traffic with a legitimate business need is allowed access.
Definitions
- CDE: The physical, logical, and virtual environment where cardholder data is stored, processed, or transmitted.
- NSCs: Hardware and software components that enforce security policies on a network, such as firewalls, IDSs/IPSs, and wireless access points (WAPs) with appropriate access control configurations.
- Wireless Traffic: Data transmitted over a wireless network using radio waves instead of physical cables.
Business implication:
Reduced Risk of Wireless Network Attacks: By securing wireless network access to the CDE, you significantly reduce the risk of unauthorized access attempts by malicious actors exploiting vulnerabilities in wireless networks. This helps protect sensitive cardholder data and prevents potential data breaches that could disrupt operations, damage reputation, and incur financial penalties.
Best practices to meet this requirement:
- Implement Network Segmentation: Physically separate your wireless networks from the wired network segment containing the CDE whenever possible. This creates an additional layer of security by requiring traffic to pass through a security control before reaching the CDE.
- Deploy NSCs: Install and configure NSCs between all wireless networks and the CDE. This could include firewalls, IDS/IPS systems, or appropriately configured WAPs that enforce strong access control measures.
- Restrict wireless access by default: Configure your NSCs to deny all wireless traffic by default attempting to access the CDE. This ensures only explicitly allowed and authorized wireless devices can gain access.
- Implement strong wireless security: On your wireless networks, enforce robust security measures such as WPA2 or WPA3 encryption, strong password complexity requirements, and regular password rotation for wireless access.
- Monitor wireless network activity: Continuously monitor your wireless network activity for suspicious or unauthorized devices or access attempts.
How to meet this compliance requirement
Here's a table outlining how compliance with Requirement 1.3.3 will be verified during a PCI DSS assessment:
Requirement | Actions required | How the assessment is done |
1.3.3 | Examine network diagrams and configurations. | The assessor will review your network diagrams and configurations to verify that: *NSCs are implemented between all wireless networks and the CDE.*The configurations of these NSCs deny wireless traffic by default and only allow access for authorized devices with a business justification. |
PCI DSS Requirement 1.4: Network connections between trusted and untrusted networks are controlled
This requirement is sub-divided into 1.4.1, 1.4.2, 1.4.3, 1.4.4, and 1.4.5. Let's explore these in detail.
PCI DSS Requirement 1.4.1: Implement NSCs between trusted and untrusted networks
This requirement mandates implementing NSCs at the boundaries between trusted and untrusted networks. These controls monitor and control access, minimizing the risk of unauthorized individuals gaining access to your internal network containing sensitive data like cardholder information.
Definitions
- NSCs: Hardware and software components that enforce security policies on a network, such as firewalls, (IDSs/IPSs), and routers with ACLs.
- Trusted network: A network segment containing critical systems and resources, including the CDE.
- Untrusted network: A network segment considered less secure and potentially exposed to higher risks, such as the public internet, guest Wi-Fi networks, or networks of partner organizations.
Business implication
Reduced risk of network intrusions: By implementing NSCs between trusted and untrusted networks, you create a security barrier that filters incoming and outgoing traffic. This helps prevent unauthorized access attempts, malware infiltration, and data breaches that could disrupt operations, damage your reputation, and lead to financial penalties.
Best practices to meet this requirement
- Identify network segments: Clearly define the boundaries between your trusted network (containing the CDE) and untrusted networks (e.g., internet, guest Wi-Fi).
- Deploy NSCs: Implement appropriate NSCs at the connection points between trusted and untrusted networks. Common options include:
- Firewalls: These inspect all incoming and outgoing traffic, enforcing access control rules based on defined security policies.
- IDSs/IPSs: These systems monitor network traffic for suspicious activity and can block or alert on potential attacks.
- Routers with ACLs: These devices route traffic and enforce access rules based on source and destination addresses, ports, and protocols.
- Segment the CDE: If your demilitarized zone (DMZ) processes or transmits cardholder data (e.g., e-commerce website), it becomes part of the CDE. Ensure the DMZ is properly segmented from the internal trusted network using additional firewalls or access control mechanisms.
- Maintain secure configurations: Configure your NSCs with robust security settings and access control rules that permit only authorized traffic flow between networks. Regularly review and update these configurations to reflect changes in your network environment.
How to meet this compliance requirement
Here's a table outlining how compliance with Requirement 1.4.1 will be verified during a PCI DSS assessment:
Requirement | Actions required | How the assessment is done |
1.4.1.a | Examine configuration standards and network diagrams. | The assessor will review your documented network diagrams and configuration standards to verify that NSCs are defined for connections between trusted and untrusted networks. |
1.4.1.b | Examine network configurations. | The assessor will examine the actual configurations of your firewalls, routers, and other NSCs to verify that they are implemented according to your documented standards and effectively segregate trusted and untrusted networks. |
PCI DSS Requirement 1.4.2: Restrict inbound traffic from untrusted networks to trusted networks
This requirement mandates restricting inbound traffic originating from untrusted networks (like the internet) and entering your trusted network (containing the CDE). Only two types of inbound traffic are allowed:
- Communications with authorized public services: This includes traffic destined for system components authorized to provide publicly accessible services like web servers, email servers, or DNS servers.
- Stateful responses: This refers to responses from untrusted networks to communication initiated by authorized components within your trusted network. For example, if a user within your trusted network initiates a web browsing session, the response traffic from the web server on the internet would be allowed.
All other inbound traffic attempts from untrusted networks must be explicitly denied by your NSCs.
Definitions
- NSCs: Hardware and software components that enforce security policies on a network, such as firewalls, IDSs/IPSs, and routers with ACLs.
- Trusted network: A network segment containing critical systems and resources, including the CDE.
- Untrusted network: A network segment considered less secure and potentially exposed to higher risks, such as the public internet, guest Wi-Fi networks, or networks of partner organizations.
- Stateful inspection: An NSC feature that tracks the status (or state) of each network connection. This helps distinguish legitimate responses to authorized requests from potentially malicious traffic attempting to bypass security controls.
Business implication
Reduced risk of external attacks: By strictly limiting inbound traffic from untrusted networks, you significantly reduce the attack surface for malicious actors attempting to exploit vulnerabilities in your publicly accessible systems. This helps safeguard your internal network (including the CDE) from unauthorized access, data breaches, and potential disruptions to critical business operations.
Best practices to meet this requirement
- Implement stateful firewalls: Deploy firewalls with stateful inspection capabilities at the boundaries between your trusted and untrusted networks. Stateful firewalls track the status of network connections and can effectively distinguish legitimate responses from unauthorized attempts.
- Define allowed services: Clearly define which system components in your trusted network are authorized to provide publicly accessible services. This helps you configure your NSCs to allow only the necessary inbound traffic for these services (e.g., web traffic on port 80 or email traffic on port 25).
- Deny all other traffic: Configure your NSCs to deny all inbound traffic from untrusted networks by default. This prevents unauthorized access attempts that might exploit unknown vulnerabilities in your systems.
- Segment public-facing systems: Consider placing publicly accessible systems like web servers in a separate network segment (e.g., a DMZ) that is further isolated from your internal trusted network with additional firewalls or access control mechanisms.
How to meet this compliance requirement
Here's a table outlining how compliance with Requirement 1.4.2 will be verified during a PCI DSS assessment:
Requirement | Actions required | How the assessment is done |
1.4.2 | Examine NSC configurations and vendor documentation. | The assessor will review the configurations of your firewalls and other NSCs to verify that they are configured to restrict inbound traffic from untrusted networks according to PCI DSS requirements. They will also examine vendor documentation for your NSCs to ensure built-in security functionality related to stateful inspection is not disabled. |
PCI DSS Requirement 1.4.3: Implement anti-spoofing measures
This requirement mandates implementing anti-spoofing measures within your NSCs to detect and block packets with forged source IP addresses from entering your trusted network (containing the CDE).
Definitions
- NSCs: Hardware and software components that enforce security policies on a network, such as firewalls, IDSs/IPSs, and routers with advanced filtering capabilities.
- Trusted network: A network segment containing critical systems and resources, including the CDE.
- IP address: A unique identifier assigned to a device on a network that allows for communication between devices.
- Spoofing: The act of falsifying the source IP address in a network packet to disguise the true origin of the packet and potentially gain unauthorized access to a network.
Business implication
Reduced risk of internal network attacks: By implementing anti-spoofing measures, you prevent malicious actors from disguising their IP addresses and potentially gaining access to your trusted network as a trusted source. This helps safeguard your internal network (including the CDE) from internal attacks, data breaches, and potential disruptions to critical business operations.
Best practices to meet this requirement
- Verify NSC capabilities: Ensure your firewalls or other NSCs have built-in anti-spoofing functionalities or advanced filtering capabilities to detect and block packets with forged source IP addresses.
- Consult vendor documentation: Refer to the documentation for your NSCs to understand their specific anti-spoofing features and any configuration options available.
- Maintain secure configurations: If your NSCs allow configuration of anti-spoofing settings, ensure they are enabled and configured effectively to block spoofed traffic.
How to meet this compliance requirement
Here's a table outlining how compliance with Requirement 1.4.3 will be verified during a PCI DSS assessment:
Requirement | Actions required | How the assessment is done |
1.4.3 | Examine NSC configurations and vendor documentation. | The assessor will review the configurations of your firewalls and other NSCs to verify that anti-spoofing measures are enabled (if configurable) and functioning properly. Additionally, they will examine vendor documentation to confirm the presence and capabilities of anti-spoofing functionalities within your NSCs. |
PCI DSS Requirement 1.4.4: Protect cardholder data from untrusted networks
This requirement mandates that system components storing cardholder data must not be directly accessible from untrusted networks like the public internet. NSCs must be implemented to ensure a physical or logical separation between the systems storing cardholder data (part of the CDE) and untrusted networks.
Definitions
- NSCs: Hardware and software components that enforce security policies on a network, such as firewalls, IDSs/IPSs, and routers with ACLs.
- Trusted network: A network segment containing critical systems and resources, including the CDE.
- Untrusted network: A network segment considered less secure and potentially exposed to higher risks, such as the public internet, guest Wi-Fi networks, or networks of partner organizations.
- Cardholder data: Any data that relates to a cardholder, including the full magnetic stripe or chip data, CVV, expiration date, and service code.
Business implication
Reduced risk of data breaches: By isolating cardholder data from untrusted networks, you significantly reduce the risk of unauthorized access attempts by malicious actors on the internet. This helps safeguard sensitive cardholder data from breaches that could lead to financial penalties, reputational damage, and potential lawsuits.
Best practices to meet this requirement
- Segment the CDE: Physically or logically separate the network segment containing systems that store cardholder data from untrusted networks. Firewalls or other NSCs with access control rules can be used to enforce this separation.
- Limit network access: Restrict access to systems storing cardholder data to authorized personnel within your trusted network. Implement strong authentication and authorization controls to prevent unauthorized access attempts.
- Avoid storing data in untrusted locations: Do not store cardholder data on systems directly accessible from the internet, such as web servers in a DMZ. Consider alternative solutions like secure cloud storage or dedicated database servers within your trusted network.
- Secure data in transit: If you need to transmit cardholder data across networks (e.g., for payment processing), ensure it is encrypted using strong cryptographic protocols like TLS/SSL.
How to meet this compliance requirement
Here's a table outlining how compliance with Requirement 1.4.4 will be verified during a PCI DSS assessment:
Requirement | Actions required | How the assessment is done |
1.4.4.a | Examine network diagrams and data flow diagrams. | The assessor will review your network diagrams and data flow diagrams to verify that they document the physical or logical separation between the CDE and untrusted networks. |
1.4.4.b | Examine NSC configurations. | The assessor will examine the configurations of your firewalls and other NSCs to verify that they are configured to prevent direct access to systems storing cardholder data from untrusted networks. |
PCI DSS Requirement 1.4.5: Limit disclosure of internal network information
This requirement mandates restricting the disclosure of internal network information, specifically internal IP addresses and routing information, to only authorized parties. This helps prevent unauthorized individuals from gaining knowledge of your network structure and potentially exploiting vulnerabilities to gain access.
Definitions
- Internal IP addresses: Private IP addresses assigned to devices within your internal network, not directly routable on the public internet.
- Routing information: Data that defines how network traffic is directed and routed between different network segments.
- Authorized parties: Individuals with a legitimate business need to know internal network information, such as network administrators or security personnel.
Business implication
Reduced risk of network intrusions: By restricting the disclosure of internal network information, you make it more difficult for malicious actors to identify potential vulnerabilities and target specific devices within your network. This helps safeguard your internal network (including the CDE) from unauthorized access attempts and potential data breaches.
Best practices to meet this requirement
- Implement network segmentation: Segment your network into different zones (e.g., trusted, DMZ, untrusted) with firewalls or ACLs controlling traffic flow between zones. This minimizes the exposure of internal network information to unauthorized users.
- Use network address translation (NAT): Implement NAT to translate public internet routable IP addresses to private internal IP addresses for your internal devices. This hides the internal network structure from external attackers.
- Deploy proxy servers: Consider placing system components behind proxy servers that act as intermediaries for communication between your internal network and the internet. Proxy servers can further restrict the exposure of internal IP addresses.
- Control routing information disclosure: Configure your network devices to limit routing information advertisement for internal network segments. This prevents unauthorized individuals from learning about the layout of your internal network.
- Educate personnel: Train your employees on the importance of protecting internal network information and the risks associated with disclosing it to unauthorized individuals.
How to meet this compliance requirement
Here's a table outlining how compliance with Requirement 1.4.5 will be verified during a PCI DSS assessment:
Requirement | Actions required | How the assessment is done |
1.4.5.a | Examine NSC configurations. | The assessor will review the configurations of your firewalls, routers, and other NSCs to verify that they are not configured to publicly disclose internal IP addresses or routing information. |
1.4.5.b | Interview personnel and examine documentation. | The assessor will interview network administrators and security personnel to understand how internal network information is controlled. They will also review relevant documentation like network security policies and procedures to verify controls are in place to limit disclosure to authorized parties only. |
PCI DSS Requirement 1.5: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated
This requirement is further divided into sub-requirement 1.5.1. Let's explore this in detail.
PCI DSS Requirement 1.5.1: Implement security controls on devices connecting to untrusted networks and the CDE
This requirement mandates implementing security controls on any computing device (company-owned or employee-owned) that can connect to both untrusted networks (like the internet) and the CDE. These controls aim to prevent threats from entering your network through these devices.
Definitions
- Security controls: Measures or safeguards designed to protect your network and systems from unauthorized access, data breaches, and other security risks. Examples include firewalls, anti-virus software, and encryption.
- Untrusted network: A network segment considered less secure and potentially exposed to higher risks, such as the public internet, guest Wi-Fi networks, or networks of partner organizations.
- CDE: The portion of your network that stores, processes, or transmits cardholder data.
- Host-based controls: Security controls implemented directly on a computing device, such as anti-virus software or personal firewalls.
- Network-based controls: Security controls implemented on the network infrastructure, such as firewalls or IDSs.
Business implication
Reduced risk of network intrusions: By implementing robust security controls on devices accessing both the internet and the CDE, you significantly reduce the risk of malware or other threats compromising those devices and potentially gaining access to your CDE. This helps safeguard sensitive cardholder data from breaches that could lead to financial penalties, reputational damage, and potential lawsuits.
Best practices to meet this requirement
- Define security configurations: Develop and document security configuration standards for devices connecting to both untrusted networks and the CDE. These standards should specify settings for anti-virus software, firewalls, and other relevant security controls.
- Deploy host-based controls: Install and maintain anti-virus software, endpoint detection and response (EDR) solutions, and personal firewalls on all devices accessing the CDE, regardless of ownership (company or employee).
- Enforce configuration settings: Implement mechanisms (e.g., Group Policy Objects in Active Directory) to enforce the defined security configurations on managed devices. Consider mobile device management (MDM) solutions for employee-owned devices.
- Limit user modifications: Restrict users' ability to modify security controls on their devices. Any exceptions for temporary disabling of controls must be documented, authorized by management on a case-by-case basis, and accompanied by additional security measures during the disabling period.
- Educate users: Train employees on the importance of maintaining strong security controls on their devices, especially those accessing the CDE and the internet.
How to meet this compliance requirement
Here's a table outlining how compliance with Requirement 1.5.1 will be verified during a PCI DSS assessment:
Requirement | Actions required | How the assessment is done |
1.5.1.a | Examine policies, configuration standards, and interview personnel. | The assessor will review your documented security policies, configuration standards for devices accessing both untrusted networks and the CDE, and interview IT personnel to understand how security controls are implemented. |
1.5.1.b | Examine configuration settings on computing devices. | The assessor will sample a selection of devices (company-owned and employee-owned, if applicable) to verify that security controls are configured according to your documented standards. This may involve reviewing anti-virus software settings, firewall configurations, and user permissions related to security controls. |