Lion Cipher Lab

Design a PCI DSS customized approach and defend it with a quantitative targeted risk analysis (Part 3)

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

Why it matters

The customized approach is the most misunderstood thing in PCI DSS v4.x, and the misunderstanding runs in exactly one direction: people hear 'meet the objective your own way' and translate it into 'we can skip this'. It is close to the opposite. The customized approach is strictly MORE work than the defined approach -- in this lab, measured on one requirement, it costs 14 artifacts against 2, seven review cycles a year against one, and 14 derived testing procedures against 5 stated ones, forever rather than once. It is also unavailable to most entities, because a self-assessment questionnaire…

What you'll learn

• telling the three approaches apart under pressure: the DEFINED approach (including the OR branches several requirements already contain), a COMPENSATING control (an option inside the defined approach, for a legitimate documented technical or business CONSTRAINT) and the CUSTOMIZED approach (for an entity that CHOOSES to meet the stated objective a different way, with no constraint required) -- plus the four exits people forget: not applicable, the legal exception, an already-satisfied OR branch, and a plain gap
• running a written decision procedure instead of a debate: 12 realistic proposals routed to 10 distinct verdicts, with 9 of 12 asking for the customized approach and 1 qualifying outright
• the difference between the 12.3.1 FREQUENCY targeted risk analysis (how often must we do this) and the 12.3.2 CUSTOMIZED APPROACH targeted risk analysis (is a control of our own design good enough), which are separate documents answering different questions
• building a targeted risk analysis as CODE rather than prose: an explicit failure model, an evidence GRADE on every parameter (measured / inferred / asserted), a seeded Monte Carlo producing an annualised loss distribution, and a head-to-head against the defined approach under COMMON RANDOM NUMBERS
• testing 'at least equivalent protection' at the mean AND in the tail, and watching a control that is 25.4% better on average come out 25.4% worse at the 99th percentile -- the exact failure a single expected-loss figure cannot see
• using a sensitivity analysis as a SHOPPING LIST rather than a report: ranking parameters by how far they move the answer, measuring the top asserted drivers, and watching the asserted share of the conclusion fall from 36.2% to 9.3% while the answer becomes MORE fragile, not less
• deriving assessor testing procedures from an objective and then stress-testing them for falsifiability across six dimensions plus a hard gate -- and discovering that 14 of your own 14 first drafts could only ever pass
• writing to the OBJECTIVE instead of the defined approach's IMPLEMENTATION, with a mechanical scorer and the one-line test that catches it: would your sentence still be true if the threat vanished?
• the roles and the independence rule: what the entity designs, documents, tests, monitors and maintains; what the assessor derives, executes and records; and why an assessor employee who helped build a control cannot then grade it
• counting the real cost of the customized approach rather than guessing at it -- 14 artifacts against 2, 7 review cycles a year against 1, and 14 derived testing procedures against 5 stated ones -- and knowing precisely what the published SAQ text says about customized-approach eligibility and which questions belong to your acquirer instead

Steps in this lab

1. [1] Read this first -- what this lab is, what it is NOT, and where it sits
2. [2] The three approaches, disambiguated hard and early
3. [2a] ...and the four exits people forget exist
4. [3] The vocabulary, defined once, in plain words
5. [4] The discipline that comes before everything: never quote a requirement number from memory
6. [5] Open a terminal and make a folder (assume nothing)
7. [6] Create caroute.py -- the registry and the decision procedure
8. [7] Run it -- twelve scenarios, ten verdicts
9. [8] The two habitual mis-routes, in detail
10. [9] The other exits, and the ones with teeth
11. [10] Requirement 12.3.1 versus 12.3.2 -- two different targeted risk analyses, and the difference is examinable
12. [11] Artifact 1 -- the control description. Meet Corvid Payments Group
13. [12] Artifact 2 -- the objective statement, and the defect that eats half of all attempts
14. [13] Create derive.py -- the two scorers, the cost counter and the scope calculator
15. [14] Score the objective statements -- 4 of 6 fail
16. [15] Artifact 3 -- what a QUANTITATIVE targeted risk analysis actually contains
17. [16] Create tra.py -- the model, and two techniques worth stealing
18. [17] Create harness.py and run the whole thing
19. [18] Read section [4] of the output -- the analysis as PROPOSED
20. [19] What happened when three asserted numbers got measured
21. [20] Why the mean lied, and why you test the tail
22. [21] A3 -- the fix, and the structural move almost nobody uses
23. [22] Worked example B -- the trap, and an analysis that says STOP
24. [23] Sensitivity -- the shopping list, and the share of your answer nobody measured
25. [24] Artifact 4 -- derive the testing procedures, then try to falsify them
26. [25] 14 of 14. Read that number again.
27. [26] The assessor's side -- who does what, and where independence bites
28. [27] The documentation set -- what has to exist and what gets signed
29. [28] What it actually costs -- counted, not guessed
30. [29] The SAQ question, answered precisely
31. [30] FAILURE MODE 6 -- the control quietly enlarges the environment it protects
32. [31] FAILURE MODE 4 -- the permanent exemption, measured over five years
33. [32] The six named failure modes on one page, each with its number
34. [33] The judgment -- when it is worth it, when it is not, and what a small merchant should do instead
35. [34] Clean up, and where to go next

Open the full interactive lab →