Requirement 1: Install And Maintain Network Security Controls

Network Security Controls (NSCs), such as firewalls and other network security technologies, are network policy enforcement points that typically control network traffic between two or more logical or physical network segments (or subnets) based on pre-defined policies or rules. NSCs examine all network traffic entering (ingress) and leaving (egress) a segment and decide, based on the policies defined, whether the network traffic is allowed to pass or whether it should be rejected. Typically, NSCs are placed between environments with different security needs or levels of trust, however in some environments NSCs control the traffic to individual devices irrespective of trust boundaries. Policy enforcement generally occurs at layer 3 of the OSI model, but data present in higher layers is also frequently used to determine policy decisions.

Requirement 1: Install And Maintain Network Security Controls

1.1 Processes And Mechanisms For Installing And Maintaining Network Security Controls Are Defined And Understood

1.1.1 All security policies and operational procedures are: • Documented • Kept up to date • In use • Known to all affected parties

It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For these reasons, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle.

1.1.2 Roles and responsibilities for performing activities are documented, assigned, and understood

Roles and responsibilities may be documented within policies and procedures or maintained within separate documents.

As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities.

1.2 Network Security Controls (NSCs) Are Configured And Maintained

1.2.1 Configuration standards for NSC rulesets are: • Defined • Implemented • Maintained

These standards often define the requirements for acceptable protocols, ports that are permitted to be used, and specific configuration requirements that are acceptable. Configuration standards may also outline what the entity considers not acceptable or not permitted within its network.

1.2.2 All changes to network connections and to configurations of NSCs are approved and managed in accordance with the change control process

Changes should be approved by individuals with the appropriate authority and knowledge to understand the impact of the change. Verification should provide reasonable assurance that the change did not adversely impact the security of the network and that the change performs as expected.

To avoid having to address security issues introduced by a change, all changes should be approved prior to being implemented and verified after the change is implemented. Once approved and verified, network documentation should be updated to include the changes to prevent inconsistencies between network documentation and the actual configuration.

1.2.3 An accurate network diagram(s) is maintained that shows all connections between the CDE and other networks, including any wireless networks

All connections to and from the CDE should be identified, including systems providing security, management, or maintenance services to CDE system components. Entities should consider including the following in their network diagrams:

All locations, including retail locations, data centers, corporate locations, cloud providers, etc.

Clear labeling of all network segments.

All security controls providing segmentation, including unique identifiers for each control (for example, name of control, make, model, and version).

All in-scope system components, including NSCs, web app firewalls, anti-malware solutions, change management solutions, IDS/IPS, log aggregation systems, payment terminals, payment applications, HSMs, etc.

Clear labeling of any out-of-scope areas on the diagram via a shaded box or other mechanism.

Date of last update, and names of people that made and approved the updates.

A legend or key to explain the diagram.

Diagrams should be updated by authorized personnel to ensure diagrams continue to provide an accurate description of the network.

1.2.4 An accurate data-flow diagram(s) is maintained that meets the following: • Shows all account data flows across systems and networks • Updated as needed upon changes to the environment

The data-flow diagram should include all connection points where account data is received into and sent out of the network, including connections to open, public networks, application processing flows, storage, transmissions between systems and networks, and file backups.

The data-flow diagram is meant to be in addition to the network diagram and should reconcile with and augment the network diagram. As a best practice, entities can consider including the following in their data-flow diagrams:

All processing flows of account data, including authorization, capture, settlement, chargeback, and refunds.

All distinct acceptance channels, including card-present, card-not-present, and e-commerce.

All types of data receipt or transmission, including any involving hard copy/paper media.

The flow of account data from the point where it enters the environment, to its final disposition.

Where account data is transmitted and processed, where it is stored, and whether storage is short term or long term.

The source of all account data received (for example, customers, third party, etc.), and any entities with which account data is shared.

Date of last update, and names of people that made and approved the updates.

1.2.5 All services, protocols, and ports allowed are identified, approved, and have a defined business need

The security risk associated with each service, protocol, and port allowed should be understood. Approvals should be granted by personnel independent of those managing the configuration. Approving personnel should possess knowledge and accountability appropriate for making approval decisions.

1.2.6 Security features are defined and implemented for all services, protocols, and ports that are in use and considered to be insecure, such that the risk is mitigated

If insecure services, protocols, or ports are necessary for business, the risk posed by these services, protocols, and ports should be clearly understood and accepted by the organization, the use of the service, protocol, or port should be justified, and the security features that mitigate the risk of using these services, protocols, and ports should be defined and implemented by the entity.

1.2.7 Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective

This review, which can be implemented using manual, automated, or system-based methods, is intended to confirm that the settings that manage traffic rules, what is allowed in and out of the network, match the approved configurations.

The review should provide confirmation that all permitted access has a justified business reason. Any discrepancies or uncertainties about a rule or configuration should be escalated for resolution.

While this requirement specifies that this review occur at least once every six months, organizations with a high volume of changes to their network configurations may wish to consider performing reviews more frequently to ensure that the configurations continue to meet the needs of the business.

1.2.8 Configuration files for NSCs are: • Secured from unauthorized access • Kept consistent with active network configurations

To prevent unauthorized configurations from being applied to the network, stored files with configurations for network controls need to be kept up to date and secured against unauthorized changes.

Keeping configuration information current and secure ensures that the correct settings for NSCs are applied whenever the configuration is run.

1.3 Network Access To And From The Cardholder Data Environment Is Restricted

1.3.1 Inbound traffic to the CDE is restricted as follows: • To only traffic that is necessary • All other traffic is specifically denied

All traffic inbound to the CDE, regardless of where it originates, should be evaluated to ensure it follows established, authorized rules. Connections should be inspected to ensure traffic is restricted to only authorized communications for example, by restricting source/destination addresses and ports, and blocking of content.

1.3.2 Outbound traffic from the CDE is restricted as follows: • To only traffic that is necessary • All other traffic is specifically denied

All traffic outbound from the CDE, regardless of the destination, should be evaluated to ensure it follows established, authorized rules. Connections should be inspected to restrict traffic to only authorized communications for example, by restricting source/destination addresses and ports, and blocking of content.

1.3.3 NSCs are installed between all wireless networks and the CDE, regardless 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

The known (or unknown) implementation and exploitation of wireless technology within a network is a common path for malicious individuals to gain access to the network and account data. If a wireless device or network is installed without the entity’s knowledge, a malicious individual could easily and “invisibly” enter the network. If NSCs do not restrict access from wireless networks into the CDE, malicious individuals that gain unauthorized access to the wireless network can easily connect to the CDE and compromise account information.

1.4 Network Connections Between Trusted And Untrusted Networks Are Controlled

1.4.1 NSCs are implemented between trusted and untrusted networks

Implementing NSCs at every connection coming into and out of trusted networks allows the entity to monitor and control access and minimizes the chances of a malicious individual obtaining access to the internal network via an unprotected connection.

1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted to: • Communications with system components that are 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

System components that provide publicly accessible services, such as email, web, and DNS servers, are the most vulnerable to threats originating from untrusted networks.

Ideally, such systems are placed within a dedicated trusted network that is public facing (for example, a DMZ) but that is separated via NSCs from more sensitive internal systems, which helps protect the rest of the network in the event these externally accessible systems are compromised. This functionality is intended to prevent malicious actors from accessing the organization’s internal network from the Internet, or from using services, protocols, or ports in an unauthorized manner.

Where this functionality is provided as a built-in feature of an NSC, the entity should ensure that its configurations do not result in the functionality being disabled or bypassed.

1.4.3 Anti-spoofing measures are implemented to detect and block forged source IP addresses from entering the trusted network

Products usually come with anti-spoofing set as a default and may not be configurable. Entities should consult the vendor’s documentation for more information.

1.4.4 System components that store cardholder data are not directly accessible from untrusted networks

Cardholder data that is directly accessible from an untrusted network, for example, because it is stored on a system within the DMZ or in a cloud database service, is easier for an external attacker to access because there are fewer defensive layers to penetrate. Using NSCs to ensure that system components that store cardholder data (such as a database or a file) can only be directly accessed from trusted networks can prevent unauthorized network traffic from reaching the system component.

1.4.5 The disclosure of internal IP addresses and routing information is limited to only authorized parties

Methods used to meet the intent of this requirement may vary, depending on the specific networking technology being used. For example, the controls used to meet this requirement may be different for IPv4 networks than for IPv6 networks.

1.5 Risks To The CDE From Computing Devices That Are Able To Connect To Both Untrusted Networks And The CDE Are Mitigated

1.5.1 Security controls are implemented on any computing devices, including company- and employee-owned devices, that connect to both untrusted networks (including the Internet) and the CDE as follows: • Specific configuration settings are defined to prevent threats 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

The specific configuration settings are determined by the entity and should be consistent with its network security policies and procedures.

Where there is a legitimate need to temporarily disable security controls on a company-owned or employee-owned device that connects to both an untrusted network and the CDE for example, to support a specific maintenance activity or investigation of a technical problem the reason for taking such action is understood and approved by an appropriate management representative. Any disabling or altering of these security controls, including on administrators’ own devices, is performed by authorized personnel.

It is recognized that administrators have privileges that may allow them to disable security controls on their own computers, but there should be alerting mechanisms in place when such controls are disabled and follow up that occurs to ensure processes were followed.

Let’s Understand With An Example

This image is borrowed from the Cybersecurity Labs. Assume it represents your work environment and cardholder data is sitting on the server dz-win10.

Requirement 1.1

It’s all about defining policies and procedures. Then, allocate the responsibilities.

Requirement 1.2

Network diagrams and data-flow diagrams can help identify the CDE. In this case, dz-win10 and any system component that has direct access to dz-win10 are part of CDE and need to be protected. e.g. dsin-dangerzone which is the physical host, other VMs and the jump-server including the network topology is part of CDE. All services, protocols, and ports allowed on dz-win10 should be approved by the business and need to be reviewed at least once every six months.

Requirement 1.3

Inbound and outbound network traffic to dz-win10 should be controlled via network, switches, VLANs, virtualization or any other means possible. In this example, all the VMs can access the dz-win10 server, but we could have restricted the access and reduced the attack surface.

Requirement 1.4

You may define the trusted and untrusted networks and control the network access accordingly. Zero Trust which is the new norm, assumes all the networks are untrusted and always in breach.

Requirement 1.5

It may include a bring-your-own-device policy with some restrictions. The idea is to avoid unnecessary risks, that’s all. We mitigated this by introducing the jump-server.