Lion Cipher Lab

Scope a cardholder data environment and validate the segmentation (PCI DSS 4.0.1, Part 2)

• GRC / Compliance
• Advanced
• ~110 min
• Free · no account required

Why it matters

Almost every failed PCI DSS assessment fails at scope, and it fails quietly, months before anybody notices. A merchant sits down with an assessor, produces a network diagram drawn in 2023, a spreadsheet of nine in-scope systems, and the sentence that starts every bad assessment: 'we don't store cards.' The sentence is usually true in the narrow sense and useless in every other sense, because PCI DSS scope was never limited to systems that store card data. It covers systems that store, process OR transmit account data; systems with unrestricted connectivity to those; and -- this is the one…

What you'll learn

• deriving a cardholder data environment from a data-flow inventory instead of accepting a scope spreadsheet -- the difference between 1 system that stores card data and 85 of 90 systems in scope
• the three scope categories in PCI DSS 4.0.1 and the propagation rules for each: CDE, connected-to, and security-impacting (Requirement 12.5.2)
• the most-missed category, quantified: Active Directory, DNS, NTP, EDR console, backup, hypervisor, CI/CD, secrets manager, MDM and the internal CA hold no card data and are in scope anyway
• validating segmentation as a TEST rather than a claim: 51 rules reviewed, 8 enforced but undocumented, 17 that defeat segmentation, plus a multi-hop pivot the paper diagram cannot show
• the penetration-test-based segmentation check under Requirement 11.4.5 (merchants, 12 months) and 11.4.6 (service providers, six months), and why the interval differs
• sensitive authentication data versus cardholder data, and the one requirement with no customized-approach option: SAD is not stored after authorization, even encrypted (3.3.1)
• tokenization, P2PE and hosted payment pages as scope reducers -- and exactly where each one stops reducing
• the customized approach and its targeted risk analysis (12.3.2), and how it differs from the risk analysis that sets a frequency (12.3.1)
• third-party service providers: the list (12.8.1), the written agreements (12.8.2), the monitoring (12.8.4), the responsibility matrix (12.8.5) and the provider side of it (12.9.2)
• the counter-intuitive move that separates people who have read about scoping from people who do it: correcting the record makes the scope go UP even as the security gets better

Steps in this lab

1. Read this first: what this lab is, and how it is different from Part 1
2. The vocabulary, defined once, in plain words
3. The three scope categories, and the one everybody forgets
4. SAD versus cardholder data -- the distinction that ends careers
5. Open a terminal and make a working folder (zero-assumption setup)
6. Meet Northgate Provisions Ltd -- the company you are about to assess
7. Create pciscope.py -- read it before you run it
8. Run it: the claim, the spreadsheet, and the number that replaces both
9. Segmentation as a TEST, not a claim
10. The category everybody misses: security-impacting systems
11. The nine failure shapes, one at a time
12. Fix ONE rule, re-run, and watch what does NOT move
13. Now fix the RECORD -- and watch the scope go UP
14. Scope reducers and their limits: tokenization, P2PE, hosted pages
15. The defined approach, the customized approach, and the two different risk analyses
16. The calendar: what is annual, what is every six months, and who counts as a service provider
17. Why this, not that -- three decisions worth arguing about
18. When NOT to chase scope reduction
19. How a pro does it differently
20. Clean up, and the sentences worth keeping

Open the full interactive lab →