Microsoft Monoculture as a Threat to National Security

Friday, June 10, 2011

Danny Lieberman

959779642e6e758563e80b5d83150a9f

This is probably a topic for a much longer essay, but after two design reviews this week with medical device vendor clients on software security issues, I decided to put some thoughts in a blog post.

Almost 8 years ago, Dan Geer, Rebecca Bace, Peter Gutmann, Perry Metzger, Charles Pfleeger, John Quarterman and Bruce Schneier wrote a report titled: CyberInsecurity: The Cost of Monopoly How the Dominance of Microsoft’s Products Poses a Risk to Security.

The report from a stellar cast of information security experts and thought leaders shows that the complexity and dominance of Microsoft’s Windows operating system in US Federal agencies makes the US government prone to cyber attack – a national security threat.

This was in September 2003.

Now fast forward to a congressional hearing on May 25, 2011 by the Committee on Oversight and Government Reform on ”Cybersecurity: Assessing the Immediate Threat to the United States Listen to the YouTube video – you will note the concern on potential damage to citizens due to virus infecting government PCs breaching personal information.

So the US government is still running Microsoft Windows and is still vulnerable to data security breaches. It seems that the Microsoft lobbying machine has been “successful” over the past 8 years on the Beltway, if you call threats to national security a success.

One of the commonly used canards by Microsoft monoculture groupies is that all operating systems have vulnerabilities and Windows is no better nor worse than Linux or OS/X. If “you” patch properly everything will be hunky-dory. There are a number of reasons why this is fallacious,  to quote the report:

  • Microsoft is a near-monopoly controlling the overwhelming majority of systems. This means that the attack surface is big, on a US national  level.
  • Microsoft has a high level of user-level lock-in; there are strong disincentives to switching operating systems.
  • This inability of consumers to find alternatives to Microsoft products is exacerbated by tight integration between applications and operating systems, and that integration is a long-standing practice.
  • Microsoft’s operating systems are notable for their incredible complexity and complexity is the first enemy of security.
  • The near universal deployment of Microsoft operating systems is highly conducive to cascade failure; these cascades have already been shown to disable critical infrastructure.
  • After a threshold of complexity is exceeded, fixing one flaw will tend to create new flaws; Microsoft has crossed that threshold.
  • Even non-Microsoft systems can and do suffer when Microsoft systems are infected.
  • Security has become a strategic concern at Microsoft but security must not be permitted to become a tool of further monopolization.

As a  medical device security and compliance expert, I am deeply concerned about medical devices that use Windows. If Windows is a threat to national security because it’s used in Federal government offices, Windows is really a bad idea when used in medical devices in hospitals.

I’m concerned about the devices themselves (the FDA classifies Web applications as medical devices also if the indications are medical-related) and the information management systems: the customer support, data collection, analysis management applications that are ubiquitous to networked medical devices.

There are two reasons why the FDA should outlaw Windows in medical devices and their information management systems.

Reason number 1 to ban Windows from medical devices is complexity. We know that the first sin of the 7 deadly sins of software development is making the software complex.  Complexity is the enemy of security because with complex software, there are more design flaws, more software defects and more interfaces where vulnerabilities can arise.

Similar to the history of data security breaches of retail systems, the medical device software industry is (or may soon be) facing a steeply increasing curve of data security and patient safety events due to the Microsoft monoculture.  We are not in Kansas anymore – not credit cards being breached, but entire hospital networks infected by Microsoft Windows viruses and patient monitoring devices that stop working because they got blue screens of death.  

Since 300 million credit cards have been breached, it is a reasonable assumption that your card and mine is out there. The damage to your credit card being breached is minimal.  But, if your child was on a patient monitor that went offline due to a Microsoft Windows virus and a critical condition was not detected in time; it’s the difference between life and death.

The complexity and vulnerabilities of Windows technologies are simply not appropriate in the medical device space when you look at the complexity and weight of the components, the SQL injection vulnerabilities provided courtesy of naive ASP.NET programmers and the ever present threat of Windows viruses and malware propagated  by USB sticks and technician notebooks.

The Microsoft monoculture breeds a generation of programmers that are scared of the command line, unable to comprehend what happens behind the GUI and lured by the visual beauty of the development tools.  When a programmer uses a component and doesn’t know it works (see Visual Studio ) and shleps around a load of piping in his project, then the energies go into implementing a cute GUI instead of thinking about code threats.

This is on a grander scale, a rerun of Microsoft Powerpoint, where you spend 80% of your time in the application’s GUI instead thinking about and then just stating your message.

Reason number 2 to ban Microsoft Windows from medical devices is more subtle and related to systems management.   The Microsoft monoculture has bred a particular kind of thinking and system management best practices based on Windows servers and Windows PCs running in the office.  This IT system management strategy assumes that PCs are just personal devices that someone has to patch and that they will eventually get infected and or breached and or get a BSOD.

Unlike an office, a hospital is a highly heterogeneous and hostile environment. The system management strategy for network medical devices must be different.

Medical device vendors need to assess their software security with the design objective being a device that runs forever and serves the mission of the doctors and patients.

Medical devices are real time embedded systems living on a hospital network. They should be fail safe, not vulnerable to viruses and should not have to rebooted every few days.

Yes – it’s a tall bill and a lot of people will have to learn how to write code in embedded Linux.

But, there is no alternative, if we want to prevent the medical device industry from suffering the ignominy of the credit card industry.

Cross-posted from Israeli Software

Possibly Related Articles:
18214
Network->General
Information Security
Microsoft Data Loss Prevention Operating Systems Attacks National Security Medical Devices
Post Rating I Like this!
7ff7b9daf5a7bb448a822d95d28153a5
JT Edwards Not sure how replacing one Monoculture with another Monoculture is going to make anyone safer. You could argue that Linux is not a Monoculture because of the different flavors of Linux, but I don’t buy that. Is it more secure, yep! Are medical devices a perfect place for Linux, hell yes. Should the FDA regulate what OS can be used on medical devices? Seriously? That one statement destroyed your credibility in this argument. Argue that manufactures and hospitals should demand or only buy Linux enabled devices, but to regulate “which” OS, not sure that is what I want my Tax dollars doing. Now argue that the FDA should create security standards so stringent that Linux is the only game unless MS makes huge changes, sure, but to wholesale ban an OS for an industry in a free market? Yea, not even sure Jobs has the balls to suggest that! Ellison probably does lol

One rant here.. I know you Linux guys LOVE the CLI it makes many of you feel superior to the point and click crowd. You even point to MS using CLI more and more as proof you being right all along! But as you pointed out complexity is one of the enemies of good design. You guys want Linux to be all it can be, it needs to get less complex! And I know we are not talking desktop experience here, but to continue your logic that same hospital with embedded devices using Linux needs to be using Linux servers and desktops! Anyway for that to happen the complexity of Linux has GOT to change! Good lord would it kill someone to figure out how to make the whole Linux driver issues less of a pain!
1307729931
959779642e6e758563e80b5d83150a9f
Danny Lieberman Joel

Tone down your rhetoric.

If you read my post and the article I reference, written by Dan Geer and colleagues, you will see that there some fundamental differences between Microsoft and it's competing operating system platforms.

You are basically saying that "Since Microsoft has an OS and has a monopoly on market, desktop, mind-share and system management practices, therefore Linux also has a monopoly on market, desktop, mind-share and system management practices"

This statement is false from a both a logical and empirical perspective.


The user lock in created by integrating applications with Windows, the complexity of the products and their code and the Microsoft predatory trade practices are diametrically different than Linux and the FOSS movement.

This patently has nothing to do with the CLI.

This has everything to do with writing secure embedded medical devices that must survive in most demanding, heterogeneous and mission critical environment one can imagine - a modern hospital.

I never advocated mandating Linux by law for medical devices.

Your reasoning that it would be more effective to mandate a complex set of software security requirements instead of outlawing Windows in embedded medical devices is far more costly to the the FDA (and indirectly to the taxpayer).

As a matter of fact - regardless of the politics involved (and they are huge...) - if the FDA were to remove Windows from an approved list of embedded medical device operating systems - the costs to the FDA would probably DECREASE since
a. The FDA would need less Windows expertise for audits
b. The threat surface they would have to cover for critical events would be smaller.


In a previous post on my blog http://www.software.co.il/wordpress/2011/06/medical-device-security-in-a-hospital-network/

I specifically related to the complexity issue by suggesting that:

Embedded medical devices should be based in embedded Linux – and not a stock version of Red Hat – but rather built ground up from the latest Linux kernel, with the minimum set of services and software (Qtk etc…) needed to run the application. The software update process should be part of the design – not something bolted on after the implementation.

Developing for embedded Linux is not copy and paste from Windows. It requires expertise to setup the basic infrastructure. But – once that infrastructure is up, the medical device developer and it’s hospital customer can be confident that they are standing on a secure platform and not a house of glass built on a foundation of sand.

For the record - I launched Windows NT in Israel and the first Microsoft ASC - I am intimately familiar with Windows and none of my comments are based on politics but rather software security issues and costs.

Respectfully
Danny
1307818352
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.