Cyber Security Incidents v. Cyber Security Attacks

There’s justifiably big brouhaha over the global computer outage caused by a flawed Crowdstrike update, and everyone is saying what needs to be said about how resilency is a massive issue; monoculture is a huge problem; and just how much Windows sucks in every conceivable way.

But man, was I disappointed when Crowdstrike CEO George Kurtz, who knows better, spouted this chestnut about the largest IT outage in the history of the world:

“Today was not a security or cyber incident.”

I am not griping about semantics: when your customer cannot reach the system, or application, or service that you expect to be accessible to them, that’s a security incident.

And if you want to know why I react strongly, just imagine being one of the hundreds of thousands of people stranded in airports by the Crowdstrike BSOD this past week when you hear Crowdstrike’s CEO say, obscenely, that “Our customers remain fully protected."

Let’s go to NIST, which defines a computer security incident as:

“An occurrence that results in actual or potential jeopardy to the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies. See cyber incident. See also event, security-relevant, and intrusion.” [Emphasis added]

What Kurtz and others who echoed this surely meant to say was that this wasn’t a “cybersecurity attack.” Indeed, it was almost certainly the result of flawed testing by Crowdstrike, nothing remotely more sexy than that.

But when professionals carelessly or intentionally use jargon to soothe the public, it does damage.

I advise my clients that they need to treat availability outages in the same way they treat data breaches or attacks: rally the troops, run the procedures, solve the problem, analyze the root causes, learn from them, and then (critically) iterate on your incident response procedures, and your detection capabilities.

It’s counterintuitive. Engineers feel that outages are a way of life, and don’t want to make a big deal of them. I can’t say how often I have worked with firms that have outages all the time that executives don’t know about precisely because people haven’t escalated previous outages to the level of incident response. The result is that no one tracks these outages, so no one will ever approve the resources that could solve the underlying issues.