Windows users are still rightly upset about the global outage in July 2024 that downed 8.5 million Microsoft devices, grounded air travel and disrupted businesses around the world. Although CrowdStrike’s system-crippling update sparked the outage, Microsoft’s antiquated operating system infrastructure was the tinder that led to a global technological wildfire.
In response, Microsoft hosted a summit with CrowdStrike and other endpoint security companies to discuss ways to better protect critical infrastructure and improve security resiliency. The solutions coming out of it are promising, but a central issue remains: interoperability between Windows and third-party security products.
Issues With Microsoft’s Product Architecture Approach
It’s widely acknowledged – even by Microsoft – that the scale of the July outage was a result of Microsoft’s archaic approach to its product architecture. The target of CrowdStrike’s update was a security product called Falcon that can be deployed on various operating systems, including macOS, ChromeOS, Linux, and Windows.
Only devices running Windows were affected, however, because Windows uniquely allows Falcon and other endpoint security products to interface directly with its kernel – the sensitive part of the operating system that orchestrates interactions between the device’s physical hardware and the software processes running on it. Most endpoint security products for Windows rely on accessing kernel-level data–including Microsoft’s own security product, Defender. The flawed update, however, caused the Windows kernel to go haywire.
Other operating systems do not allow this access because it is a known risk. Apple has long advocated against kernel programming, as has the creator of Linux, Linus Torvalds. Apple and the Linux community took steps years ago to “harden” the kernels in their operating systems. They also developed partnerships with CrowdStrike and other security vendors that do not rely on kernel access, but rather rely on more modern application programming interfaces (APIs).
Microsoft made it a point after the summit that it needs to consider additional security capabilities outside direct kernel access. It could take this effort in one of two directions. It could pursue a collaborative partnership between Microsoft and the security community to harden Microsoft’s operating system in a manner that supports a competitive, innovative marketplace for security products. Or, it could implement “solutions” that boost its own security products by undermining Windows interoperability with competing products.
How Microsoft Can Improve Trust
Which will it be? Microsoft’s lofty summit rhetoric points to the former, but history suggests the latter is more likely in the end. It’s important to note that the summit was positioned as “initial conversations” and “not a decision-making meeting,” as Microsoft put it.
But look at Microsoft’s deeds, not its words: the company has a well-deserved reputation for creating barriers to interoperability that favor its own products, from the browser wars of the late 1990s, to a 2009 agreement with the European Commission (EC) on Windows interoperability with third-party software, to more recent concerns about restrictive interoperability, bundling, and data portability practices relating to its cloud offerings.
If Microsoft is indeed earnest about the collaborative path, it won’t be an easy one to trod. It will require trust among participants, many of whom are direct competitors with each other and with Microsoft. There are also potentially challenging antitrust issues to work through whenever competitors come together in ways that could affect the competitive landscape.
To build this trust, Microsoft still needs to explain why it waited until a crisis to act on the July outage. The company’s claim that the 2009 antitrust agreement with the EC tied its hands is dubious. The plain language of the agreement requires only that Microsoft give third parties “equal footing,” not kernel access to the extent that Falcon had. Unsurprisingly, the EC has rejected Microsoft’s claim.
Perhaps more damning, Microsoft did not exercise its right to withdraw from the agreement in December 2019, and it also made no apparent effort at any point during the 15 years that the agreement has been in force to work.
Microsoft should also act on its claims from the summit that it supports choice and competition in security by committing to a core principle that hardening the Windows kernel must not result in unfair competitive advantages for Defender or other Microsoft products.
This would focus collaboration on achieving better security for Windows users instead of jockeying for competitive advantage – a critical point where the company’s flagship cybersecurity improvement program, the Secure Future Initiative, falls short.
After decades of security failures that have repeatedly compromised multinational organizations and critical government agencies, what Microsoft chooses to do in the months following this summit is a matter of public interest – and the company must treat it as such.
Moving forward, Microsoft should develop and implement its kernel hardening plan in an open and transparent process, with reasonable exceptions to protect sensitive business information and information that could aid attackers.
Image credit: JeanLuclchard / Shutterstock.com