Implementing PCI DSS v4 Using USP

You can implement PCI DSS v4 regulation compliance that is tailored to your specific business requirements and network topology using a Unified Security Policy (USP). View compliance reports from the violations browser at any time, and verify compliance with each specific regulation. If a regulation is not in compliance, identify the specific device and rule that is causing the violation.

Overview

To implement best practices or the compliance regulations of a standard, you need to create a USP Matrix containing the compliance zones required by the standard. The compliance zones are placeholder zones into which you place your network zones, using SecureTrack zone hierarchies. Your existing zones can then be collected into these compliance zones, to ensure compliance monitoring of your entire network. To ensure that you maintain ongoing compliance as your network topology evolves, we recommend that you periodically review the hierarchy of your compliance zones.

The required PCI DSS compliance zones are:

  • Corporate (representing all internal networks)
  • DMZ
  • Internet
  • PCI Applications
  • PCI Data
  • PCI Web
  • Wireless Networks

Create the USP

Before you create this USP, make sure all the required compliance zones have been created (see Network Zones).

  1. Browser > USP Viewer.
  2. Click +ADD USP.

  3. Select PCI-DSS from the menu. The zones required for PCI-DSS appear.

  4. For each required zone displayed, select the appropriate compliance zone.

  5. (optional) Enter the USP description.

  6. Click Create.

The PCI-DSS USP has now been created. You can click on the card to view the matrix in the USP Builder and modify the policy as needed.

The following requirements are defined in the USP matrix:

Source / Destination

DMZ

Corporate

PCI Applications

PCI Data

PCI Web

Wireless Networks

Internet

DMZ

 

R1.4.4

  • Restricted

R2.2.4

  • Restricted

R2.2.4

  • Restricted

R2.2.4

  • Restricted

R1.4.4

  • Restricted

R2.2.4

  • Restricted

Corporate

R1.2.5

  • Comments in all rules
  • ANY not allowed in source or destination

R1.4.4

  • Restricted

 

R2.2.4

  • Restricted

R1.3.1.b

  • Blocked

R2.2.4

  • Restricted

R2.2.4

  • Restricted

R2.2.4

  • Restricted

PCI Applications

R1.4.2

  • Restricted

R2.2.4

  • Restricted

 

R1.3.1.b

  • Restricted

R1.3.2

  • Restricted

R1.3.2

  • Blocked

R1.3.2

  • Blocked

PCI Data

R1.3.2

  • Blocked

R1.2.5

  • Comments in all rules
  • ANY not allowed in source or destination

R1.2.1.b

  • Restricted

 

R2.2.4

  • Restricted

R1.3.2

  • Blocked

R1.3.2

  • Blocked

PCI Web

R1.4.2

  • Restricted

R2.2.4

  • Restricted

R2.2.4

  • Restricted

R 1.3.1.b

  • Blocked

 

R1.3.2

  • Blocked

R1.3.2

  • Blocked

Wireless Networks

R1.4.2

  • Restricted

R1.1.3

  • Blocked

R1.3.2

  • Blocked

R1.3.2

  • Blocked

R1.3.2

  • Blocked

 

Ignored

Internet

R1.4.2

  • Restricted

R1.1.3

  • Blocked

R1.3.2

  • Blocked

R1.3.2

  • Blocked

R1.3.2

  • Blocked

Best Practice

  • Blocked

 

SecureTrack will identify any current violations of the policy. All access requests that are submitted from SecureChange will also be checked for violations. This process will ensure on-going PCI DSS compliance.

PCI DSS v4 Regulations

 

Requirement

Unified Security Policy Implementation

1.2.5

1.2.6

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

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.
  • Create a universal security policy matrix that identifies all PCI DSS zone-to-zone connections.
  • Identify which services are approved for each source-destination pair for insecure services, protocols, or ports. Examples of insecure services, protocols, or ports include, but are not limited to FTP, Telnet, POP3, IMAP, and SNMP v1 and v2.
  • Use rule properties to ensure that comments, logs, and usage are documented for each device rule for each source-destination pair.
  • Use rule properties to prevent the use of ANY as a source, destination, or service for each source-destination pair.

1.2.7

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

View Aurora dashboard and Rule Viewer regulatory to verify that all relevant devices are compliant.

1.3.1.a

Examine configuration standards for NSCs to verify that they define restricting inbound traffic to the CDE is in accordance with all elements specified in this requirement

View Aurora dashboard and Rule Viewer regulatory to verify that all relevant devices are compliant.

1.3.1.b

Examine configurations of NSCs to verify that inbound traffic to the CDE is restricted in accordance with all elements specified in this requirement.

Configure the matrix to limit the inbound and outbound PCI Data zone traffic to the necessary applications, servers and protocols in the PCI Applications zones using the access type restricted or blocked.

1.3.2.a

Examine configuration standards for NSCs to verify that they define restricting outbound traffic from the CDE in accordance with all elements specified in this

View Aurora dashboard and Rule Viewer regulatory to verify that all relevant devices are compliant.

1.3.2.b

Examine configurations of NSCs to verify that outbound traffic from the CDE is restricted in accordance with all elements specified in this requirement

Configure the matrix to limit the inbound and outbound PCI Data zone traffic to the necessary applications, servers and protocols in the PCI Applications zones using the access type restricted or blocked.

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.

All devices are automatically added to the matrix of a USP. Irrelevant devices can be removed.

1.4.4

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

Configure the matrix to limit the traffic from the internal network to the DMZ and other untrusted networks using the access type restricted.

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.

Configure the matrix to limit the inbound traffic to the DMZ networks to system components that provide authorized publicly accessible services, and explicitly required protocols and ports.

Configure the matrix to restrict all inbound traffic from the Internet to the DMZ network only.

2.2.4

Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled.

Configure the matrix to explicitly specify in the access type only those services, protocols, daemons, ports, and protocols that are required for the functioning of the system.

Configure the rule properties to identify unused rules.

2.2.5

If any insecure services, protocols, or daemons are present:

  • Business justification is documented.

  • Additional security features are documented and implemented that reduce the risk of using insecure services, protocols, or daemons.

TOS supports TLSv1.2 for encrypting communications between internal processes. You must ensure that other devices, daemons, and services use secure encryption for any communications.

10.2

Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.

TOS provides full accountability (who made policy changes and when the changes were made) for many devices.

10.5

Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis.

TOS maintains traffic logs for user configurable period of time, and can retrieve device and policy usage information for any range of time

10.7.1

The SecureTrack dashboard and the Rule Viewer lets you see violations in your environment whenever a policy change occurs. SecureChange implements workflow change automation that utilizes risk analysis to prevent unauthorized or risky device policy changes).

The SecureTrack dashboard and the Rule Viewer lets you see violations in your environment whenever a policy change occurs. SecureChange implements workflow change automation that utilizes risk analysis to prevent unauthorized or risky device policy changes. User can configure alerts for new violations following changes.