PCI-DSS for Network Engineers: Segmentation, Scoping, and What Auditors Actually Check

Why Network Engineers Need to Understand PCI-DSS

PCI-DSS (Payment Card Industry Data Security Standard) is a contractual compliance framework that any organization handling cardholder data must follow. As a network engineer, you are responsible for the controls that define the Cardholder Data Environment (CDE) boundary. If your firewall rules, VLAN design, or access controls are wrong, the organization fails the audit — and you will be the person explaining why to the QSA.

I've been the engineer managing PCI-compliant network segments for financial clients across multiple countries. This is what you actually need to know — not the 12-requirement marketing summary, but the network-layer specifics that auditors verify.

---

---

Requirement 1: Network Segmentation

PCI-DSS Requirement 1 covers firewall and router configuration. The core obligation is: the CDE must be isolated from untrusted networks, including your own corporate LAN.

What "segmentation" actually means

Segmentation is not just VLANs. A VLAN on a shared switch with an ACL is not considered strong segmentation by most QSAs — especially if ACL misconfigurations could allow CDE access. Strong segmentation means:

• A stateful firewall (or equivalent) at the CDE boundary
• Default deny — only explicitly permitted traffic is allowed through
• No routing path from corporate LAN to CDE unless through the firewall

What auditors check in Requirement 1

Cisco ASA — CDE Boundary Firewall Config Pattern

# Interface definition — CDE on high security level, DMZ on medium
ASA(config)# interface GigabitEthernet0/0
ASA(config-if)#  nameif outside
ASA(config-if)#  security-level 0
ASA(config-if)#  ip address 203.0.113.1 255.255.255.248
ASA(config)# interface GigabitEthernet0/1
ASA(config-if)#  nameif dmz
ASA(config-if)#  security-level 50
ASA(config-if)#  ip address 10.1.1.1 255.255.255.0
ASA(config)# interface GigabitEthernet0/2
ASA(config-if)#  nameif cde
ASA(config-if)#  security-level 100
ASA(config-if)#  ip address 10.2.1.1 255.255.255.0

# Access lists — explicit deny at end (logged)
ASA(config)# access-list DMZ_TO_CDE extended permit tcp 10.1.1.0 255.255.255.0 10.2.1.0 255.255.255.0 eq 443
ASA(config)# access-list DMZ_TO_CDE extended permit tcp 10.1.1.0 255.255.255.0 10.2.1.0 255.255.255.0 eq 8443
ASA(config)# access-list DMZ_TO_CDE extended deny ip any any log
# Explicit deny with log — every blocked connection creates a syslog entry
# This is required evidence for Req 10 (logging)

ASA(config)# access-group DMZ_TO_CDE in interface dmz

---

Requirement 7 & 8: Access Controls

PCI requires least-privilege access. For network engineers, this means:

• No shared accounts. Every engineer must have a named account on every network device they access. No group "admin" account shared across a team.
• MFA on all CDE access. SSH to a CDE device without MFA is a finding. We use Cisco ISE with TACACS+ and RSA SecurID (or Duo) for all device logins.
• Privileged access via jump server. Direct SSH from a laptop to a CDE device is not acceptable. All access routes through a logged jump server.

# Cisco ASA — TACACS+ AAA for PCI compliance
ASA(config)# aaa-server TACACS-PCI protocol tacacs+
ASA(config-aaa-server-group)#  aaa-server TACACS-PCI (inside) host 10.2.1.50
ASA(config-aaa-server-group)#  key pci-tacacs-key-strong
ASA(config)# aaa authentication ssh console TACACS-PCI LOCAL
ASA(config)# aaa authentication enable console TACACS-PCI LOCAL
ASA(config)# aaa authorization command TACACS-PCI LOCAL
ASA(config)# aaa accounting command TACACS-PCI
# aaa accounting command = every CLI command typed is logged to TACACS+ server
# This is the evidence trail auditors want for Req 10

---

Requirement 10: Logging

Every access to the CDE must be logged. Every firewall permit and deny at the CDE boundary must be logged. Logs must be retained for 12 months (3 months immediately accessible).

What to log:

• All user logins to CDE network devices (TACACS+ accounts for auth success/failure)
• All firewall rule hits at the CDE boundary (explicitly configured on each ACL entry)
• All routing changes on CDE-connected devices
• All configuration changes (aaa accounting command)
• Interface state changes on CDE-connected links

Common gap: Engineers configure logging on new rules but forget to audit existing rules. Run a log-hit audit quarterly to confirm every rule at the CDE boundary has the log keyword.

# Audit — find ACL entries missing the "log" keyword on Cisco IOS
Router# show ip access-lists CDE-INBOUND
# Manually review: every "permit" and "deny" line must end in "log"
# Any line without "log" = audit finding

# Add log to existing rules (IOS-specific — must delete and re-add the line)
Router(config)# ip access-list extended CDE-INBOUND
Router(config-ext-nacl)#  no permit tcp 10.1.0.0 0.0.0.255 10.2.0.0 0.0.0.255 eq 443
Router(config-ext-nacl)#  permit tcp 10.1.0.0 0.0.0.255 10.2.0.0 0.0.0.255 eq 443 log

---

Requirement 11: Penetration Testing and Segmentation Testing

Every 12 months (and after significant infrastructure changes), segmentation controls must be tested. This is not optional — it is a requirement.

What segmentation testing means in practice:

1. From every out-of-scope network segment, attempt to reach CDE IP addresses
2. Attempt to reach CDE management ports (SSH/22, HTTPS/443, SNMP/161) from corporate LAN
3. Verify that all attempts are blocked and logged
4. Document the test methodology, tester identity, date, and results

As the network engineer, you provide: the IP schema of the CDE, the list of CDE devices, and the firewall rules. The QSA or penetration tester independently verifies that the boundary is actually enforced.

---

The Most Common PCI Network Findings