History · Unit 05 · Lesson 2 of 2

When one incident reaches many organizations

WannaCry, SolarWinds, and the shared dependencies that turn technical events into wider disruption.

8 minready

Helpful before thisWhere hacking comes from

After this lesson you can

distinguish direct infection from disruption through a dependency
explain why trusted suppliers still need bounded access and oversight
evaluate whether a recovery plan depends on the service it must replace

Explore the eras below. On wider screens, scroll sideways to see the full timeline.

A security incident rarely respects the boundaries of an organization chart. Your computer may work while the service you need is unavailable. Your organization may maintain its own systems while depending on a supplier’s software. History makes those connections visible.

Both arrows point toward the shared dependency: applications and recovery documents need the same identity provider. This fictional plan needs an independent recovery access path.

2017: disruption is larger than a device count

On May 12, 2017, WannaCry began causing widespread disruption, encrypting data and demanding ransom. The UK’s National Audit Office documented the effect on NHS services in England. Its report distinguished 6,912 identified appointment cancellations from an estimate exceeding 19,000: recorded and estimated impact are different claims. It also separated directly infected organizations from others affected through dependencies or precautions.

That distinction is useful beyond this incident. A clinic unable to receive records has an availability problem even if its own computers are running. Counting infected devices cannot, by itself, measure delayed care, disrupted communication, or the work needed to recover. Conversely, counting affected organizations does not prove that every one was infected.

2020: trust can connect separate organizations

The SolarWinds Orion compromise became public in December 2020. Malicious changes to supplier software brought the software supply chain into the response. In January 2021, CISA’s updated guidance distinguished organizations with evidence of follow-on activity from those without it. The history is a reminder to examine what happened in a particular environment rather than assuming one uniform outcome.

A software signature can support a claim about the source and integrity of a file under a trusted key. It cannot guarantee that the code is harmless. A compromised production process can undermine the assumptions behind the familiar update path. Software still needs maintenance; supplier trust belongs alongside permissions, monitoring, and recovery.

Trace a fictional dependency

A community center uses one identity provider for bookings, staff email, payments administration, and its recovery documents. These are four applications, but they share a sign-in dependency. If that dependency becomes unavailable, moving the documents to another folder will not help someone who still needs the same sign-in service to read them.

The center draws two kinds of connection: needs this to operate, and can change or administer this. They answer different questions. A booking service may need email to send confirmations without needing permission to administer staff mailboxes. Reducing unnecessary authority limits possible consequences; providing an independent fallback helps continuity.

PredictThe center moves bookings to a second supplier. Both suppliers still use the same sign-in service. Has it removed the shared sign-in failure?

No. It has changed one supplier relationship, but the shared identity dependency remains. Redundancy helps only against the failures it actually separates.

Ask what the proposed control changes

Control	The question it helps answer	What it does not establish alone
Software inventory	Where do we use this product or service?	Whether every deployment was affected
Bounded permissions	What can this component change?	Whether its permitted behavior is always safe
Independent recovery access	Can responders reach essential instructions?	Whether the restored service is correct

Use these historical cases to build a habit of separating cause, reach, impact, and recovery. A report may establish one while leaving another uncertain. That is more informative than a single dramatic label. Continue with incident coordination and network boundaries.

Check yourself

No timer. No penalties. Read the explanation and try again whenever you like.

A clinic cannot receive records from an affected partner, but has no evidence of local infection. What does this establish?

Show the answer
Correct answer: The clinic is operationally affected; local infection is a separate question. This distinguishes the service impact from its technical cause and location.
An application has a valid supplier signature. Which conclusion is justified?

Show the answer
Correct answer: The signature supports origin and integrity under the trusted key; behavior still needs evaluation. A signature binds bytes to a key. It does not prove that the producer or build process made only safe decisions.
An organization keeps recovery instructions in a different cloud folder using the same unavailable sign-in service. Is that sufficient independence?

Show the answer
Correct answer: No: the recovery access path still shares the failed dependency. A useful fallback must remain reachable under the failure conditions it is designed for.
A historical report distinguishes affected organizations from directly infected organizations. How should you summarize it?

Show the answer
Correct answer: Keep the two populations distinct and explain how dependencies spread impact. Both numbers can be meaningful, but they measure different things.

Try it

WriteInvent a community center with bookings, email, payments, and a building-access service. Draw what each needs to work. Circle one dependency shared by three services, then describe a fallback that does not need that dependency. Use fictional names and data.

References