Check out the new V6 release
7 minute read
IP Fabric and PCI Compliance - Part 4: Path Tracing
Updated: October 19, 2022

IP Fabric and PCI Compliance - Part 4: Path Tracing

This article was co-authored by Dan Kelcher, Solutions Architect at IP Fabric

In part 3 of this series on PCI compliance, we covered how you can satisfy parts of requirements 1 and 12 of the PCI DSS by leveraging IP Fabric to obtain a complete network inventory and to visualize your network with up-to-date topological overviews and network diagrams. So now that you have this inventory (including end-of-life data and vendor-suggested replacements), and a network diagram that can be updated ad-hoc without reliance on manual documentation, you can begin to investigate the dataflow within your network and further protect yourself from any potential issues during your next PCI compliance audit.

Let's dig in and see how IP Fabric's path tracing capabilities can allow you to satisfy some additional requirements set out by the PCI DSS. In this series entry, we will partially cover further sub-requirements within requirement 1, as well as part of requirement 11, as set out by the PCI DSS.

What are the relevant requirements?

Here are the specific requirements within 1 and 11 that can be satisfied using the path tracing function:

As mentioned in part 3 of this series, requirement 1.2.4 touches upon path tracing. The requirement itself states that enterprises possess an accurate dataflow diagram, maintained to meet the following: a) It shows all account data flows across systems and networks, and b) it is updated as needed upon changes to the environment.

1.3.1 specifies that inbound traffic to the card data environment (CDE) be restricted to only necessary traffic, with all other traffic being specifically denied. All unauthorized traffic cannot be able to enter the CDE. This is intended to prevent "malicious individuals" from accessing the network via unauthorized IP addresses.

1.3.2 stipulates that outbound traffic from the CDE be restricted to only necessary traffic, with all other traffic being specifically denied.

1.4.1 mandates that Network Security Controls (NSCs) be implemented between trusted and untrusted networks, so that unauthorized traffic cannot traverse network boundaries between those trusted and untrusted networks. This requires an examination of configuration standards and network diagrams to verify that NSCs are defined (1.4.1.a), and that these are in accordance with documented configuration standards and network diagrams (1.4.1.b).

1.4.2 requires inbound traffic from untrusted networks to trusted networks be restricted to: a) communications with system components that are authorized to provide publicly accessible services, protocols and ports, and b) stateful responses to communications initiated by system components in a trusted network, with all other traffic being denied. Essentially, only authorized traffic or responses to a system component (in the trusted network) can enter from an untrusted network.

1.4.4 requires system components that store cardholder data (CHD) to not be directly accessible from untrusted networks. This requires an examination of the dataflow and network diagram to verify that system components storing CHD are not directly accessible from said untrusted networks (1.4.4.a). Also required is an examination of NSC configurations to verify that controls are properly implemented to ensure that CHD-storing components are not directly accessible from untrusted networks (1.4.4.b).

11.4.5 states that if segmentation is used to isolate the CDE from other networks (see part 2 for more detail on network segmentation and PCI compliance), penetration tests are performed on segmentation controls. This must be performed AT LEAST once every 12 months and after changes to segmentation controls and methods. The CDE must be confirmed as sufficiently isolated from all out-of-scope systems.

How does IP Fabric help with these requirements?

1.2.4 – By providing a source and destination within your network, IP Fabric can show the path that data takes through the network. These can be generated on-demand or configured to run automatically. The ability to generate these on-demand helps to satisfy requirement 1.2.4, as administrators can run these regularly to ensure they are kept current and accurate. This also provides an easy view of all devices that would be in-scope for a PCI compliance audit, meaning any devices within that data flow would need to be PCI compliant.

How does it work? When a snapshot of the network is taken, IP Fabric captures the state of each device, including CDP/LLDP, MAC table, and routing table information. That data is used to determine the relationship between devices. A graphical topology can be built from that relationship information.


In the above diagram, the traffic flow starts at the top left, from host in site L33. The router L33R4 has equal-cost load balancing, splitting traffic across two paths. The traffic flows through an MPLS network to the L81 site. The presence of the transit cloud in the lower left indicates the flow traverses through a device (or multiple devices) that IP Fabric does not know (often this would be a service provider’s network). The traffic finally reaches the destination on L81R5.

1.3.1 and 1.3.2 - Using the same path tracing tool allows you to determine whether traffic can enter or exit the CDE. A trace can be performed using specific source and destination IP addresses or using CIDR blocks and can include a defined protocol and port. This also allows for validation of the NSCs in place to ensure that only necessary traffic is flowing through these points. When a path trace is created, an intent rule is generated based on the intended status of that flow, be it pass or fail. Any deviation from what is expected or planned can be remedied by reinforcing the relevant NSCs to prevent any unnecessary traffic from entering, or exiting, where it should not be.

The above table shows the status of the path verification rules. The 5-tuple for each test is listed, along with the expected state (all allowed, or none allowed), the state of the test (all, part, or none of the traffic allowed), and the result which shows why traffic was blocked. The state is also color-coded, with green meaning the state matched expectations, and red signifying a deviation.

1.4.1 – Of particular interest within this requirement are 1.4.1.a and 1.4.1.b - These sub-requirements stipulate that configuration standards and network diagrams are verified (1.4.1.a), and in accordance with the documented standards for configuration standards and diagrams (1.4.1.b). With path tracing, you can determine where these NSCs are located, how they are configured, and whether this is sufficient to segregate trusted and untrusted networks. IP Fabric can also provide you with security assurance - You can standardize the management of your configurations and ensure that these align with your documented configuration standards required under 1.4.1.b. Standardizing the configuration management of NSCs reduces manual effort - Saving you additional time, effort, and brainpower in ensuring your NSCs are configured in accordance with your documented configuration standards before your next PCI compliance audit.

IP Fabric allows you to drill down to a packet-level to find decision information. In this example, the traffic was denied because it matched an inbound deny rule named [email protected] 124 on the firewall interface ge0/0/4.200.

1.4.2 – Similarly to the requirements in 1.4.1, path tracing of the network and dataflow diagrams can be used to determine the flow of traffic between trusted and untrusted networks. As this requirement also stipulates that NSC configurations (and vendor documentation) be verified to determine if inbound traffic from untrusted to trusted networks is sufficiently restricted, IP Fabric’s security assurance can once again be used to standardize configuration management and ensure that these are sufficiently hardened against unwanted accesses.

1.4.4 – This requirement is also quite similar with regards to how IP Fabric can help. Using the network diagram that you have already built, you can verify if system components that store CHD are directly accessible from untrusted networks. Under 1.4.4.a, this means you have to verify your network and dataflow diagrams to ensure there is documentation that system components storing CHD is not directly accessible. Under 1.4.4.b, NSC configurations must be verified to ensure controls are in place to ensure CHD components are not accessible from untrusted networks. Again, with path tracing, and the ability to standardize configurations, you can ensure that these components are sufficiently protected and hardened against access from untrusted networks.

11.4.5 - As discussed in part 2, using your dataflow and network diagrams established by IP Fabric, you can verify whether you have sufficient segmentation in place. By locating the appropriate environments, you can verify whether segmentation is effective, prior to the investigation by an independent auditor.

Get IP Fabric

Request a demo and discover how to increase 
your networks visibility & get better time efficiency.
Free Demo | Zero Obligation
Request a Demo

In Action

Here's how simple IP Fabric makes this process:

Creating a path check

  1. Log into IP Fabric and navigate to Diagrams > End-to-end path
  2. Enter the source and destination IP/CIDR (expand "More Details" to specify protocol and port)
  3. Click submit
  4. The path lookup will display on the right, and a set of options to define a path check will now appear at the bottom of the input column.
  5. Select the option for Pass or Fail and click Save

Evaluating the status of path checks

  1. Log into IP Fabric and navigate to Technology > Routing > Path Verifications
  2. Locate the intent rule to be verified (this list can be filtered and/or sorted, and clicking the result boxes in the Intent Verification Rules section will automatically apply the corresponding filter)
  3. Click the Eye icon in the Actions column to open that path check
  4. The devices are color-coded to indicate ACL status - Green meaning the traffic was allowed, and red meaning it was denied.
  5. Right-clicking on the red firewall gives the ability to view the flow details for that device.
  6. In this case, there is equal-cost load balancing happening, which created two inbound flows. Both inbound flows are allowed. The traffic is then hair pinned through the L66JFW10 firewall and returned to the L66JFW9 firewall. The traffic coming in is now blocked.
  7. Clicking on the blocked flow shows the detailed decision table used to determine why the traffic is blocked.
  8. There is a rule named [email protected] that is denying traffic
  9. Clicking on the rule shows the details of that rule

This process can also leverage the API and webhook capabilities of IP Fabric. New path checks can be added programmatically and included in automation workflows. Webhooks can be configured to push information on failed intent checks into other platforms.


IP Fabric uses network configuration and state data to build out a representation of the network topology and can then determine how traffic would flow through the network, giving you all of the information that you need before your next PCI compliance audit. Adding intent rules to these path checks quickly and easily allows teams to identify problem areas. This visibility extends from a global topology view, down through a device level and into the detailed decisions made by network devices. That level of visibility simplifies both the environments' compliance state, as well as the process of gathering evidence to support either confirmation of compliance or the need for changes to achieve PCI compliance.

Follow us on LinkedIn and our blog, where we publish new content on a regular basis. For more information on how IP Fabric can help you to get to know your entire network inside and out, please request a demo here.

This article was co-authored by Dan Kelcher, Solutions Architect at IP Fabric


Try out the platform

Test out IP Fabric’s automated network assurance platform yourself and be inspired by the endless possibilities.

What would this change for your network teams?
Start live demo
We're Hiring!
Join the Team and be part of the Future of Network Automation
Available Positions
IP Fabric, Inc.
115 BROADWAY, 5th Floor
NEW YORK NY, 10006
United States
This is a block of text. Double-click this text to edit it.
Phone : +1 (914) 752-2991
Email : [email protected]
IP Fabric s.r.o.
Kateřinská 466/40
Praha 2 - Nové Město, 120 00
Czech Republic
This is a block of text. Double-click this text to edit it.
Phone : +420 720 022 997
Email : [email protected]
IP Fabric UK Limited
Gateley Legal, 1 Paternoster Square, London,
England EC4M 7DX
This is a block of text. Double-click this text to edit it.
Phone : +420 720 022 997
Email : [email protected]
IP Fabric, Inc. © 2023 All Rights Reserved