Tag Archives: Microsoft

Information Security Best Practices

What is more important – patient safety or hospital IT?

What is more important – patient safety or the health of the enterprise hospital Windows network?  What is more important – writing secure code or installing an anti-virus?

A threat analysis was performed on a medical device used in intensive care units.  The threat analysis used the PTA (Practical threat analysis) methodology.

Our analysis considered threats to three assets: medical device availability, the hospital enterprise network and patient confidentiality/HIPAA compliance. Following the threat analysis, a prioritized plan of security countermeasures was built and implemented including the issue of propagation of viruses and malware into the hospital network (See Section III below).

Installing anti-virus software on a medical device is less effective than implementing other security countermeasures that mitigate more severe threats – ePHI leakage, software defects and USB access.

A novel benefit of our approach is derived by providing the analytical results as a standard threat model database, which can be used by medical device vendors and customers to model changes in risk profile as technology and operating environment evolve. The threat modelling software can be downloaded here.

Continue reading

Tell your friends and colleagues about us. Thanks!
Share this
dilbert Data Security

3 things a medical device vendor must do for security incident response

You are VP R&D or CEO or regulatory and compliance officer at a medical device company.

Your medical devices measure something (blood sugar, urine analysis, facial anomalies, you name it…). The medical device interfaces to a mobile app that provides a User Interface and transfers patient data to a cloud application using RESTful services over HTTPS.

Sound familiar?

The Medical device-Mobile app-Cloud storage triad is a common architecture today for many diagnostic, personal well-being and remote patient monitoring indications.

We have numerous clients with the Medical device-Mobile app-Cloud storage system architecture and we help them address 4 key security issue –

  1. How to ensure that personal data and user authentication data is not stolen from the mobile medical app,
  2. How to ensure that the mobile medical app is not used as an attack pivot to attack other medical device users and cloud servers,
  3. How to comply with the HIPAA Security Rule and ensure that health data transferred to the cloud is not breached by attackers who are more than interested in trafficking in your users’ personal health data,
  4. How to execute effective security incident response and remediation – its a HIPAA standard but above all – a basic tenet for information security management.

How effective is your security incident response?

The recent SANS Survey on Security Incident Response covers the challenges faced by incident response teams today—the types of attacks they detect, what security countermeasures they’ve deployed, and their perceived effectiveness and obstacles to incident handling.

Perceived effectiveness is a good way of putting it – because the SANS Survey on Security Incident Response report has some weaknesses.

First – the survey that is dominated by large companies: over 50% of the respondents work for companies with more than 5,000 employees and fully 26% work for companies with more than 20,000 employees.    Small companies with less than 100 employees – which cover almost all medical device companies are underrepresented in the data.

Second – the SANS survey attempts, unsuccessfully, to reconcile reports by the companies they interviewed that they respond and remediate  incidents within 24 hours(!) with reports by the PCI (Payment Card Industry) DSS (Data security standard) Association that retail merchants take over 6 months to respond.       This gap is difficult to understand – although it suggests considerable variance in the way companies define incident response and perhaps a good deal of wishful thinking, back-patting and CYA.

Since most medical device companies have less than 100 employees – it is unclear if the SANS findings (which are skewed to large IT security and compliance organizations) are in fact relevant at all to a medical device industry that is moving rapidly to the medical device-App-Cloud paradigm.

3 things a medical device vendor must have for effective incident response

  1. Establish an IRT.  (Contact us and we will be happy to help you set up an IRT and train them on effective procedure and tools).  Make sure that the IRT trains and conducts simulations every 3-6 months and above all make sure that someone is home to answer the call when it comes.
  2. Lead from the front. Ensure that the head of IRT reports to the CEO.   In security incident response, management needs to up front and not lead from behind.
  3. Detect in real time. Our key concern is cloud server security.    Our recommendation is to install OSSEC on your cloud servers. OSSEC sends alerts to a central server where analysis and notification can occur even if the medical device cloud server goes down or is compromised.
Tell your friends and colleagues about us. Thanks!
Share this
skin mounted medical devices

Shock therapy for medical device malware

Israel has over 700 medical device vendors.  Sometimes it seems like half of them are attaching to the cloud and the other are developing mobile apps for all kinds of crazy, innovative applications like Healthy.io ( Visual Input Turned Into Powerful Medical Insight – translation: an app that lets you do urine analysis using your smart phone).

But – let’s not forget that many Medical devices  such as bedside monitors, MRI, nuclear medicine and  catheterization devices all reside on today’s hospital enterprise network.

An enterprise hospital network is a dangerous place.

Medical devices based on Microsoft Windows  can be extremely vulnerable to attack from hackers and malware who penetrate the hospital network and exploit typical vulnerabilities such as default passwords.

More importantly – medical devices that are attached to a hospital network are a significant threat to the hospital network itself since they may propagate malware back into the network.

While a thorough software security assessment of the medical device and appropriate hardening of the operating system and user-space code is the best way to secure a medical device in a hostile hospital network – this is not usually an option for the hospital once the medical device is installed.

Taking a page out of side-channel attacks and using the technique to detect malware, University of Michigan researchers have developed WattsUpDoc, a system designed to detect malware on medical devices by noting small changes in their power consumption.

The researchers say the technology could give hospitals a quick way to identify medical devices with significant vulnerabilities.

The researchers tested WattsUpDoc on an industrial-control workstation and on a compounder, which is used to mix drugs.

The malware detector first learned the devices’ normal power-consumption patterns. Then it tested machines that had been intentionally infected with malware. The system was able to detect abnormal activity more than 94 percent of the time when it had been trained to recognize the malware, and up to 91 percent of the time with previously unknown malware. The researchers say the technology could alert hospital IT administrators that something is wrong, even if the exact virus is never identified.

For the full article see WattsUpDoc

 

Tell your friends and colleagues about us. Thanks!
Share this
safeguard your head office small business

4 steps to small business security

Software Associates specializes in security and compliance for biomed.  Many of our biomed clients are small 3-10 person startups working out of a small office and not having neither the IT budget nor the IT best practices to take care of their own network.

According to the latest statistics from the FBI in their annual Uniform Crime Report, one burglary occurs in the U.S. every 14.4 seconds. As bad as it is to be the victim of a burglary, when you have a home office or small business, the effects can bring your operation to a standstill as you try to reorganize your affairs.

Here are four things you can do to protect your small business systems:

1. Physical security – install an alarm system

Adding an alarm system is an effective way to protect your office from a break-in.  How do you find a reputable service provider for a security system for your home office/small business office?

According to SecurityCompanies.com, a comparison shopping resource for alarm systems, there are over 5,000 home security providers in the U.S. market. That’s a lot – and you will need to do a little research and preparation before you start.

Try Google Local – a Google search for alarm systems will usually pop-up a number of providers in your neighborhood with their phone numbers.

After you have a list of 3 home security providers – prepare a checklist before making the calls.  When you call a home security provider you should get answers to these 6 questions:

  • Do you want a hard-wired system or a wireless one?
  • Do you need professional monitoring or would you prefer a sensor-activated system?
  • How big is your home?
  • Do you want advanced features like home automation?
  • Do you need remote access?
  • Will you be installing security cameras as well?

After getting satisfactory answers  – ask for references (recent ones) and guaranteed service levels – if the alarm goes off when you’re on vacation, what  are your options?

2.  Network security – being a good neighbor and assuring your bandwidth

Working on open  wireless network enables other people to jack in.

This has an upside and downside.

The upside of an open wireless router is that its good neighbor policy.  If a passers-by asked you for a glass of water, you would gladly offer them on.   The risk of having sensitive business information stolen or other private information compromised from your home office/small business office network by a casual surfer is practically zero – there are far more interesting targets for drive-by attacks than your small office.

The downside of an open router is assuring bandwidth.  Guests  and neighbors can dramatically slow down your Internet connection. If bandwidth and fast response time is really important to you –  protect your wireless network with a personal password and share it selectively with friends and colleagues.

Do you regularly have clients over, or other guests, who need access to your Internet connection? Set up a separate network for guests, protecting it with a unique password that you can share with guests.

3.  Access security – protecting passwords

With so many online services requiring you to enter strong passwords – it is hard to remember the passwords to your own network and small office server.   Having said that – the last thing you want is to use the same Google password and/or Facebook password for your small business.  That is a really bad idea because if someone hacks your office password – their first attack will be on your Google and Facebook services.

You can try a password generator program to generate unique passwords that are nearly impossible to hack. Top-rated programs include – KeePass, Sxipper and RoboForm & Data Vault.

Another equally good option is to use phonetic passwords that you can easily remember with combinations of letters and numbers – like Xcntu8B4F6g (Accentuate before fixing)

4. Data security –  develop and implement a backup protocol

How often do you backup your files? Once a day? Weekly or monthly?

Having your computer stolen isn’t your only risk.

While modern hardware is very reliable, it’s  not perfect and even the most expensive, dependable computers can crash without any warning.  Even a faulty motherboard can cause disk corruption.

To protect yourself from the panic and anxiety of losing your work, make a plan to backup your work at the end of each work day. Save files to a free cloud-based storage system, like DropBox, or use a removable hard drive. If using a removable hard drive, be sure to store it in a different area of your home, out of the office, to prevent theft. If any harm should come to your computer in a fire or other natural disaster, you will want your hard drive to be stored in a separate location that is out of harm’s way.

Tell your friends and colleagues about us. Thanks!
Share this

The Israeli credit card breach

There are 5 reasons why credit cards are stolen in Israel. None have to do with terror; 4 reasons are cultural and the 5th is everyone’s problem: “confusing compliance with security“.

I  could write a book on mismanagement of data governance and compliance, data security, web server security, web application software security.

In 2003, I got turned on to the notion of using extrusion prevention to prevent data loss. I had the privilege to work with some of the pioneers in data loss prevention and over a period of over 5 years, I evangelized, sold, marketed, implemented and supported data loss prevention solutions in Israel and Europe. In the course of that time, I made thousands of phone calls, met hundreds of prospects and sold a dozen systems.  I  developed a unique perspective to the data security space working with both vendors and C-level decision makers in a wide variety of verticals from financial services to diamonds and telecommunications.

There is no need to state the obvious common denominators between Israeli companies and their US counterparts who have suffered the ignominy of a large scale credit card data breach: Closing the barn doors after the horses have fled, thinking it won’t happen to them, relying on their Checkpoint firewall to prevent data breaches, erroneously calling an anti-virus threat management, believing their IT outsourcing provider and equating the counting of compliance check list items with effective data security.

In this essay, I will try and enumerate what I believe are the key contributing factors behind the insecurity of most Israeli businesses.  Most are inherently cultural to Israel although the last factor (PCI DSS 2.0) is everyone’s problem.

Letting your piss go to your head

The first factor is cultural. It’s called in Hebrew  עלה לו השתן לראש.  It’s hard to translate this exactly – but a literal translation is “letting your piss go to your head”.   Arguably, this may be true for many senior executives, especially those on Wall Street who run billion dollar financial service businesses.

The difference is that in Israel, a colonel who served in the Israeli Air Force and then retired at age 45 on a full military pension to work as a VP in a publicly-held Israeli company that does $50M worth of business has more piss up his head then the CEO of IBM.  You are more likely to ascend bodily into heaven than to convince this person to be a security leader, implement robust data governance in his organization and implement strong data security countermeasures. There are many jokes about this in Israel. The one I like the most goes like this: “Why not have sex under an open window in Israel? Because, someone will leap through the window and tell you – move aside, I’ll show you how it’s done“.  As far as I can tell, this is also the root cause for Israeli politicians like Ehud Barak, Bibi and Tzipi Livni who believe that they know what is best for the Palestinians.  (Letting your success get the best of you is gender-neutral).

The Checkpoint syndrome

The second factor is also cultural. I would label it the Checkpoint syndrome. I believe that the Americans call it “NIH – Not invented here”.   It is literally almost impossible to sell an Israeli CIO on the notion of innovative data loss prevention technologies when Checkpoint hasn’t really done much in that space (granted they introduced a DLP software blade for their firewall product in 2010, 7 years after Fidelis, Vontu and Verdasys already had working technology). Port Authority, later acquired by Websense, did indeed have some success in Israel – burning $60M in VC funding and selling about 30 systems in Israel due to a related syndrome that I shall call the 8200 syndrome – which is sort of an Israeli coolness factor – like Roy Hargrove and RH Factor playing funk. A related illness, which is at epidemic levels in Israel, is the Microsoft Monoculture.  While Microsoft has correctly pigeonholed data security into data governance  the main focus of Microsoft operating systems is access control and when key system management focus is on access control then it becomes difficult for system managers to properly assess the risk from trusted insider threats – insiders who violate security policy simply because they can. עלק אבטחה.

Retaliation instead of mediation

The third factor is political.

Saber rattling is a political gesture and retaliation is not a substitute for proactive threat analysis and premeditated risk mediation.

My friend Maryellen Evans sent me this clip from the Financial Times: Israel seeks revenge for hacking

The Israeli government has threatened to retaliate against the hacker who last week published the credit card details of thousands of Israelis, with one senior official comparing the cyberattack to a “terrorist operation”. Danny Ayalon, the deputy foreign minister, warned that the attack represented “a breach of sovereignty comparable to a terrorist operation, and must be treated as such”. He added: “Israel has active capabilities for striking at those who are trying to harm it, and no agency or hacker will be immune from retaliatory action.”

Oh. I’m getting shivers at the thought of Israeli generals led by Ehud Barak retaliating against hackers.

There are 3 fundamental flaws behind this thinking (assuming someone is actually thinking like this, which may be assuming too much).

  1. Due to the asymmetrical nature of hacking, there is neither payback, nor deterrence value in threatening to send a drone aircraft to shoot a hacker in Mexico/Saudia/Albania/etc….
  2. Israeli leaders have  proven track records of threatening but not delivering on their promises (the disengagement from Gaza is a case in point) and then caving in populistic, media-driven, Jewsh-mother driven demands to trade terrorists with blood on their hands for Israelis who were drug dealing (see Elchanan Tannenbaum) or soldiers who failed in their duty (see Gilad Shalit is not a hero). As a result, Israeli leadership credibility in this respect is rather low.
  3. Threatening with retaliation is a low-cost, political do-nothing alternative to a fundamental threat analysis of the vulnerabilities in information systems, online sites and networks and careful, open and thorough implementation of strong data security countermeasures – such as locking down Web servers, outlawing Windows and securing message queue infrastructures used for B2B connectivity.

Legislation without enforcement

Several years ago, I had an interesting sales call with the CSO of Clalit, the big Israeli HMO.   I made my pitch for data loss prevention and tied it into the ability of DLP to deliver real-time monitoring and visibility and assure PHI privacy compliance. He laughed at me and said: “Listen, Danny – Israeli has a dozen privacy regulations on the books, all are relevant to PHI, but no one is serious about compliance, so we do what we think we need to do in the limitations of our budget and it is what it is.

The problem of legislation without enforcement is endemic in Israel from traffic safety to women’s rights to environmental protection: Israel is a country with more legislation and commissions of inquiry than  enforcement.   Perhaps,  a weak system of enforcement and abiding the law may be  a vestige of defense mechanisms developed while living in the Diaspora.   Certainly – the Eastern European Jews who founded Israel did not come from a background of law, order and compliance.  They came from a background of revolution and change.

Compliance  without security

Finally, we come to PCI DSS 2.0.  I have written extensively on the drawbacks of PCI DSS and here and here (The Tao of GRC) and suggest specific ways of getting credit card security right.

Perhaps the time has come to perform a vulnerability assessment of the standard itself.

In very simple terms, the biggest vulnerability of PCI DSS is that it’s about 10 years behind the curve.  When people in the PCI DSS Security Council in Europe confess to never having heard of DLP (Data loss prevention) and when the standard places an obsessive emphasis on anti-virus, you know you’re still in Kansas.

Speaking with a senior representative of PCI DSS Security Council in Europe last year, I posed some of these questions and he replied that the situation with merchants is so bad that PCI DSS is “better than nothing”.

That is pathetic isn’t it?

Perhaps we would all be better off taking the day off and hoovering our flats instead of trying to reeducate management, fix political systems, improve our data security and prevent credit card breaches.

It would certainly be cheaper.

 

 

 

Tell your friends and colleagues about us. Thanks!
Share this

The top 10 mistakes made by Linux developers

My colleague, Dr. Joel Isaacson talks about the top 10 mistakes made by Linux developers. It’s a great article and great read from one of the top embedded Linux programmers in the world.

The Little Engine That Could

Copyright 2004 Joel Isaacson. This work is licensed under the Creative Commons Attribution License.

I  try to explain what are the top 10 mistakes made by Linux developers as I see it. I’m aware that one person’s mistake is another person’s best practice. My comments are therefore subjective.

I will use an embedded Linux device, the WRT54GS, a wireless router as an illustration of an embedded Linux device.An interesting article about this device can be found in: http://www.pbs.org/cringely/pulpit/pulpit20040527.html.

“The Little Engine That Could” How Linux is Inadvertently Poised to Remake the Telephone and Internet Markets – By Robert X. Cringely

So what are the top 10 mistakes made by Linux developers?

10 – Pick a vendor.
9 – Then pick a platform.
8 – We are not in Kansas anymore.

Support Issues

10 – Pick a Vendor

  • In my experience picking a large foreign company for support is not the best way to go for various reasons.
  • More about this later.

Continue reading

Tell your friends and colleagues about us. Thanks!
Share this

Securing Web servers with SSL

I’ve been recently writing about why Microsoft Windows and the Microsoft monoculture in general  is a bad idea for medical device vendors – see my essays on Windows vulnerabilities and medical devices here, here and here.

It is now time to slaughter one more sacred cow: SSL.

One of the most prevalent misconceptions with vendors in the medical device and healthcare space regards the role of SSL and TLS in protecting patient information.  When faced with a requirement by a government or hospital customer for compliance to one of the US privacy and security standards, a vendor usually reacts with the CEO asking his CTO to look into “solutions”. The CTO’s answer usually goes  like this:

I did some research. Apparently to be FIPS  (or HIPAA, or …) compliant we should use TLS and not SSL. I think that configuring the browser to be FIPS  (or HIPAA, or …) compliant may take a little work.

Action items are given out to the technical team, they usually look like this:

Joe – You establish a secure web site

Jack – Make sure all the addresses on the workstation point to https instead of http

Jack and Joanne – Compile a new version of the Servers and workstation to work properly on the new site.

Jack and Jill – Do what ever needs to be done so that the web services work on the new site.

That’s all – No other changes need to be done to the application.

Oooh.  I just love that last sentence – “No other changes need to be done to the application”.  What about patching Web servers and the Windows operating systems? What about application software vulnerabilities?  What about message queue vulnerabilities ? What about trusted insiders, contractors and business partners who have access to the application software?

There are multiple attack vectors from the perspective of FIPS and HIPAA compliance and PHI data security.  The following schematic gives you an idea of how an attacker can steal PHI, figure using any combination of no less than 15 attack vectors to abuse and steal PHI:

HIPAA security in the cloud

There are potential data security vulnerabilities in the client layer, transmission layer, platform layer (Operating system) and cloud services (Amazon AWS for example).

So where does SSL fit in? Well, we know that the vulnerabilities for a PHI data breach can not only happen inside any layer but in particular there are vulnerabilities in the system interfaces between layers. That means between server layers and client-server interfaces.  SSL  Quoting from the Apache Tomcat 6.0 SSL Configuration HOW-TO:

SSL, or Secure Socket Layer, is a technology which allows web browsers and web servers to communicate over a secured connection. This means that the data being sent is encrypted by one side, transmitted, then decrypted by the other side before processing. This is a two-way process, meaning that both the server AND the browser encrypt all traffic before sending out data.

Another important aspect of the SSL protocol is Authentication. This means that during your initial attempt to communicate with a web server over a secure connection, that server will present your web browser with a set of credentials, in the form of a “Certificate”, as proof the site is who and what it claims to be. In certain cases, the server may also request a Certificate from your web browser, asking for proof that you are who you claim to be. This is known as “Client Authentication,” although in practice this is used more for business-to-business (B2B) transactions than with individual users. Most SSL-enabled web servers do not request Client Authentication.

In plain English, SSL is good for protecting credentials transmitted between the browser and web server during the login process from eavesdropping attacks.  SSL may still be vulnerable to man in the middle attacks by malware that piggybacks on the plain text browser requests and responses before they are encrypted. Similarly, SSL may be vulnerable to cross-site scripting attacks like the Paypal XSS vulnerability discovered in 2008 that would allow hackers to carry out attacks, add their own content to the site and steal credentials from users.

SSL is a key component in a secure login process, but as a security countermeasure for application software vulnerabilities, endpoint vulnerabilities, removable devices, mobile devices and data security attacks by employees,  servers and endpoints, it is worse than worthless because it sucks the medical device/healthcare vendor into a false feeling of security.

SSL does NOT make a medical device/healthcare Website secure. The SSL lock symbol in the  browser navigation window just means that data in motion between a browser client and Web server is encrypted.   If you can attack the endpoint or the server – the data is not protected. Quoting Gene Spafford ( I think this quote has been used for years but it’s still a good one)

“Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit card information from someone living in a cardboard box to someone living on a park bench.”
Gene Spafford Ph.D. Purdue, Professor of Computer Sciences and Director of CERIAS

This is all fine and dandy, but  recall our conversation from the CTO giving action items to his team to “establish a secure web site” as if it was point and click on a Microsoft Office file. The team may discover that even though SSL is not a very good data security countermeasure (albeit required by FIPS and HIPAA), it may not be that easy to implement, let alone implement well.

It’s no wonder that so many web servers are misconfigured by the clueless being led by other clueless people who never read the original documentation and were all feeding off google searches for tutorials. Yikes!

Most people don’t bother reading the software manuals and google for advice looking for things like “Tomcat SSL configuration tutorial“.  Jack, and Jill and Joanne in our example above, may discover themselves wandering in an  abundance of incorrect,incomplete and misleading information in cyberspace, which is mixture of experts who assume everyone  knows how to setup secure AJP forwarding and Tomcat security constraints and a preponderance of newbies who know nothing (or a little bit, which is worse than nothing).

Working with a client in the clinical trial space, I realized that the first and perhaps biggest problem is a lack of decent documentation, so I wrote SSL and Certificate HOW TO – Apache 2.2 and Tomcat 6, Ubuntu which I hope will be my modest contribution (along with this blog) to dispelling some of the confusion and misconceptions and helping medical device and healthcare vendors implement secure Web applications. No promises – but at least I try to do my bit for the community.

Tell your friends and colleagues about us. Thanks!
Share this

The connection between application performance and security in the cloud

I met with Avner Algom last week in his office in Herzliya. Avner is the director of the Israeli Cloud and Grid Technology Consortium – IGT – The IGT is a non-profit organization of leading industry companies, vendors, ISVs, customers, VCs and academia, focused on knowledge sharing and networking for developing Cloud computing/SaaS, Virtualization and SmartGrid solutions. It is open, independent and vendor-neutral.

It is significant that discussions of cloud security and performance focus almost exclusively on infrastructure issues such as virtualization or procedural issues such as infrastructure compliance with various security standards and frameworks.

I remarked to Avner in the course of our chat, that there is a close correlation between performance and security issues for Web applications running in the cloud.  Avner  asked me how I came to that conclusion.

Here is why cloud performance and cloud security have common issues.

Virtually all applications deployed in the cloud are either Web-based applications or smartphone apps for Android or IOS that use http/https as their application transport.

The current rich Web 2.0 application model is broken and it has nothing to do with the  serious and fundamental issues with Microsoft monoculture, Windows operating systems vulnerabilities and Internet Explorer non-compliance with IETF  standards.

It will not help if you use Ruby on Rails or CakePHP or Zend Framework either. The debate between the Ruby on Rails, ASP.NET and PHP camps is mildly interesting but irrelevant from a cloud security and performance perspective.

A deeper look at Web applications reveals that the current rich Web 2.0 application development and execution model suffers from a broken architecture that cannot be fixed by tweaking languages.

Further examination shows that data typing, message passing, redundant code, data and multiple tier issues that are security vulnerabilities for Web applications in the cloud are also root causes of application performance issues and latency that result in a poor user experience and high cost of operation for the application operator. Note that in a utility model where you pay for CPU cycles,  you pay more for inefficient applications. That is the dark side of the externally vivacious cloud service model.

The attached presentation examines some of the root causes of the currently broken Web 2.0 application development and execution model and shows that the same security vulnerabilities born out of Web 2.0 client/server architecture result in 10x poorer performance than a traditional client-server model based on stateful, TCP unicast socket communications.

See Web application security in the cloud

Tell your friends and colleagues about us. Thanks!
Share this

Why outlawing Windows from embedded medical devices is a good idea

In a previous post The Microsoft Monoculture as a threat to national security, I suggested that the FDA might consider banning Windows as an operating system platform for medical devices and their accompanying information management systems.

One of my readers took umbrage at the notion of legislating one monoculture (Microsoft) with another (Linux) and how the Linux geeks are hooked on the CLI just like Windows users are hooked on a GUI.

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

One of the biggest threats to medical devices in hospitals is the widespread use of USB flash disk drives and Windows notebooks to update medical device software. With the infamous auto-run feature on Microsoft USB drives – flash memory is an easy attack vector for propagating malware via Windows based medical devices into a hospital network. This is one (and not the only) reason, why I am campaigning against use of Windows in medical devices.

This  has nothing to do with the CLI or GUI of the operating system and personal preferences for a user interface.

This has everything to do with manufacturing 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.

It might be possible to mandate a complex set of software security requirements instead of outlawing Windows in embedded medical devices as a more politically-correct but far more costly alternative for the the FDA and the US taxpayer.

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 decrease since the FDA would need less Windows expertise for audits and the threat surface they would have to cover for critical events would be smaller.

Tell your friends and colleagues about us. Thanks!
Share this

Microsoft gives source code to Chinese government

Sold down the river. A phrase meaning to be betrayed by another. Originated during the slave trade in America. Selling a slave “down the river” would uproot the slave from their from spouses, children, parents, siblings and friends. For example:

“I can’t believe that Microsoft gave their source code to the Chinese in a pathetic attempt to get them to buy more MS Office licenses.  Boy-were we sold down the river!”

In the euphemistically worded press release Microsoft and China Announce Government Security Program Agreement, we learn that China joins over 30 other countries as recipients of  access to Windows operating system source code. I bet all that yummy, ecumenical, international  cooperation gave someone at the BSA warm and fuzzy feelings. Either that or Ballmer told them to keep quiet.

Hold on.  That announcement was in 2003.

Fast forward to 2011.  Searching on Google for “chinese attacks on US on US” yields 57 million hits. After the RSA breach, China is linked to attacks on US Defense contractors and US Congresswoman condemns attack on change.org

In 2011, Steve Ballmer is saying that  China is doing 5 percent of the revenue that it should be doing because  of pirated software. See the article  Microsoft’s Chinese revenue 5% of what it could be

The BSA (Business Software Alliance), an industry lobby group, has some interesting figures to fuel Ballmer’s comments:

  • Four of five software programs installed on PCs are pirated
  • This amounts to “commercial theft” of close to $8 billion a year
  • Piracy in 2010 cost the software industry $59 billion in revenue

I would not take BSA numbers at face value. The BSA estimates are guesses multiplied several times without providing any independent empirical data. They start off by assuming that each unit of copied software represents a direct loss of sale for Microsoft, a false assertion.

If it were true, then the demand for software would be independent of price and perfectly inelastic.

A drop in price usually results in an increase in the quantity demanded by consumers. That’s called price elasticity of demand. The demand for a product becomes inelastic when the demand doesn’t change with price. A product with no competing alternative is generally inelastic. Demand for a unique antibiotic, for example is highly inelastic. A patient will pay any price to buy the only drug that will kill their infection.

If software demand was perfectly inelastic, then everyone would pay in order to avoid the BSA enforcement tax. The rate of software piracy would be 0. Since piracy rate is non-zero, that proves that the original assertion is false. (Argument courtesy of the Wikipedia article on price elasticity of demand ).

See my essay on the economics of software piracy.

Back to Microsoft and their highly ineffective strategy to sell more licenses in China.

Clearly, Microsoft’s strategy to induce the Chinese to buy more Microsoft software licenses by sharing Windows source code has not gotten any traction in the past 8 years.

Au contraire, from a software engineering perspective, it is a fair assumption that having access to Windows source code has made it easier for Chinese cyber attackers to write attack code to penetrate and compromise US defense contractors, critical infrastructure and activist groups like change.org – who all still use  highly vulnerable Windows monoculture products.

This is where we need to explain to the people who drink Microsoft Koolade about the difference between “controlled access” to source code with countries who are  potential enemies with the notion of Open source – where everyone and anyone can look at the source code – where lots of eyeballs help the developers make the operating system more robust.

From a security perspective, the number of eyeballs looking at Linux make it more secure than Windows.

But more significantly, from a commercial perspective, note how abortive Microsoft strategy really is in this case study from  the Harvard Business School on Red Flag Software.

In 2005, just five years after its formal launch, Beijing-based Red Flag Software was the world’s second-largest distributor of the Linux operating system and was expecting its first annual profit. On a unit basis, Red Flag led the world in desktops (PCs) shipped with Linux and was No. 4 in installed servers. On a revenue basis, Red Flag was fourth overall. Within China, Red Flag held just over half of the Linux market and ran key applications for the postal system, large state-owned enterprises, and more than a million PCs. The Chinese government supported Linux as an alternative to Microsoft’s Windows operating system to avoid royalty payments to foreign firms and dependence on foreign technology.

Since the Chinese government have been open about their support of Linux for years, it certainly makes the release of Windows source code look like a very bad idea.  I would hope that this does not go unnoticed in US Congress.

Tell your friends and colleagues about us. Thanks!
Share this