Chapter 31 — Advanced cases in cloud and identity incidents

Lesson map

Lesson 31 published. Map, example, EX091.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["31.1 Tenant scope"]
  N2["31.2 Tokens and lifetimes"]
  N3["31.3 Audit events and retention"]
  N4["31.4 Shared responsibility"]
  N5["31.5 Recovery in the cloud"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX091"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["31.1 Tenant scope"]
  N2["31.2 Tokens and lifetimes"]
  N3["31.3 Audit events and retention"]
  N4["31.4 Shared responsibility"]
  N5["31.5 Recovery in the cloud"]
  N6["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX091"]

[Learning outcomes and connection]
    |
    v
[31.1 Tenant scope]
    |
    v
[31.2 Tokens and lifetimes]
    |
    v
[31.3 Audit events and retention]
    |
    v
[31.4 Shared responsibility]
    |
    v
[31.5 Recovery in the cloud]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX091]

Learning outcomes and connection

You will be able to (1) scope a cloud incident by tenant, subscription and identity; (2) reason about token lifetimes and their effect on containment; (3) identify the audit events and their retention in cloud platforms; (4) apply the shared-responsibility model to response; and (5) compare containment and evidence plans across identity architectures. Chapter 13 introduced identity concepts; this chapter applies them in cloud settings where much of the infrastructure belongs to a provider.

31.1 Tenant scope

Cloud resources are organized in tenants, accounts, subscriptions or projects. An incident's scope includes the identities that can act in that scope, including external ones: guest users, partner applications, managed-service providers with delegated access. Mapping who can act is the first step; Chapter 6's reachability applies.

In the referral-letters example, scope starts with the phished administrator but must include the new access key the attacker created, since it is an identity that can act independently of the original account. Guest users and partner applications with delegated access belong on the same list until shown to be irrelevant.

31.2 Tokens and lifetimes

Cloud APIs accept bearer tokens. Access tokens are usually short-lived (often around an hour); refresh tokens can last much longer and obtain new access tokens. Containment must address refresh tokens and sessions, not only passwords. Some platforms support continuous access evaluation to revoke more quickly; whether it applies depends on the service and configuration — check provider documentation.

Case B shows the benefit of short sessions: once the IdP user is disabled, existing role sessions expire within an hour. In Case A the attacker's long-lived key keeps working until someone deactivates it, which is why key review comes first there. Write down the lifetime of every credential type involved before declaring containment.

31.3 Audit events and retention

Cloud platforms log control-plane actions (create, delete, change permissions) and, with additional configuration or licensing, data-plane access (reading objects, mail items). Retention defaults vary and may be short. The Exchange Online case reviewed in Chapter 20 showed how detection depended on the audit logging available to the customer. Before an incident, know which events you have and for how long; during one, export and preserve them early.

The referral-letters cases show the stakes. In Case A, with no data-read logging, nobody can say which letters were read, so exposure must be assumed for the whole bucket. In Case B the read logs, kept in a separate account, list each object, so the privacy assessment can name exactly what was taken and for whom. The difference was decided months before the incident.

31.4 Shared responsibility

Providers secure the underlying platform; customers secure their configurations, identities and data. In incidents the boundary determines who can investigate what: the customer cannot inspect the provider's internal systems, and the provider may not investigate customer configurations without a request. Response plans should name provider support paths and what evidence the provider can supply.

For Harbourline's vendor-hosted booking platform, the vendor controls much of the evidence, so the response plan must say how to request it and how quickly. Agree those paths in the contract, before an incident forces the question.

31.5 Recovery in the cloud

Recovery may mean redeploying infrastructure from code, restoring storage from versioned or immutable backups, and re-establishing trust: rotating keys, removing unknown applications and federation settings. Attackers who gain high privilege can delete backups in the same account; separation of backup accounts is a resilience control.

In the referral-letters cases, Case A's backups sit in the same account the attacker controlled, so they may have been deleted or altered; Case B's sit in a separate account with deletion protection. Recovery in A therefore starts by establishing whether any trustworthy copy exists at all, which is a question B never has to ask.

31.6 Worked example (synthetic): two architectures

Fictional. Two clinics networks suffer the same event: an administrator's credentials are phished and used to create a new access key and download a storage bucket of scanned referral letters.

Case A — cloud-only identity: administrators are local users of the cloud account with long-lived access keys; logging of data reads is not enabled; backups are in the same account. Case B — federated identity: administrators sign in through the organization's IdP with MFA, receive one-hour role sessions; data-read logging is enabled to a separate logging account; backups are in a separate account with deletion protection.

Containment: A — deactivate the new and old access keys, reset the user's console password, check for other new users and keys, review permissions; the attacker's keys work until deactivated. B — disable the user in the IdP and revoke sessions; existing role sessions expire within an hour, and can be cut sooner with a deny policy for sessions issued before a time, if the platform supports it.

Evidence: A — control-plane log shows key creation, but which objects were read is unknown (no data-read logging) — exposure must be assumed for the whole bucket. B — data-read logs list each object read, allowing a precise exposure set.

Provider-dependent assumptions: token lifetimes, revocation behaviour and log availability differ by provider and configuration; verify each in documentation before relying on them.

31.7 Common errors and limits

• Resetting passwords while long-lived keys and refresh tokens remain.
• Discovering during an incident that data-access logging was never enabled.
• Keeping backups where a compromised administrator can delete them.

• Generalizing one provider's behaviour to another.

• Checking only for the access key the attacker created, not for other new users, roles or policies.

• Assuming the provider will supply data-read logs that were never enabled.
• Declaring exposure limited without logs capable of showing what was read.
• Restoring from backups in the same account without first checking whether the attacker altered or deleted them.

Exercises — chapter 31

Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.

EX091 — Scope list. Steps: list six categories of identity that could act in a cloud tenant and how you would enumerate each. Rubric: 3 = users, guests, service principals/applications, managed identities/roles, delegated partner access, federation trusts; enumeration via provider admin APIs/consoles; 2 = four; 1 = users only; 0 = none.

EX092 — Containment plan for A. Steps: write an ordered containment plan for Case A with verification steps. Rubric: 3 = deactivate keys, check for other new identities/keys/policies, rotate credentials, protect backups, verify via control-plane logs; order justified; 2 = misses persistence checks; 1 = password only; 0 = none.

EX093 — Exposure statement. Steps: write the privacy-relevant exposure statement for A and for B. Rubric: 3 = A: whole bucket potentially exposed (no read logs), number of letters; B: exact objects read with counts; both fact-limited; 2 = one; 1 = speculative; 0 = none.

Chapter synthesis

In cloud incidents, scope by every identity that can act, contain tokens and keys as well as passwords, depend on audit logs you enabled in advance, respect the shared-responsibility boundary and keep recovery copies out of the attacker's reach.