Compromised supplier update
A signed update from a software supplier reaches several endpoints before the supplier warns of a possible build compromise.
Fictional training scenario; no real system or person is described.
Safety and authority boundary
Do not assume a valid signature proves safety; separate confirmed installation from suspected malicious behavior.
Preparation
GV · ID · PRA signed update from a software supplier reaches several endpoints before the supplier warns of a possible build compromise.
Your decision. Before opening the response, decide what each named team should do, how it would do it, why, whose approval is needed, and what evidence would change the decision.
Reveal the worked team response
| Team | What | How | Why |
|---|---|---|---|
| Juniper Evidence team | Prepared an evidence route | Named read-only sources and custodians for: Endpoint behavior changes after installation, but the supplier advisory is preliminary and does not yet list every affected version. | The first alert needs a verifiable provenance and time. |
| Kestrel Service team | Rehearsed safe continuity | Tested an isolated version of: Redeploy a verified prior version through an approved rollback path after testing business dependencies. | A rushed recovery can worsen the service impact. |
| Lumen Decision team | Set authority and escalation | Assigned owners and approval conditions around: Do not assume a valid signature proves safety; separate confirmed installation from suspected malicious behavior. | Safety, privacy and communications need accountable decisions. |
Detection and analysis
DEEndpoint behavior changes after installation, but the supplier advisory is preliminary and does not yet list every affected version.
Your decision. Before opening the response, decide what each named team should do, how it would do it, why, whose approval is needed, and what evidence would change the decision.
Reveal the worked team response
| Team | What | How | Why |
|---|---|---|---|
| Juniper Evidence team | Triaged the signal | Preserved source, UTC time and a second independent check for: Endpoint behavior changes after installation, but the supplier advisory is preliminary and does not yet list every affected version. | One alert is a lead, not proof of cause or scope. |
| Kestrel Service team | Measured user impact | Compared the actual service with the scenario baseline: A signed update from a software supplier reaches several endpoints before the supplier warns of a possible build compromise. | Technical alerts alone do not establish operational impact. |
| Lumen Decision team | Declared a bounded case | Recorded confirmed facts, unknowns, owner and next review time. | The teams can coordinate without overstating the evidence. |
Response and containment
RSDo not assume a valid signature proves safety; separate confirmed installation from suspected malicious behavior.
Your decision. Before opening the response, decide what each named team should do, how it would do it, why, whose approval is needed, and what evidence would change the decision.
Reveal the worked team response
| Team | What | How | Why |
|---|---|---|---|
| Juniper Evidence team | Preserved and scoped evidence | Saved the original records and defined a bounded path for: Pause the rollout, preserve package hashes and installation logs, and isolate hosts only where impact is supported. | Containment must not destroy the basis for later review. |
| Kestrel Service team | Applied the approved control | Implemented: Pause the rollout, preserve package hashes and installation logs, and isolate hosts only where impact is supported. | A reversible, owner-approved change reduces harm without expanding scope. |
| Lumen Decision team | Authorized and communicated | Logged the approver, affected users and constraint: Do not assume a valid signature proves safety; separate confirmed installation from suspected malicious behavior. | Response actions need clear authority and proportional notice. |
Recovery
RCRedeploy a verified prior version through an approved rollback path after testing business dependencies.
Your decision. Before opening the response, decide what each named team should do, how it would do it, why, whose approval is needed, and what evidence would change the decision.
Reveal the worked team response
| Team | What | How | Why |
|---|---|---|---|
| Juniper Evidence team | Checked for persistence | Compared new telemetry against: An unaffected build hash is present, key workflows pass, and monitoring finds no recurring suspicious behavior. | An apparently healthy service can still be compromised. |
| Kestrel Service team | Restored in stages | Executed: Redeploy a verified prior version through an approved rollback path after testing business dependencies. | A staged return tests dependencies before widening access. |
| Lumen Decision team | Accepted the business outcome | Requested owner sign-off only after: An unaffected build hash is present, key workflows pass, and monitoring finds no recurring suspicious behavior. | Recovery is a service decision, not merely a green dashboard. |
Improvement
ID.IMRequire staged rollouts, supplier contact paths, signed artifact provenance and rollback rehearsal.
Your decision. Before opening the response, decide what each named team should do, how it would do it, why, whose approval is needed, and what evidence would change the decision.
Reveal the worked team response
| Team | What | How | Why |
|---|---|---|---|
| Juniper Evidence team | Turned uncertainty into a test | Documented the evidence gap and proposed: Require staged rollouts, supplier contact paths, signed artifact provenance and rollback rehearsal. | A lesson needs a measurable future check. |
| Kestrel Service team | Rehearsed the changed control | Assigned an owner and date to test: Require staged rollouts, supplier contact paths, signed artifact provenance and rollback rehearsal. | An untested action item is not a verified improvement. |
| Lumen Decision team | Closed the decision record | Approved resources, tracked the owner and checked the new control later. | Learning must feed Govern, Identify and Protect. |
Recovery acceptance test
An unaffected build hash is present, key workflows pass, and monitoring finds no recurring suspicious behavior.
Improvement to verify
Require staged rollouts, supplier contact paths, signed artifact provenance and rollback rehearsal.