How a company falls: a simulator of the final lapses

By Kike Gandia · Threats · 5 min read

Illustration of a chain of five network nodes, one green, two amber and two red, with an open padlock in the middle, a red attacker dot over the last node, a 72-hour clock running down and documents leaking out

Almost no company falls because of a spectacular failure. It falls because of the last lapse: the exception made for senior management, the machine a vendor installed that nobody added to the inventory, the account nobody deprovisioned, the backup nobody ever tried to restore.

You don't read this, you play it. Over one week you steer your company through an attack. At each moment you choose what state each control was really in (working, on paper only, or nonexistent) and see how far the attacker gets and how much damage they leave behind. At the end, the 72-hour clock.

Interactive simulator of a week-long incident. Five moments of an attack and, at each one, three possible answers: a real, verified control; a control on paper only (it exists but nobody checks that it works); or no control. 1) Phishing email: two-factor authentication with no exceptions, two-factor except for senior management, or password only. 2) Public vulnerability in the VPN: inventory and patches within days, a patching policy with one machine outside the inventory, or patches when there's time. 3) Privilege escalation: least privilege and reviewed deprovisioning, an offboarding procedure nobody checks, or everyone is an administrator. 4) Backups: isolated, immutable and with tested restores; backups in the same domain that have never been restored; or a disk in the office. 5) Detection: alerts reviewed by a named person, logs nobody looks at, or no logging. An animated map shows how far the attacker gets and four gauges show the damage: days of downtime, data exposed, legal risk and lost trust. If there is a breach, the final 72-hour decision: notify on time and supplement later (GDPR Art. 33 and 33(4), plus notice to affected individuals if there is a high risk, Art. 34), wait for the forensic report, downplay the number of people affected and say the data was encrypted, or not notify. Concealment or misrepresentation counts as an aggravating factor (Art. 83(2)) and the infringement can cost up to €10 million or 2% of worldwide turnover (Art. 83(4)). At the end, an incident report with the controls that worked, the ones that existed only on paper and the doors with no control at all.

The five lapses, at a glance

For those who prefer to see it at a glance, or want to take it to the next management meeting: these are the simulator's five checkpoints and the question that separates a real control from one that exists only on paper.

Email Two-factor with no exceptions
Is there an account (usually senior management's) where it was switched off "because it was a nuisance"? That's the one they go after.
Perimeter An inventory of what's exposed
The patching policy only covers what's on the list. Is the machine the vendor installed on it?
Accounts Verified deprovisioning
Having an offboarding procedure is not the same as checking every quarter that no orphaned accounts with permissions are left.
Backups Tested restores
A backup that has never been restored is a hypothesis. And if it lives in the same domain, it gets encrypted along with everything else.
Detection Someone who's watching
Keeping logs detects nothing. You need a named person who reviews the alerts, out of hours too.

It's not a lack of technology: it's a lack of commitment to testing it. A control nobody verifies gives the same peace of mind as one that works, right up to the day you need it. What usually separates the companies that hold out from the ones that fall is a periodic review and someone accountable for doing it.

The 72 hours: this is no longer awareness, it's damage

You don't choose the breach. What you do in the 72 hours that follow, you do. The GDPR requires you to notify the authority within that window from the moment you become aware of it (Art. 33), allows you to do so in phases when you don't yet know everything (Art. 33(4)) and requires you to inform affected individuals if they face a high risk (Art. 34).

What protects the people affected and the company

  • Notify on time with what you know
  • Supplement the information as the analysis progresses
  • Inform affected individuals so they can protect themselves
  • Cooperate with the authority from the outset

What makes it worse and counts as an aggravating factor

  • Waiting weeks for the full forensic report
  • Downplaying the number of people affected or saying it was encrypted
  • Not notifying and hoping nobody finds out
  • The authority hearing about it from third parties (Art. 83(2)(h))

Delaying, sugarcoating or staying silent doesn't reduce the harm: it shifts it onto people who can't protect themselves.

If you want to know the real state of your controls (not the state the policy says they're in), that's exactly what we check in a pentest or a GDPR audit. And if what's missing is someone watching the alerts, that's what managed security is for.

Related service

managed security: someone watching the alerts

Topics

#Ransomware #Data-breach #GDPR #Incident-response #Security-controls #Simulator

Keep reading

Test your real controls