Lab: PCI compliance with firewall, IPS and TLS proxy

Use inspect, not pass, for the allowed flow. Inspect is stateful: the reply is allowed automatically because the router remembers the session. Pass is one-way, and the reply needs a second rule in the other direction (fault 1 below). Where the Manager's guided security workflow offers a scenario for compliance or segmentation, it can build the zones and pairs for you. Scenario names vary by release.

1. Attach the IPS policy to the firewall rule or zone pair that covers the payment flow, with a signature set suited to the traffic (check what your release offers).
2. Set the mode to detection. Confirm the IPS engine is running on BR-01 and that signature updates work.
3. Run a normal trading period. Collect the alerts and sort them: real findings, false positives, noise.
4. Tune: remove or suppress only signatures you can justify, and write the reason down.
5. Switch to prevention in a change window with a rollback ready. A false positive in prevention mode stops a payment, so the first day needs watching.

IPS on encrypted traffic sees the outside of the session only (addresses, ports, handshake). Without decryption it can match few payload signatures. That is a real limit, and it is the reason task 3 exists.

Payment gateway: bypass, do not decrypt. The reasons:

• Card data is meant to stay protected by TLS from the terminal to the gateway. Decrypting at BR-01 puts the clear text inside the router for a moment, which brings that router and its keys into the review.
• Payment terminals and gateways often pin certificates or use mutual TLS. A proxy presenting its own certificate breaks the connection (fault 2 below).
• The flow is narrow and known. Segmentation, a one-rule allow, and monitoring give most of the control with less risk.

Terminals' general web traffic, if there is any: decrypt. Terminals should need little beyond the gateway, so the better answer is often to block general web access from VPN 40 altogether. If a terminal does need the internet (for updates, for example), allow only named destinations. Where a managed terminal must browse, decryption with the proxy is acceptable, with banking, health and other sensitive categories in the bypass list, and the CA certificate installed on the terminal.

This is a design opinion, not a Cisco requirement. Some organisations do decrypt payment traffic at a controlled inspection point, and their assessor accepts it. The point is to decide deliberately and write the reason down.

• What to log: firewall drops and allows for the CDE zone pairs, IPS alerts and drops, policy changes with the user who made them, and login events on BR-01 and the Manager.
• Where: send logs to a collector off the router. Local buffers are small and are lost on a reload. Protect the collector from changes by the people whose actions it records.
• Time: use NTP on every device, so entries from the router, the Manager and the collector line up.
• Retention: set by the standard you are assessed against and by company policy. Ask the assessor for the period, and do not copy a number from this page.
• Review: someone must read the alerts. A log nobody looks at proves little.

The zone-pair rule uses pass, not inspect. Pass is one-way: the outbound packets are allowed, and the replies come back from the data-centre zone to CDE, where no rule exists, so they are dropped. Diagnose by looking at the pair's counters in both directions and at the drop statistics, which show a drop for the reverse direction. Fix: change the action to inspect, which tracks the session and allows the reply. Do not fix it by adding a broad reverse rule, since that would allow new connections from the data centre into the CDE.

The payment application checks the gateway's certificate (pinning, or a client certificate for mutual TLS). The proxy answers with a certificate signed by the organisation's CA, which the application does not accept. Diagnose by checking the TLS proxy statistics or logs for that destination and by testing with the proxy bypassed for 10.20.40.0/24. Fix: add the payment gateway to the bypass list (by address or by server name) and leave it undecrypted, as decided in task 3.

There are two usual causes. First, a route leak: a policy or a configured route-leak between VPN 10 and VPN 40 delivers the traffic, and if the two VPNs ended up in the same zone, the firewall allows it as traffic within a zone. Second, an allow rule that is too broad, for example a corporate to CDE pair with "any" as the match, added for a support task and not removed. Diagnose by checking the zone membership (is VPN 40 in a zone alone?), the list of zone pairs, and the OMP and service-side routes for 10.40.1.0/24 in VPN 10. Fix: remove the leak and the broad rule, keep VPN 40 alone in its zone, and if support really needs access, create a narrow rule (one source host, one port) with an approval and an end date.