Chapter 34 — Integrate identity, endpoint and cloud response | Engineering Incident response and cyber resilience

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 34 — Integrate identity, endpoint and cloud response

Lesson map

Lesson 34 published. Map, example, EX067.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["34.1 Different control planes, different rules"]
  N2["34.2 Interface design"]
  N3["34.3 Correlation"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX067"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["34.1 Different control planes, different rules"]
  N2["34.2 Interface design"]
  N3["34.3 Correlation"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX067"]

[Learning outcomes and connection]
    |
    v
[34.1 Different control planes, different rules]
    |
    v
[34.2 Interface design]
    |
    v
[34.3 Correlation]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX067]

Learning outcomes and connection

After this chapter you can (1) design integration interfaces across identity, endpoint and cloud control planes; (2) respect each platform's own authorisation, rate limits and evidence rules; (3) correlate events across platforms with explicit entity and time mapping; and (4) validate a cross-platform case trace and its rollback. It builds on Chapters 11, 12, 22 and 27 and prepares Chapters 38 and 44.

34.1 Different control planes, different rules

Each platform has its own model. The identity provider (IdP) controls accounts, sessions, tokens and federation; the endpoint platform controls agents, processes and network isolation of hosts; the cloud provider controls resources, roles and keys through its API and logs actions in its audit trail. Each has its own permission model, API rate limits, eventual-consistency delays and log retention. An integration that ignores these will fail exactly under incident load. In case C-3101 below, the cloud audit event for CreateAccessKey arrived 11 minutes after it happened, which is one such delay.

34.2 Interface design

For each integration define: the actions used and their permission scopes (least privilege — the integration identity that disables accounts should not be able to create administrators); idempotency (does a repeated call do harm?); consistency (how long before an action takes effect everywhere — token revocation may propagate over minutes); rate limits and the breaker behaviour (Chapter 33); evidence (which audit event proves the action happened, and with what delay it appears); and rollback. Treat provider limits as requirements; document them with the date checked, because they change.

34.3 Correlation

A single incident spans platforms: a phished account (IdP) signs in from a new device, a process on a laptop exfiltrates data (endpoint), and an access key is created in a cloud account (cloud audit). Correlation requires entity resolution across identifiers (Chapter 22) and time alignment with known offsets and delivery delays. Cloud audit logs in particular can arrive many minutes after the event; rules that correlate on ingest time will miss or misorder.

Case C-3101 in the worked example shows this risk concretely. By event time, the cloud key was created at 09:19:55, after the 09:12:04 sign-in and the 09:14:30 rclone.exe start. By delivery time it appears at 09:31:02, so a ten-minute correlation window on ingest time would separate it from the IdP event.

34.4 Worked example (synthetic): cross-platform account incident at HVSS

Trace for case C-3101 (all identifiers synthetic):

09:12:04 IdP: sign-in m.kaur@hvss.example from new device, MFA satisfied by push approval (event delivered 09:12:40).
09:14:30 Endpoint: on laptop HV-LT-0441, process rclone.exe started by HVSS\mkaur, outbound 2.1 GB to 198.51.100.23 (documentation range).
09:19:55 Cloud audit: CreateAccessKey for role-assumed session tagged with m.kaur (delivered 09:31:02 — 11 minutes late).

Integration diagram: case platform → IdP (revoke sessions, disable account; scope: user-admin-limited) → endpoint (isolate host; scope: isolate-only) → cloud (deactivate key, attach deny policy to role session; scope: key-admin-limited). Each arrow lists expected effect delay and verifying event.

Validation: the trace links all three by resolved entity person:0441, aligns event times (not delivery times) and shows that the cloud key was created after the push-MFA approval — consistent with MFA fatigue, a hypothesis to test. Actions executed: sessions revoked (verified by IdP audit event at 09:41), host isolated (agent confirmation 09:42), key deactivated (cloud audit 09:44, delivered 09:53). Rollback plan recorded for each.

34.5 Errors and limits

One over-privileged integration identity for all platforms.
Correlating on delivery time.
Assuming actions take effect instantly everywhere.
Ignoring rate limits until the incident.

The C-3101 integration in the worked example was designed against all four of these errors. It uses three separate scopes, user-admin-limited for the IdP, isolate-only for the endpoint and key-admin-limited for the cloud, rather than one powerful identity. Correlation used event times, so the 11-minute delay of the cloud audit record did not reorder the trace. Each action was confirmed by its platform's own record, and the key deactivation at 09:44 was not delivered until 09:53.

Exercises — chapter 34

EX067 — Integration spec. Objective: define an interface. Inputs: the cloud integration of the worked example. Steps: write its specification: actions, permission scope, idempotency, consistency delay, rate-limit behaviour, verifying evidence, rollback. Expected evidence: specification. Rubric: 3 = all seven elements specific; 2 = five; 1 = vague; 0 = none.

EX068 — Correlation window. Objective: handle delivery delay. Inputs: a rule "IdP new-device sign-in followed by cloud key creation within 15 min" evaluated on ingest time; cloud delivery delay up to 15 min. Steps: show a case the rule misses and redesign it. Expected evidence: example and design. Rubric: 3 = event-time evaluation with a watermark/late-arrival wait of ≥ 15 min, plus re-evaluation on late events; 2 = partial; 1 = widen window only; 0 = none.

Chapter synthesis

Integrating response across identity, endpoint and cloud means respecting each plane's permissions, limits, delays and evidence; correlating on event time with explicit entity mapping; and verifying every action with the platform's own audit record.

Continue studying — chapter 34 of 50

← Chapter 33 · Course chapter index · Chapter 35 →

Continue to the next authored lesson.