No, EU competition policy was not responsible for global IT chaos II
More excitement as the world cleans up after Friday’s global IT chaos, caused directly by poor CrowdStrike testing processes and marking its software as essential to Windows booting — but indirectly by Microsoft allowing inadequately tested/sandboxed code to run in “kernel” mode on PCs, where it can/did cause a system crash on around 8.5m Windows PCs globally and billions of dollars of insured damage, exposing “the vulnerabilities of a global economy run on a handful of software platforms” [1].
CrowdStrike has published its initial findings on what caused the problem, while this is a good technical account of the Windows issues from a retired Microsoft developer (summary: Microsoft signed a CrowdStrike driver which then loaded untested pseudocode, which caused the system crash):
Microsoft is now claiming it dare not impose more security obligations on such kernel-mode software run by Windows, because its antivirus/security competitors and the European Commission will say this is anticompetitive. This is a poor excuse. But the EC and other regulators could take steps to clarify what OS monopolists can and cannot do for good security reasons, as well as consider whether action is needed under existing or prospective laws. For example, the EC could launch a market investigation under the Digital Markets Act to consider whether the obligations applying to “gatekeeper” operating systems (ie Windows) should be extended in relation to the fairness/contestability of OS security tools [2]. Clearly there should be action under the various cybersecurity directives too.
I just started another project for the European Commission looking across the 8 (!) digital-related laws the EU recently passed, so I look forward to identifying further work for them 😉 But we’ll only avoid further global IT chaos if regulators learn from incidents like this — not least since trivial action by CrowdStrike [3], or security tool market-coordination action by Microsoft, could have avoided it entirely.
Postscript: “As a long-time CTO… It’s clear to me that CrowdStrike should be sued and I suspect that unless Microsoft stops providing kernel access to third parties, many businesses will be increasing the footprint of Apple Mac devices in their corporate estates.”
[1] That’s why important systems should be designed so they are resilient to failure by some nodes, with diversity in key components (e.g. operating systems). And also why security by design is key. Of course, a more competitive operating system market would help — also the goal of EU competition policy 😉
[2] Art. 16(2) allows the EC to use its investigative powers immediately while it talks to the member states about adopting an Art. 16(1) decision to conduct the investigation. Some additional obligations could be adopted using delegated powers (Art. 12) while others might need a legislative update. Meanwhile, the Commission could ask for the assistance of national competition authorities to investigate (Art. 16(5)), perhaps starting with Estonia’s, which hosted the operating system breakout session at last month’s European Competition Network DMA conference. N.B. This meets this Art. 19(1) test, going back to the 2009 Microsoft decision: “In its assessment, the Commission shall take into account any relevant findings of proceedings under Articles 101 and 102 TFEU concerning digital markets as well as any other relevant developments.”
[3] I hear from an impeccable source that three lines of code from CrowdStrike to make use of Microsoft’s Structured Exception Handling would have avoided the problem.
@ian Note that uSoft signed an agreement with the EU. The problem could be avoided if uSoft moved their security code to sandboxed environments, and this could then allow them to require the same of 3rd parties.
Since uSoft *hasn't* done that, they cannot required 3rd parties run in a sandboxed environment.
As someone who has written code both in the kernel, and code moved outside the kernel to a sandboxed environment, I'll say that both are sucky as hell. Just in different ways.
@ian Of course, if uSoft ensured their products used only the same APIs that 3rd parties had access to, that'd probably help with the sandboxed version not sucking as much. (The same goes for Apple for their products, although I will note that Apple has a history of using SPIs for their products, and then turning them into APIs. This results in them being able to test the programming interfaces before finalizing them into something stable enough for 3rd party use.)