The previous five lessons have built the module's complete armoury: the map of the discipline, the catalogue of technical attacks, social engineering, protection measures and access control. Now comes the reality check. This lesson analyses incidents that really happened, are public and are documented, and puts them through a reproducible method of analysis. We do not study them out of morbid curiosity or because of their size: we study them because in every one of them controls you already know about failed, and because the same causes recur with a regularity that is almost comic — until it is your company's turn. You will see Target, WannaCry, Equifax, SolarWinds, Colonial Pipeline and a case of misconfigured cloud storage; for each one, a table of control failure, the control that would have prevented it and the lesson applicable to Nimbus. And we will close with an hour-by-hour reconstruction of a fictitious but plausible incident at Nimbus Reservas, in order to answer the only question that matters: what would have changed the outcome.

1. The method: how an incident is analysed
2. Target (2013): the supplier as the way in
3. WannaCry (2017): the known, unpatched vulnerability
4. Equifax (2017): an outstanding patch and blind detection
5. SolarWinds (2020): the supply chain and code signing
6. Colonial Pipeline (2021): a VPN without MFA and a decision to pay
7. A leak through misconfigured cloud storage
8. The patterns that recur in all of them
9. The Nimbus case: an hour-by-hour ransomware reconstruction
10. Closing the module

Without a method, incident analysis degenerates into anecdote ("they got a virus") or moral judgement ("they were careless"). Neither of those improves anybody's security. The following method has six steps and applies equally to a public case and to one of your own.

Three rules that make the analysis useful:

1. Look for causes, not culprits. There is almost never a villain. There is an administrator with 400 alerts a day, an impossible delivery deadline or a procedure nobody has reviewed in three years. An analysis that ends by pointing at a person guarantees that next time nobody reports anything — exactly the cultural rule of 02-03.
2. Distinguish the technical failure from the organisational one. In almost all the cases that follow, the technical control existed. What failed was the process around it: who looks at the alert, who applies the patch, who renews the certificate. Big incidents are rarely hard technical problems.
3. Always ask "would it happen to us?" honestly. The natural reflex is to think "that happened because they were huge and careless". Almost always, the translation to an SME is direct and easier to exploit.

Note: the following cases are based on public information — official reports, hearings, researchers' publications and the companies' own statements. The figures and dates are the commonly accepted ones, but any analysis of somebody else's real incident must be taken with the caveat that the complete information is rarely public. The purpose here is educational, not forensic or accusatory.

• Initial vector: credentials belonging to an external supplier (air conditioning services) that had access to the corporate network for billing and remote monitoring tasks.
• Movement: from that access, the network where the point-of-sale terminals operated was reached. The network was not adequately segmented: an air conditioning supplier should never be able to reach the payment environment.
• Impact: tens of millions of card records and personal data records; direct and indirect costs in the hundreds of millions; the resignation of the chief executive and of the head of systems.

The fact that makes Target the most cited case in the history of corporate security: the tools worked. They detected the malicious activity and raised the alarm. The failure was not technological, it was one of process: nobody with decision-making authority attended to those alerts in time. It is the perfect illustration of the NIST CSF imbalance you diagnosed in 02-01: plenty of Protect, little Detect understood as the organisational capacity to respond to what has been detected.

• Initial vector: direct exploitation of an SMB vulnerability on systems that were exposed or reachable from a compromised network. The patch had been available for two months.
• Movement: automatic, worm-like propagation, with no human intervention: each infected machine scanned and infected others. That is what explains the speed.
• Impact: services paralysed in multiple countries. The best-documented case is that of the British public health system: thousands of appointments and operations cancelled, ambulances diverted, diagnostic equipment out of action. The damage was not the ransom: it was the operational shutdown.

The uncomfortable lesson of WannaCry: there was no novel technique, no 0-day at the moment of the attack, no sophistication. It was a known vulnerability, with a patch available, left unapplied. The least glamorous measure in the 02-04 catalogue — patching — would have neutralised the biggest mass-propagation incident of recent history.

And a clarification about the kill switch that is usually told badly: it was not an organised defence or anybody's plan. It was a researcher who analysed the code, saw a lookup of an unregistered domain and registered it for a few dollars. It stopped that variant. Trusting your company's survival to somebody having that idea in time is not a strategy.

• Initial vector: a critical vulnerability known and with a patch available for two months in a web application reachable from the Internet.
• Movement: once inside, the attackers found credentials stored in the clear that gave them access to dozens of databases unrelated to the initially compromised system. A total absence of segmentation and of least privilege.
• The blind detection: the device that inspected encrypted outbound traffic needed a valid certificate. That certificate had been expired for around ten months, so the inspection was not working. The attackers exfiltrated for 76 days through a channel the organisation believed it was watching.
• Impact: sensitive personal data of almost 150 million people; fines and settlements in the hundreds of millions; resignations at the top.

The lesson that makes Equifax the most instructive case of all: the organisation had the detection control. It had bought it, installed it and configured it. But it had not worked for ten months and nobody knew. Hence the rule worth engraving:

Every control needs a control that verifies it is still working. Certificates that expire, agents that stop reporting, backups that start failing, alerts that were disabled "temporarily" a year ago. A defence degrades silently, and silence looks a great deal like security.

Immediate practical application for Nimbus: a monthly check that answers five questions: are all the machines reporting to the EDR? are all the log sources still arriving? did the last backup complete and was it restored? does any certificate expire within 30 days? have the five alerts from 02-04 ever fired (if never, perhaps they are broken)?

• Initial vector: compromise of the vendor's build process. The malicious code was inserted before signing, so the update went out signed and verified by the legitimate vendor.
• Why it was so hard to detect: every usual control passed. The file came from the right supplier, through the right channel, with the right signature. The software behaved normally for weeks before activating, and its command and control traffic imitated the product's legitimate protocol.
• Impact: access to the networks of public bodies and large companies; an investigation and remediation cost that is hard to quantify, and a lasting impact on trust in the automatic update model.

The honest conclusion, and the reason this case is special: against an adversary with state-level resources who compromises the build chain of a legitimate supplier, an SME like Nimbus has no realistic preventive defence. Pretending otherwise would be dishonest. What it can do, and it is exactly the "assume breach" approach of 01-03:

1. Limit the privileges of all third-party software. If a monitoring tool does not need to be a domain administrator, it should not be one.
2. Control outbound traffic. A command and control channel needs to get out. Egress filtering with an allowlist is the defence that is genuinely within reach.
3. Detect behaviour, not just origin: a known tool doing something it never used to do.
4. Maintain an SBOM so you can answer quickly when the next case is published.
5. Reduce the number of third parties with privileged access. Each one is an additional supply chain you do not control.

• Initial vector: a single credential, from an old VPN account that was still active, with a reused password that had appeared in somebody else's breach, with no second factor. No exploit, no 0-day, no sophisticated phishing.
• Movement: from that access to the corporate network, the attacker exfiltrated data and deployed ransomware.
• The most instructive detail: the industrial system that moves the fuel was not encrypted. The shutdown was a business decision: unable to determine with certainty the scope of the compromise or to bill correctly, the company chose to halt operations. In other words, the operational impact was caused by uncertainty, not by the encryption.
• Impact: fuel shortages on the east coast of the United States, panic buying, a regional emergency declaration.

On the decision to pay, which is what gets debated most and understood worst:

• Paying did not restore the service. The decryption tool provided was so slow that the real recovery was done with the company's own backups. That is a frequent outcome: decryption tends to be slow, partial and unreliable.
• Paying does not solve the exfiltration. The data had already left. The second extortion is not cancelled by the first payment.
• Paying funds the business model and marks the organisation as a payer, which increases the probability of another attack.
• And even so, there are situations in which an organisation with no valid backups faces going out of business. That is why the only decision taken before the incident, and the one that makes the discussion unnecessary, is to have tested immutable backups.

Legal note: paying ransoms has legal, tax, insurance and potential sanctions implications that vary with the jurisdiction and with the identity of the attacking group. In a real case, the decision must be taken with legal advice and in coordination with the competent authorities. This course does not recommend paying; it describes the case for educational purposes.

The structural lesson for Nimbus: an enormous company, with budget and with critical infrastructure, was brought to a halt by a reused password on a forgotten account. If that is the vector, size and budget do not protect you. What protects you is identity hygiene, which is free.

This case is not a particular company: it is a pattern that has recurred hundreds of times over the last decade, in companies of every size. We treat it as a case because it is, by some distance, the most likely one for Nimbus.

• Initial vector: none. There is no intrusion, no exploitation, no stolen credential. The data was public and somebody downloaded it. Technically, it is not even an attack.
• Why it recurs so much: the public permission solves an immediate problem ("my access doesn't work") and the cost shows up months later; the person who configured it is usually not the one who suffers the consequences; and there is no alarm signal at all — the bucket works perfectly.
• Typical impact: complete exposure of the data held, with no limit and no traceability of who downloaded it. In breach notification terms, it is the worst scenario: you have to assume full access by unknown parties.

The direct connection with Nimbus is not hypothetical: the 01-04 inventory already turned up Sara's payroll sheet with an "anyone with the link can view" setting. It is the same phenomenon, in another service and on a smaller scale. A public link is a publication: links get forwarded, indexed and leaked.

And the scenario that ought to keep you awake: if somebody exports a dump of the Nimbus database to debug a problem and leaves it in an accessible bucket, the exposure is not a few e-mail addresses, it is the complete diaries of forty clinics, with the sensitivity load you already know from the context rule of 01-04.

Note on legal implications: an exposure of this kind involving data that reveals health information triggers specific obligations of notification and of risk assessment for those affected, with demanding deadlines. It must be handled with the compliance owner and legal advice; it is covered in 06-03 and 04-05.

Ordered by frequency across the six cases analysed. None is exotic. None requires an expensive product.

The three cross-cutting conclusions:

1. Almost no big incident starts with a sophisticated technique. They start with an outstanding patch, a forgotten account, a supplier with too much access or a badly set permission. Sophistication, when it appears, comes after getting in.
2. In almost every case, the control existed and did not work. Target had alerts; Equifax had traffic inspection; Colonial had a VPN. What was missing was the process that keeps a control a control: somebody who looks, somebody who verifies, somebody who renews.
3. Time to detection is the variable that most determines the damage. 76 days at Equifax, weeks at Target, months at SolarWinds. The NIST CSF Detect function — Nimbus's weakest according to your own diagnosis in 02-01 — is what separates an incident from a catastrophe.

Fiction, but built out of the patterns above and out of the real findings of the Nimbus inventory. It is what would happen if nothing you have learned in this module were applied.

• The systems consultancy (A-19) has permanent administrative remote access, with shared accounts between its engineers and no MFA.
• The backups (A-03) are in the same cloud account (A-05) as production and are reachable with the same administration credentials.
• Logging exists, but nobody reviews it. There are no alerts configured.
• Nimbus has never tested a full restore.

This is the most valuable exercise in the whole module: it is not enough to list failures, you have to rank which ones matter.

The three conclusions:

1. Two controls of zero or low cost — MFA and just-in-time access for the third party — would have prevented the incident entirely. They would not have mitigated it: they would have stopped it.
2. Two low-cost controls — the secret in a manager and immutable backups — would have turned a catastrophe into a manageable incident. With the secret protected, the attacker stays on one server. With immutable backups, Nimbus restores in hours and the ransom loses all its leverage.
3. None of the ten controls requires buying a security product. They are all in the 30 and 90-day plan of 02-04. The incident does not happen for lack of budget: it happens for lack of decision.

And the alternative scenario, to see it in the positive. With the measures of 02-04 and 02-05 applied, the story would be this: day 0, 22:14 — an access attempt with the consultancy's credential; MFA fails; an alert is raised for a third-party access attempt outside the agreed window; Lucía sees it the next morning, calls the consultancy, discovers its breach, revokes the access and rotates the credentials. Total duration of the incident: one morning. Impact: zero.

You have worked through the whole conflict: who attacks, how, through where, what you defend yourself with and what happens when you do not. And the real cases have closed the circle by showing that the concepts of this course are not theory: they are exactly the controls that were missing in every one of those headlines.

Common mistakes:

• Reading the cases as other people's stories. "They were gigantic and careless" is the mental mechanism that prevents learning. The translation to an SME is direct and almost always easier to exploit.
• Stopping at the initial vector. The vector explains how they got in; the failures of segmentation, privilege and detection explain why the damage was enormous.
• Looking for culprits. An analysis that ends on a person changes nothing and guarantees that next time nobody reports anything.
• Confusing "we had the control" with "the control was working". Equifax had traffic inspection. It had been blind for ten months.
• Believing an antivirus would have stopped WannaCry. What would have stopped it was the patch published two months earlier.
• Thinking that paying the ransom resolves the incident. It does not return the exfiltrated data, decryption tends to be slow and partial, and it marks the organisation as a payer.
• Treating the supplier's breach as the supplier's problem. The data and the customers are yours, and so is the responsibility towards them.
• Analysing an incident without producing concrete changes with an owner and a date. That is entertainment in the format of a report.

Tips:

• Apply the six-step method to any incident that turns up in the news. Half an hour of analysis is worth more than a whole course of headlines.
• After each case, ask yourself the uncomfortable question: "which of our controls is today's Equifax expired certificate?". There is usually one.
• Set up the monthly control health check: agents reporting, log sources arriving, backups completed, certificates close to expiry, alerts that have ever fired.
• When you analyse an incident of your own, write the timeline before the conclusions. The causes emerge on their own once the hours are in order.
• Keep the analysis and review it after six months: half the agreed actions are usually still outstanding, and knowing that is more useful than assuming the opposite.
• Practise the exercise of section 9.5 — which controls prevent and which controls mitigate — with any risk in your organisation. It is the fastest way to prioritise well.

A 50-person SME offering a document management SaaS suffers this incident:

• 15 January: a critical vulnerability is published in the document processing library they use. The patch comes out the same day.
• 2 February: an attacker exploits the vulnerability on the document conversion server, which is reachable from the Internet.
• 2-20 February: the attacker discovers that this server has mounted the network folder where all the customers' documents are stored, with read and write permissions.
• 20 February: they exfiltrate 400 GB of documents.
• 21 February: they encrypt the network folder and the backups, which were on the same storage array.
• 21 February: customers report that they cannot get access. The incident is discovered.
• 22 February: the team discovers that the alerting system sends e-mails to the address of an administrator who left the company eight months ago.

Required: (a) apply the six steps of the method; (b) build the control failure → control that would have prevented it table; (c) identify which patterns from section 8 appear; (d) give the two controls that would have changed the outcome and justify why those and not others; (e) point out the failure of 22 February and explain which case in this lesson it resembles.

Choose Target or Equifax and produce a complete translation to Nimbus Reservas.

Required:

1. Write the timeline of the equivalent incident at Nimbus, with the team's real names, assets from the A-01…A-22 inventory and specific times.
2. Identify which elements of Nimbus's current environment make that incident possible today.
3. List the controls that would prevent it, stating which are already in the 30/90/180-day plan of 02-04.
4. Estimate the impact on Nimbus across four dimensions: operational, financial, reputational and regulatory.
5. Draft the communication paragraph Marta would send to customers within the first 24 hours, bearing in mind that the full scope is not yet known.

Go back to the Nimbus case in section 9. The attacker was inside for 20 days without being detected.

Required: (a) for each of the five phases of the attack (initial access, reconnaissance, escalation, exfiltration and backup sabotage), define one detectable signal and the log source that would contain it; (b) write the corresponding alert rule in pseudocode or SQL; (c) rank the five alerts by the ratio of detection value to implementation cost; (d) for each alert, define who receives it, on which channel and what they do in the first 15 minutes; (e) explain why it is preferable to have these five alerts rather than fifty.

Solution 1

(a) The six-step method:

1. Timeline: 18 days from publication of the patch to exploitation; 19 days inside with no detection; detection by the customers on 21 February. Recovery predictably long or impossible.
2. Initial vector: a known critical vulnerability, with a patch available since 15 January, on a server exposed to the Internet.
3. Movement: nothing sophisticated. The conversion server already had mounted the folder with every customer's documents, with read and write permissions. A single hop, by defective design.
4. Impact: 400 GB of customer documents exfiltrated; data and backups encrypted; service outage; breach notification with a broad scope; serious reputational damage for a SaaS whose product is precisely the custody of documents.
5. Control failures: see the table below.
6. Lessons: section (d).

(b) Control failures:

(c) Patterns present: 1 (a known, unpatched vulnerability), 2 (absence of segmentation), 5 (late detection), 6 (a control that fails silently), 8 (insufficient backups) and 10 (size does not protect you). Six out of ten, in a small company's incident.

(d) The two decisive controls:

1. Patching to deadline. It would have prevented the entry entirely. It is the only control on the list that stops the incident rather than mitigating it, and that is why it comes first.
2. Immutable, separated backups. They do not prevent the entry or the exfiltration, but they turn the possible disappearance of the company into an interruption of hours. It is the control that removes the most impact per euro invested.

The other controls (segmentation, least privilege, alerts) are equally necessary, but these two are the ones that change the outcome: the first stops it happening; the second stops it being terminal.

(e) The failure of 22 February — alerts sent to an ex-employee's address — is exactly the Equifax case: a detection control that existed, was paid for and was configured, and had not worked for eight months without anybody knowing. The consequence is the same: false confidence, which is worse than not having the control, because it stops you looking for alternatives. And it shares a root cause with Colonial Pipeline: an identity that outlived its holder's departure. The fix is twofold: alerts directed to a team alias and a monthly check that the alerts really do arrive — by firing a test alert, for instance.

Solution 2 (worked through with the Target case; Equifax is analogous)

1. Equivalent timeline at Nimbus:

2. What makes it possible today: the consultancy's permanent, shared access with no MFA (A-19); the absence of segmentation between the administration network and the data zone; administrative credentials in runbooks (A-17); the absence of alerts that anyone attends to; the absence of access logging for bucket A-02; and no process at all for reviewing third-party access.

3. Controls and where they fit in the 02-04 plan:

4. Estimated impact across four dimensions:

• Operational: the service keeps running (there is no encryption), but the team spends weeks on investigation and response, and all development stops.
• Financial: costs of forensic analysis, legal advice, communication, a possible fine and, above all, loss of contracts. For a B2B SaaS, the biggest cost is non-renewal.
• Reputational: direct damage to asset A-20. The clinics entrusted their patients' data; the problem is one of trust, not of technology.
• Regulatory: a breach of personal data that reveals health information, with obligations to notify the authority and, probably, those affected. It must be handled with the compliance owner and legal advice (06-03).

5. Marta's communication within the first 24 hours:

"Dear customer,

On [date] we detected unauthorised access to part of our infrastructure, originating in the credentials of an external supplier with technical access to our systems. We have revoked that access, isolated the affected systems and activated our response procedure with the support of external specialists.

We are determining precisely which information may have been affected. We do not yet have the definitive scope and we will not communicate unconfirmed estimates. We will write to you again within 72 hours at the latest, even if only to say that the investigation is continuing.

What we can confirm now: the service remains operational; payment data is tokenised at our gateway and is not stored on our systems; and we have notified the supervisory authority in accordance with our obligations.

Your direct point of contact for any question is [name and telephone number]. I am deeply sorry about this situation and I will keep you personally informed.

Marta Solves — CTO, Nimbus Reservas, S.L."

The five decisions behind this communication: it goes out early even though not everything is known; it neither minimises nor speculates; it says explicitly what is not yet known; it commits to a deadline for the next communication and keeps it even if there is no news; and it gives a named point of contact. The most common and most expensive mistake is waiting until you have all the information: by the time it arrives, the customer has already heard from somewhere else and trust is broken. Crisis communication is developed in 04-05.

Solution 3

(a) and (b) Signals, sources and rules:

(c) Ranked by value/cost:

(d) Recipient and the first 15 minutes:

(e) Why five and not fifty. Three reasons, and the third is decisive:

1. Real capacity. Nimbus has one person with a percentage of their time for this. Fifty alerts produce fatigue and, after three weeks, all of them get ignored. It is exactly what happened at Target: the alerts existed and nobody acted.
2. Coverage by phase, not by technique. These five cover the five phases of the attack. Having just one of them working at any of those phases is enough to break the chain. You do not need to cover every technique: you need to cover every moment.
3. Every alert must have an owner, a channel and a procedure. Writing those three fields for five alerts is an afternoon's work; for fifty, it is a project that never gets finished. An alert with no owner is not an alert: it is a log line with more words in it.

The healthy progression is to start with five that genuinely work, and to add a new one every time an incident or a simulation reveals a blind spot. That is the zero-cost purple team of 02-01: detection grows out of what actually happens, not out of a theoretical catalogue.

You have closed the module with the reality check. You have a six-step method of analysis — timeline, initial vector, movement, impact, control failures and lessons — with its three rules: look for causes and not culprits, distinguish the technical failure from the organisational one, and always ask honestly whether it would happen to us. And you have applied it to six real incidents whose teachings are now part of your judgement: Target, where the tools detected and nobody acted, and where an air conditioning supplier reached the payment environment; WannaCry, where the biggest mass-propagation episode of recent history would have been neutralised by a patch published two months earlier; Equifax, with its outstanding patch, its credentials in the clear and — above all — its detection control expired for ten months, from which comes the most transferable rule of the lesson: every control needs a control that verifies it is still working; SolarWinds, which teaches that a valid signature certifies origin and not the absence of malice, and against which the only honest strategy for an SME is to limit privileges, control egress and detect behaviour; Colonial Pipeline, where a password reused on a forgotten account with no MFA brought critical infrastructure to a halt, and where paying did not restore the service; and the leak through misconfigured storage, the most likely pattern for Nimbus, in which there is not even an attack.

From all of them you have extracted the ten patterns that recur — patching, segmentation, weak identity, third parties with excessive access, late detection, controls that fail silently, badly stored secrets, untested backups, improvised crisis management and the finding that size does not protect you — together with the three cross-cutting conclusions: that almost no big incident starts with a sophisticated technique, that in almost all of them the control existed and did not work, and that time to detection is the variable that most determines the damage. And you have reconstructed hour by hour a ransomware incident at Nimbus that comes in through the consultancy's remote access, escalates by means of a secret forgotten in a .env, exfiltrates 1.2 TB over seven days and destroys backups that sat in the same account as production; with its complete analysis and, above all, with the answer to the question that gives the whole exercise its meaning: two zero-cost controls — MFA and just-in-time access for the third party — would have prevented it entirely, and two more low-cost ones — the secret in a manager and immutable backups — would have turned the catastrophe into a morning's work. None of them requires buying anything.

Now run through, in your head, the defences you have accumulated across these six lessons: TLS protecting traffic in transit, the 120-second signed URLs of the attachments bucket, the HMAC signature that authenticates the gateway webhook, DKIM certifying Nimbus's e-mail, the FIDO2 passkeys that resist phishing because the key never leaves the device, the JWT's RS256 signature validated with the issuer's public key, the encryption at rest of the database and of the immutable backups, the constant-time comparison of the TOTP code, the code signing of the SolarWinds updates. All of them — absolutely all of them — rest on the same foundation: cryptography. So far we have used it as a black box that works; from here on we are going to open it up.

In Module 3: Cryptography we will study what is inside that box and why it can be trusted. We will begin with the fundamentals and the vocabulary, work through symmetric and asymmetric cryptography with their complementary roles, hash functions, HMAC and the secure storage of passwords — which is where it is finally explained how Nimbus should store its users' passwords —, the protocols that combine all those pieces, such as the TLS you have been taking for granted for six lessons, key management, certificates and PKI, which is the genuinely hard problem, and finally the practical applications in a system like Nimbus's. We start with Introduction to Cryptography (03-01).