Operational Scenarios with a SaaS HR Platform
A 6,000-employee services firm runs payroll and benefits on a SaaS HR platform. Access is through corporate SSO; the platform calls a benefits provider API and stores bank details. The vendor will not provide raw logs, there is no EDR coverage inside the SaaS, and the only reliable telemetry is IdP authentication logs and HR ticket exports. A strategic scenario has been retained: an external attacker obtains payroll data to commit fraud and embarrass the firm. The team must build operational scenarios in four weeks. The vendor's security questionnaire says 'MFA enforced' and 'encryption at rest'; the firm has no evidence of how admin accounts are protected. The payroll team regularly exports CSV files to reconcile payments. The sponsor wants 'one operational scenario per strategic scenario' to keep the report short, but the technical lead says that would hide the difference between an SSO compromise and a CSV exfiltration.
1. How many operational scenarios should be built from the strategic scenario, and what determines the split? Explain using supporting assets and threat modes.
Read the worked answer
The number should be driven by distinct supporting assets and threat modes, not by a one-to-one rule. At least two scenarios are needed here: one through the CSV export path and one through SSO or identity compromise. They differ in assets, evidence and measures: the CSV path involves a payroll workstation, export function and exfiltration channel; the SSO path involves the IdP, tokens and SaaS admin console. A third may be justified if vendor-side administration is materially different from the firm's own IdP. Stop splitting when the same assets, actions and measures repeat. The sponsor's 'one per strategic scenario' rule would create a false sense of completeness and would likely hide the export risk, which is the path with the weakest current evidence. The report can stay short by grouping measures, not by collapsing distinct paths.
2. Build one operational scenario for the CSV-exfiltration path and one for SSO compromise, listing supporting assets, elementary actions and assumptions.
Read the worked answer
CSV path. Supporting assets: payroll workstation, SaaS export function, file share or email, benefits API data. Elementary actions: phish a payroll user; obtain credentials; authenticate to the SaaS; export a CSV containing bank details; exfiltrate via personal email or removable media. Assumptions: no DLP on exports; CSV includes full bank details; MFA may not cover the export action.
SSO compromise path. Supporting assets: IdP, SaaS tenant, admin console, HR data store. Elementary actions: steal a session token or perform MFA fatigue; authenticate through SSO; escalate to an admin role; create a persistence account; export or redirect data. Assumptions: IdP logs are available; vendor-side logs are not; admin MFA protection is unverified. Each scenario should state which step is uncertain, because that uncertainty drives monitoring and contractual measures.
3. What should the team do about the missing vendor logs and unverified MFA claims? How should uncertainty be recorded without making the scenario unusable?
Read the worked answer
Treat the missing logs and unverified MFA as evidence gaps, not as proof of safety. Record them as explicit assumptions with a confidence level, an owner and a validation action. Use compensating evidence: IdP logs, HR ticket exports, the vendor questionnaire, and a contractual request for admin authentication evidence. Design measures that remain useful under uncertainty, such as phishing-resistant MFA, least privilege on export functions, and alerting on bulk CSV generation. In the scenario, mark the vendor-side steps as 'unknown' rather than deleting them; that keeps the risk visible and supports a decision to negotiate audit or logging rights. The scenario is still usable because the firm can act on its own side of the boundary while escalating the provider-side gap to risk acceptance or contract renewal.