Model privilege misuse and escalation

A useful threat model does not stop at a generic item such as “account theft.” Start with a business consequence to prevent: unauthorized extraction of claims data, unapproved policy changes or disruption of a denial service. Name a plausible entry point, an identity or token the attacker could misuse, its existing privileges and the additional step needed to reach the outcome. Then identify evidence that would separate this path from unsupported speculation. A storage misconfiguration, a role that can assign other roles and a business record that sends an unverified attribute are distinct hypotheses with different controls and tests. Being “inside the network” does not rule out any of them.

Draw the path as transitions: foothold → credential acquisition → permitted action or bypass → privilege increase or trust-boundary crossing → data access or modification. For each transition record the prerequisite, required permission, affected resource, observable signal and existing control. Do not invent numerical success probabilities. Crossing can be horizontal between cloud accounts rather than vertical to a global administrator. If a workload identity can read all object stores when it needs one, compromise of a low-value service becomes a route to a sensitive store. The decisive measure is what the compromised identity can do, not how reassuring its role name sounds in a diagram.

Keep likelihood reduction separate from impact reduction. A short-lived token may narrow the exploitation window but cannot prevent a large export within minutes if its scope is broad. Restricting the resource can limit harm from a leaked token without fixing the leak. Design layers with distinct jobs: protect the credential, narrow privilege, check context at the resource, limit request volume, detect abnormal use and revoke the ability during response. Multiple controls do not justify retaining a sweeping entitlement. Record dependencies among layers; if all trust the same unverified attribute source, they may fail together. Compare attack paths under the actual permission graph, not an idealized future design.

When one transition cannot be removed immediately, state residual risk precisely. Suppose a legacy converter cannot be changed within a week. The team can remove operations' ability to edit store policy, suspend copying sensitive results to analytics and review access logs more closely. Those are temporary measures with owners and expiry, not proof of permanent remediation. Prioritize a transition that unlocks many paths or the greatest impact. Suppressing a noisy alert is not equivalent to stopping an export. If tests used synthetic data, do not claim they proved every production restriction. Compare configuration and drift before extending the test conclusion to production.

Do not rank threats by multiplying two arbitrary likelihood and impact numbers. When incident data are weak, use an explained ordering: present reachability, number of assets opened by the privilege, operation sensitivity and ease of revocation after detection. State uncertainty. A workload identity might serve two applications that have not yet been separated, making restriction a dependency decision. Show the service owner two options: split the identities and scope each, or temporarily retain the shared identity while preventing new role grants and recording detailed access. The first treats the underlying coupling but requires engineering and rollout; the second reduces an urgent path without resolving identity sharing.

A path test needs boundaries that prevent the verification itself from creating an incident. Use an isolated account and synthetic records, specify authorization, test window and who may stop the exercise. Record state before and after the change. A test that proves excessive privilege can be granted and leaves that privilege in place increases risk. Ask two questions of the result: did the intended policy stop the action, and did a log connect the denied request to identity, resource and rule? If a network block stopped it before policy evaluation, do not attribute success to the wrong control. Try the alternate legacy interface as well; it might succeed even while the primary path fails.

For each modeled path, the risk register needs an owner, treatment decision, residual exposure and closure evidence. “Continuous monitoring” is not an action unless it specifies a signal, threshold, recipient, response time and alert exercise. Nor is “least privilege” a provable state without comparing an identity's allowed operations with the work it actually needs. After narrowing converter permissions, watch for legitimate processing failures. Repair missing dependencies with a resource-specific grant, not a return to global access. A defensible decision reduces the harmful path, preserves the legitimate job and leaves a reviewable verification trail.