Part 1 · assessment and mitigation recommendations · published v1.0 · 14 October 2026
A cloud permission error becomes a data breach
SC05 · Financial services · SaaS · ecommerce
What really happened
The US Department of Justice’s Capital One case records an intrusion discovered in July 2019 and theft involving data from more than 100 million credit applications.
US Department of Justice · Capital One case
Evidence limit: The example establishes the possible scale of cloud data loss. The following configuration/identity routes are hypotheses to test in a client environment, not a claim that every route occurred in this incident.
The question for the client
Could an exposed application, leaked build secret or excessive cloud role reach data it should not?
Business impact: Large-scale disclosure, unauthorised deployment, tenant isolation failure and recovery burden.
- Systems involved
- Cloud identities, application endpoints, storage, CI/CD repositories, containers, secrets and audit trails.
- Where people fit
- Cloud engineers, developers and supplier administrators determine who can access which resource; review and ownership failures can create exposure without a staff-contact attack.
How a similar risk could develop here
Proposed client threat model, not a reconstruction of undocumented incident details.
Find a public or application-mediated entry → gain an overprivileged identity or exposed resource → access sensitive storage → copy data or change a deployment.
Each route depends on several controls. If one stage is blocked, later checks can only continue as a separately authorised, clearly labelled assumed-compromise test. Do not claim an end-to-end attack succeeded merely because a downstream test identity was supplied.
Referenced attack-vector guides
Approval is specific, never inherited from the guide. Check the client, campaign, individual person/asset, method, channel, time window and risk ceiling. Deny overrides allow; absent, expired or withdrawn permission blocks the action. LOW/MED/HIGH describe proposed test impact, not permission or finding severity.
Read the approval rules.
Assessment playbook · Part 1
Start with G01 scope and Target Management, G02 intelligence gathering where needed, and G03 tool/resource preflight. Each selected vector receives its own scoped invocation record.
SC05-S01LOW · proposed test impact1. Scope accounts and roles
Agree exact tenants, repositories, read-only permissions and synthetic data.
- Why this is needed
- It tests a barrier in the route above and helps answer: Could an exposed application, leaked build secret or excessive cloud role reach data it should not?
- Vector / method
- Tools and guides
- Target Management / CRM · native service; handoff is not automatic execution
- Client cloud identity inventory · client/operator supplied
- Repository input
- role-matrix.csv · RES-013 · published assessment resource; pin its version/hash in the case record.
- Output
- Cloud and role map; attach evidence, target ID, vector version and approval revision.
- Measure
- Selected resources with known owner/access rules / selected resources. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.
- Current result
- NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.
- Recommendation on failure
- Resolve unclear tenant ownership and remove unnecessary standing access. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.
SC05-S02MED · proposed test impact2. Review configuration snapshots
Use the selected read-only scanner and source/configuration checks, recording incomplete permissions as gaps.
- Why this is needed
- It tests a barrier in the route above and helps answer: Could an exposed application, leaked build secret or excessive cloud role reach data it should not?
- Vector / method
- Tools and guides
- Repository input
- test-case.json · RES-006 · published assessment resource; pin its version/hash in the case record.
- Output
- Configuration and secret-exposure findings; attach evidence, target ID, vector version and approval revision.
- Measure
- Selected applicable checks collected / selected applicable checks. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.
- Current result
- NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.
- Recommendation on failure
- Correct the material exposure or configuration flaw; rotate confirmed exposed secrets through the client process in a later authorised change. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.
SC05-S03MED · proposed test impact3. Validate synthetic access
Use test identities to confirm expected and prohibited storage or SaaS access, with audit events.
- Why this is needed
- It tests a barrier in the route above and helps answer: Could an exposed application, leaked build secret or excessive cloud role reach data it should not?
- Vector / method
- Tools and guides
- Client cloud/SaaS console with test identities · client/operator supplied
- Repository input
- synthetic-customers.csv · RES-007 · published assessment resource; pin its version/hash in the case record.
- Output
- Role boundary and logging evidence; attach evidence, target ID, vector version and approval revision.
- Measure
- Prohibited accesses denied / executed cases. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.
- Current result
- NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.
- Recommendation on failure
- Enforce the expected resource/tenant boundary and retain useful audit events. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.
Use one step-result record per case and G06 reporting for the client deliverable. The report must explain successes, failures, uncertainty, prohibitions and coverage limits.
Recommendations to reduce the risk
Reduce the likelihood: Reduce public exposure and standing privilege, protect build secrets and review deployment configuration.
Reduce the impact if it happens: Separate sensitive datasets and administration, restrict exports and detect unusual resource access.
How to verify improvement later: repeat the failed control case and a permitted/clean comparison using the same agreed measure; compare conditions and evidence. A better test pass rate alone is not a quantified reduction in business risk.
End of Part 1: evidence-backed findings and mitigation recommendations. The implementation action plan, allocated work, commercial service packaging and costs are deliberately deferred.
Supporting TenguProtect capabilities
Baseline from the 13 October operational audit. This does not claim the complete service is ready or that permissions are already enforced across every agent.
| Capability | Observed readiness | Remaining gap |
|---|
| Cloud, SaaS, containers and source configuration | Resources present; full execution unproven | Choose one supported cloud and verify read-only permissions, selected scanners and report quality on a disposable fixture. Do not claim every cloud is supported. |
| Web applications, APIs and customer portals | Partial; model path ready, full service unproven | Prove authenticated testing and reporting on an owned fixture. HexStrike is missing tools present elsewhere; validate the actual execution environment. |
| Security governance, suppliers and staff lifecycle | Content and advisory components; repeatable delivery unproven | Define the exact advisory scope, evidence requests, reviewer competence and report. Do not imply accreditation or legal compliance from a checklist. |