Payment processor treats 'cloud misconfiguration' as a single risk
FinPay, a payment processor handling 18 million card transactions a day, is 60% through a migration from two owned data centres to a public cloud. The estate includes 42 microservices, an externally hosted key-management service, and a multi-region object store holding tokenised card data. A penetration test found an IAM role attached to a CI/CD runner with s3:GetObject on a bucket containing 2.4 million tokenised records and export logs; the role was not in the intended-state configuration. The cloud team says the bucket is 'encrypted and private', and the risk register lists 'cloud misconfiguration' as a single risk scored likelihood 3, impact 3. The CISO has two weeks before the next risk committee and wants a defensible analysis, not a tool dump. The PCI DSS assessor is due in 60 days. Logging coverage is 70%; the SIEM has no alert for role-policy changes.
1. Critique the current identification of 'cloud misconfiguration' as one risk and propose a more rigorous identification approach for FinPay. What specific risk scenarios would you add?
Read the worked answer
Critique. 'Cloud misconfiguration' is a cause or control-failure category, not a risk scenario. Aggregating it into one likelihood-3, impact-3 entry hides which asset is affected, which threat actor could exploit it, what consequence follows, and who owns the response. It also conceals the difference between an exposed bucket, an over-privileged CI/CD role, and a missing detection rule.
Approach. Use a hybrid of asset-based, threat-based, and scenario-based identification. Inventory the token store, IAM roles, CI/CD pipeline, key-management service, logging pipeline, and cross-region replication. Identify threats (external attacker, malicious insider, compromised build credential, supply-chain compromise) and vulnerabilities (role drift, excessive permissions, missing alerting, incomplete logging). Use bow-tie analysis for the highest-consequence paths. Write each risk as cause, event, consequence, and affected asset, and record existing controls separately from control gaps. Involve cloud platform, application owners, payments, compliance, and the SOC.
Scenarios to add. A compromised CI/CD credential uses an over-privileged role to read the token bucket; a stale cross-account role permits unauthorised access; a KMS key policy change allows decryption by an unintended principal; a logging gap delays detection of bulk export; replication writes data to an unapproved jurisdiction; vendor remote access bypasses approval. Each needs its own owner, rating, and treatment decision.
2. Design likelihood and impact scales suitable for this analysis and apply them to the IAM role finding. Justify qualitative versus semi-quantitative analysis.
Read the worked answer
Impact scale. Use anchored levels 1 to 5 across financial loss, cardholder data exposure, regulatory and PCI DSS consequences, service outage, and reputation. For example, level 4 could mean exposure of a large tokenised dataset with contractual notification obligations; level 5 could mean decryption keys or live card data are compromised. Tokenisation reduces direct card-data impact but does not make a 2.4 million-record exposure negligible. Likelihood scale. Anchor levels by frequency or exploitability: 1 highly unlikely, 3 plausible within the year, 5 observed or trivial to exploit. Consider threat activity, exposure, required privileges, and detection capability.
Apply. The IAM role exists, external scanning is routine, and the role has direct read permission, so likelihood is at least 4 unless evidence shows the role cannot be assumed. Impact is 4 or 5 depending on whether tokens can be linked to cardholders or keys are reachable. The risk band is high or extreme even with medium confidence.
Method choice. Use semi-quantitative scoring because the organisation has some event data and penetration-test evidence, but not enough for reliable annualised loss estimates. Keep the ordinal labels and the matrix; do not multiply ordinal numbers as if they were cardinal. State confidence as low because logging coverage is 70% and role-policy changes are not alerted. Calibrate with incident data, red-team results, and PCI DSS scope. After remediation, reassess residual likelihood and preserve the rationale.
3. What should be recorded and communicated to the risk committee and the PCI DSS assessor about this finding?
Read the worked answer
Record. Create a risk register entry with the scenario, affected assets, threat and vulnerability, existing controls, evidence from the penetration test, likelihood and impact ratings, confidence, risk owner, treatment options, cost, target residual risk, review date, and status. Link it to the CI/CD change record, IAM policy evidence, logging gap, and any incident ticket. Record who decided what and why, including any interim restriction on the role.
Communicate to the risk committee. Provide a concise decision paper: the scenario in business language, the rating and confidence, the potential cardholder and regulatory impact, treatment options, cost, and the decision requested. Avoid dumping tool output. State whether the exposure is active and what containment has already occurred.
Communicate to the PCI DSS assessor. Provide the scope, methodology, evidence of analysis, control gaps, and remediation dates. The assessor needs to see that the risk was identified and managed, not necessarily the entire corporate register. Apply need-to-know: share sensitive architecture details only with authorised assessors. If data was actually accessed, trigger the incident-response and notification assessment rather than treating this as a purely documentary risk exercise.