Crowdstrike - a para-incident review



We find ourselves in the midst of a classic social response to a significant incident - a heady blend of technobabble, confusion and hyperbole, with a sprinkling of genuinely helpful information, grief and support for those right in the thick of it, and warnings about the likelihood of further exploitation ... of ... the classic social response to a significant incident. 

That's a positive feedback loop, amplified by the echo chambers of social media, and traditional news reporters whose job is (in part) to stir the pot and sell papers.

"This is HUGE!" they tell us, breathlessly. "Bigger than a really big thing, and still growing!" According to the din just on LinkeDin over the weekend, the Crowdstrike incident is "a major global outage", a "mass global outage and major impact to services", "carnage", "cataclysmic", "global chaos", the "patchpocalypse", "digital catastrophe", "the biggest cyber incident in history", "one of the largest glitches in the Matrix", "massive disruptions", "a complete nightmare … the ramifications to this outage are going to be massive", "incredibly serious, detrimental and possibly life-threatening situation" ... OK OK we get the picture.

In my opinion, information technology, risk and security, cybersecurity and incident response professionals (leaders especially) ought to appreciate what's really happening here, rising above the hubbub. We should remain calm, confidently offering clear, competent guidance and rational direction. 

That's hard, though, because we too are human beings. We bleed. Allegedly.

At the same time, a cool, calm, confident, considered and unemotional response to a major incident can come across as cold, heartless or ignorant to those who are pumped up on adrenaline, perhaps teetering on the edge of panic. It's a no-win emotionally-charged situation ... but if we don't resist, there's a remote risk of the situation running away due to the positive feedback, precipitating something even worse. Conversely, downplaying or supressing the incident entirely would also be risky in slowing or halting the response.

I'm disappointed but not surprised at the number of armchair experts pontificating on 'the real cause' as if there is just one, some quick to point their fingers at Crowdstrike, Microsoft, Crowdstrike customers, the IT industry, IT QA and other professionals (including us infosec wonks) as if blaming anyone achieves anything except perhaps vent a little steam (and that's OK).

Meanwhile, there's an incident to resolve, systems to rebuild and secure, business processes to recover, an emotional swamp to drain.

Once that's done, the post-incident review and wash-up will be fascinating. Not just yet though, please. Let's catch our breath.

Popular posts from this blog

Pragmatic ISMS implementation guide (FREE!)

Image
Early this morning ( very  early!) I remotely attended an ISO/IEC JTC 1/SC 27/WG 1 editing meeting in London discussing the planned revision of ISO/IEC 27003:2017 . Overall, the meeting was very productive in that we got through a  long  list of expert comments on the preliminary draft standard, debated the objectives of the project and the standard and reached consensus on most points. In summary: 27003 is to be revised to align with the current 2022 releases of ISO/IEC 27001 , 27002 and 27005 : These changes are  mostly  minor aside from the new section 6.3 on ISMS changes.
Read more

Two dozen information risks that ISO forgot

Image
Selecting the wrong controls - controls that are inappropriate, ineffective, too costly, impracticable, fragile, unnecessary, counterproductive or whatever, often as a result of blind faith in fads and fashions of the day and FOMO e.g. MFA, AI, cyber Failing to select the right controls - controls that are ideal for the particular situation, both now and in perpetuity, for whatever reason - mostly ignorance and prejudice Selecting and implementing controls at the wrong time or in the wrong way (where 'wrong' includes ineffective, inappropriate, sub-optimal e.g. bolting on controls rather than designing and building them in) Inept and inaccurate identification, analysis and quantification of risk, including reliance on p oor quality (incomplete, inaccurate, out of date, misleading, unreliable ...) information about actual risks, particularly subtle and emerging risks plus those involving deliberate concealment and misdirection e.g. fraud, misinformation, disinformation, propagan
Read more

ISMS internal audit priorities

Image
A thread on the ISO27k Forum sparked my imagination over coffee this morning. Hope had previously asked for assistance with an ISO/IEC 27001:2022 audit plan.  Bhushan offered a lengthy and generally sound response explaining how to use a spreadsheet with tabs to plan and record the audit work performed on 100% of the main body clauses and 50% of the 93 Annex A controls, day-by-day. That's OK ... except it wasn't entirely clear that he was interpreting and elaborating on the standard's actual requirements. ISO/IEC 27001 does not explicitly require, for example, that (as Bhushan stated) "ALL the management system clauses from 4 to 10 AND their sub-clauses need to be listed and audited" in an ISMS internal audit, although evidently he interprets it in that way. In clause 9.2.1, the standard states a requirement for internal audits to provide information on whether the ISMS conforms to the organization’s own requirements for the ISMS plus the requirements of the stan
Read more