Implementing PCI DSS v3 Using USP

You can implement PCI DSS v3.2 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:

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

Create the USP

To create a Unified Security Policy that implements PCI DSS v3:

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

  1. From the menu, go to Browser > USP Viewer.
  2. Click +ADD UNIFIED SECURITY POLICY.

  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.3.6

  • Restricted

R2.2.2

  • Restricted

R2.2.2

  • Restricted

R2.2.2

  • Restricted

R1.3.6

  • Restricted

R2.2.2

  • Restricted

Corporate

R1.1.6a

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

R1.3.6

  • Restricted

 

R2.2.2

  • Restricted

R1.2.1.b

  • Blocked

R2.2.2

  • Restricted

R2.2.2

  • Restricted

R2.2.2

  • Restricted

PCI Applications

R1.3.1

  • Restricted

R2.2.4

  • Last hit < 90

 

R1.2.1.b

  • Restricted

R2.2.2

  • Restricted

R1.3.4

  • Blocked

R1.3.4

  • Blocked

PCI Data

R1.3.4

  • Blocked

R1.1.6a

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

R1.2.1.b

  • Restricted

 

R2.2.2

  • Restricted

R1.3.4

  • Blocked

R1.3.4

  • Blocked

PCI Web

R1.3.1

  • Restricted

R2.2.2

  • Restricted

R2.2.2

  • Restricted

R 1.2.1.b

  • Blocked

 

R1.3.4

  • Blocked

R1.3.4

  • Blocked

Wireless Networks

R1.3.2

  • Restricted

R1.3.4

  • Blocked

R1.3.4

  • Blocked

R1.3.4

  • Blocked

R1.3.4

  • Blocked

 

Ignored

Internet

R1.3.2

  • Restricted

R1.3.4

  • Blocked

R1.3.4

  • Blocked

R1.3.4

  • Blocked

R1.3.4

  • Blocked

Best Practice

  • Blocked

 

PCI DSS Regulation 1.1.6a (comments in all rules, ANY not allowed in source or destination) applies to every cell in the matrix.

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 v3.2 Regulations

Requirement

Unified Security Policy Implementation

1.1.6.a

Verify that firewall and router configuration standards include a documented list of all services, protocols and ports, including business justification and approval for each.
  • Create a universal security policy matrix that identifies all PCI DSS zone to zone connections relationships.
  • 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.1.7

Requirement to review firewall and router rule sets at least every six months.

View the violations browser regularly to verify that all relevant devices are compliant.

1.2.1.a

Examine firewall and router configurations standards to verify that they identify inbound and outbound traffic necessary for the cardholder data environment.

View the violations browser regularly to verify that all relevant devices are compliant.

1.2.1.b

Examine router and firewall configuration standards to verify that they identify inbound and outbound traffic necessary for the cardholder environment.

Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic.

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.2.1.c

Examine firewall and router configurations to verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit “deny all” or an implicit deny after allow statement.

The "deny all" cleanup rule is implicit when the access type for a source-destination pair is restricted.

All devices are automatically added to the matrix of a USP, and can be removed if they are not relevant.

1.2.3

Install perimeter firewalls between all wireless networks and the cardholder data environment, and configure these firewalls to deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment

All devices are automatically added to the matrix of a USP, and can be removed if they are not relevant.

1.3.1

Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.

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.

1.3.2

Limit inbound Internet traffic to IP addresses within the DMZ.

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

1.3.4

Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.

Configure the matrix to block all traffic from the internet from accessing the data environment using the access type blocked.

Configure the matrix to block all outbound traffic from the PCI Data zone to the internet using the access type restricted or blocked.

1.3.6

Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks. System components that store cardholder data must not be located in a DMZ or be accessible from the Internet or other 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.

2.2.2

Enable only necessary services, protocols, daemons, etc., as required for the function of the system.

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.

2.2.3

Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.

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

2.2.4

Configure system security parameters to prevent misuse.

Configure the rule properties to identify unused rules.

10.1

Implement audit trails to link all access to system components to each individual user.

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

10.7

Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (e.g., online, archived, or restorable from backup).

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

10.8

Additional requirement for service providers only: Implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of Firewalls, IDS/IPS, FIM, Anti-virus, Physical access controls, Logical access controls, Audit logging mechanisms, Segmentation controls (if used).

The SecureTrack dashboard and violations browser 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.