Category Archives: Information security

Weekly security lessons learned

We specialize in security and compliance for the health care and bio-med space, helping clients build  security into their products, instead of bolting it on later. There are plenty of challenges to go around and it often seems like you’re trying to drink from a fire-hose.  Lots of water,  a few drops into your mouth, getting thoroughly wet and having lots of fun!

This week, we had oodles of interesting problems to solve but the 64K question is:

How many of the solutions will we remember next week this time?

I decided to start writing a weekly lessons_learned file. I’m maintaining it in my own git repository. If I go anywhere with some of these daily lessons, I’ll move it to github. Here are a few lessons I learned this week.

  1. A little bit of introspection can go a long way – or how not to make changes in a complex Web application and reduce the probability of introducing new bugs and new vulnerabilities.
  2. Do not take Unicode for granted
  3. Making MVC frameworks more secure with stored procedures and views
  4. Denormalization is not a bad thing especially if it keeps the code simple
  5. Data validation: replacing declarative statements with Javascript code

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

A strategy for combating cyber terror

Instead of getting some real work done this morning,  I started collating some thoughts on cyber security strategy. I guess it’s a lot easier to think about strategies than to fix buggy, risky code.

For most people – there are two worlds, the cyberspace world and the physical, people-populated world.

This dichotomy of two separate spaces has deeply influenced everything we do with information security.

There are corporate physical security people that handle doors and locks and phones and corporate information security people that handle data and network security. The two people and their staffs often do not report to the same manager.

On a government level, we have intelligence, military and police forces and cyber warfare and cyber crime groups inside each organization that may or may not be part of an integrated effort in the war on crime, drugs and terror.

It is a curious facet of our modern, technology-driven life that the adoption of a new technology is inversely proportional to the amount of publicity given to the technology.   Who talks about plain old phones?  Who talks about email as killer application? No one.

People still tend to discuss the Internet and Facebook and their own social/work lives as if they are separate entities.

Using this model of gradated technology adoption, we can see that social media has not mainstreamed to the point where it as much a part of our life as a phone.   When as many people use Facebook or other social media to the same extent that they use a phone, there will be little to talk about the “phenomenon of social media”.

However, there are already at least two large communities of people where the Internet and social media has already become part of their day-to-day work life.

These two notable examples are the software developer and hacker communities.  There is no cyber space and physical space, second life and real life; there is only the software and the communications channels that are a means to an end.

If physical, people and cyber space is a continuum, there is no reason to build a security portfolio that treats cyber space and physical/people space separately.

People attack other people and their assets using multiple channels: physical, personal, removable device, email, web, wireless and cellular. Is cyberstalking less severe than a man following women home from the gym?

1) The first part of my proposed cyber security strategy is to adopt a single continuum  of threat vectors,  people and  communications channels, whatever and wherever they are.

2)  The second part of my strategy regards means of reducing the cyber terror threat surface.

The academic definition of a terrorist, is a person who attacks civilians.

If we consider that cyber terror is not fundamentally different than bombers with suicide belts, we are drawn to consider the amount of damage caused by any terror attack whether on the street or in a database of customer records. Reducing the probability of attack means first of all, reducing the threat surface.

We can reduce the threat surface by dividing and conquering, keeping cyber terrorist strength small and counter-terrorist effectiveness high and deny incentives for glorification and bandstanding of cyber terror activities. To minimize the glam and sympathy factor, we should withhold real-time disclosure of information regarding the terror activities. See more on counter terrorism on the Wikipedia.  Because we live in a real-time world of smart phones, Twitter and satellite phones, denying real-time exposure is denying one of the key attacker advantages.

3) I am an advocate of proper thinking over brute force.  A government, and certainly a business cannot spend its way into a secure information posture.

This part of the cyber security strategy mandates spending less money on reactive countermeasures like anti-virus software and reduce vulnerabilities by reducing the number of Windows machines by 10% a year and using Linux and FOSS technologies instead that are cheaper and more secure.   I have written here, here and here about why using Microsoft Windows is a bad idea. The discipline of software engineering (older and much better developed than information security engineering) has known for years that adding people to a late software development project only makes it even later.   Adding more anti-virus software only makes the Windows PCs even more vulnerable.

If we are serious about leveraging private-public partnerships in the war against cyber terror, instead of pouring billions into big defense contractors, let’s call up information security professionals for annual reserve duty in the war against cyber terror. I believe that the Chinese and Israelis already do this.

4) The fourth part of the cyber security strategy is a to use offensive measures proactively against attackers before the fact and not after an event. Retaliation after an attack is not an effective security countermeasure for the next attack since it only gives the attackers free publicity and increases their motivation.  Taking focused, violent measures before an attack, given accurate intelligence, may be the best and safest way to reduce damage to civilian assets.

5) The fifth part of my proposed cyber security strategy suggests a demand-side strategy to reduce the social value of being a hacker.

Although there are offensive alternatives such as mounting systematic DDos attacks on the attackers or developing targeted spyware such as Stuxnet, even more intriguing is the notion of using a demand-side strategy to reduce the social value of being a hacker. Perhaps we can learn from the counter terror success of the Italians in the late 60s with dismantling the Brigatisti. The Italian government infiltrated the Red Brigades – bred mistrust and quickly rolled up the organization.

Attacking the social networks of people who develop and distribute malware would involve infiltrating the hacker underground, arresting hackers for criminal activity and cutting deals in return for actionable intelligence.

Since malware is a form of terrorism – this strategy might be effective since it goes directly to the source and potentially denies a key hacker benefit – the social gratification.

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

Lies of social networking

Is marketing age segmentation dead?

My sister-in-law Ella and husband Moshe came over last night for coffee. Moshe and I sat outside on our porch, so he could smoke his cigars and we rambled over a bunch of topics, private networking,  online banking and the Israeli stock market.  Moshe grumbled about his stock broker not knowing about customer segmentation and how he used the same investment policy with all his clients.   A few anecdotes like that and I realized:

Facebook doesn’t segment friends

There is an outstanding presentation from a person in google research discussing this very point – a lack of segmentation in social networks:

http://www.slideshare.net/padday/the-real-life-social-network-v2

Almost every social networking site makes 4 assumptions, despite the fact that there is ample evidence that they’re wrong.

  1. Your friends are equally important
  2. Your friends are arranged into discrete groups
  3. You can manage hundreds of friends
  4. Friendship is reciprocal and equal

 

In fact :

  1. People tend to have 4 – 6 groups
  2. Each group has 2-10 people
  3. There are strong ties and weak ties.
  4. Strong ties are always in the physical world are < 6
  5. Weak ties in a business context are  < 150

 

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
rug salesmen

Why your IT vendor doesn’t want you to do a risk analysis

Did you ever have a feeling that your IT integrator was treating you like a couple of guys selling you a Persian rug?  “Take it now – it’s so beautfiful, just perfect for your living room, a steal  for only $10,000 and it’s on sale” and when you ask if it will last, they tell you “Why do you want it to last? Enjoy, use it in good health, wear it out quickly and come back to the store so that we can sell you Persian Rug 2012”.

I had a meeting with a long-time client today – I’ve developed some systems for them in the FDA regulatory and clinical trial management space. We met for lunch to discuss a new project which involved an extension to an existing multi-center study.

The question of disaster recovery planning and offsite backup came up and  they asked me what I thought about backing up their clinical trial data together with their office file backups taken by their outsourcing IT provider.

I said this is a very bad idea because while their IT contractor specializes in providing Microsoft Windows/Office support for small businesses, they just don’t have the know-how or security expertise for HIPAA compliant data storage.

In general, small business IT integrators are  behind the curve on data security, compliance, disaster recovery and application software security. Their job is to keep Microsoft SBS running smoothly and install anti-virus software, not mitigate data security and HIPAA compliance attacks. The typical SMB integrator mindset is dominated by the Microsoft monoculture, and I would not expect them to be able to analyze data security threats correctly.

Whenever I go somewhere – I’m always looking at things with a security perspective – open doors, windows – things that could be easily lifted. Who might be a threat. Storing clinical data with a bunch of Microsoft Office files is just too big a risk to take. The CEO accepted my recommendation to encrypt data on a secure, hardened virtual server instance in the cloud and monitor potential exposure to new emerging threats as their application and project portfolio evolves.

After lunch and getting back into the office, I realized that Risk analysis is a threat to IT vendors.

Not every security countermeasure is effective or even relevant for your company. This is definitely a threat to an IT vendor salesperson who must make quota.

I am a big proponent of putting vendor suggestions aside and taking some time to perform a business threat analysis (shameless plug for our business threat analysis services,  download our free white paper and learn more about Business Threat Modeling and security management). In a business threat  analysis you ignore technology for a week or 2 and systematically collect assets, threats, vulnerabilities …and THEN examine the cost-effective security countermeasures.

Your vendor wants to sell you a fancy $20,000 application security/database firewall, but it may turn out that your top vulnerability is from 10 contract field service engineers who shlep your company’s source code on their notebook computers. You can mitigate the risk of a stolen notebook by installing a simple security countermeasure – Free open-source disk encryption software for Windows Vista/XP, Mac OS X, and Linux.

Information security vendors often promote their backup/data loss prevention/data retention/application security products using a compliance boogeyman.

The marketing communications often reaches levels of the absurd as we can see in the following example:

NetClarity (which is a NAC appliance) claims that it provides “IT Compliance Automation” and that it “Generates regulatory compliance gap analysis and differential compliance reports” and “self-assessment, auditing and policy builder tools for Visa/Mastercard PCI, GLBA (sic), HIPAA, CFR21-FDA-11,SOX-404, EO13231 government and international (ISO270001/17799) compliance.”

A network access control appliance is hardly an appropriate tool for compliance gap analysis but asserting that a NAC appliance or Web application firewall automates SOX 404 compliance is absurd.

Sarbanes-Oxley Section 404, requires management and the external auditor to report on the adequacy of the company’s internal control over financial reporting. This means that a company has to audit, document and test important financial reporting manual and automated controls. I remember the CEO of a client a few years ago insisting that he would not accept any financial reports from his accounting department unless they were automatic output from the General Ledger system – he would not accept Excel spreadsheets from his controller, since he knew that the data could be massaged and fudged. If there was a bug in the GL or missing / incorrect postings he wanted to fix the problem not cut and paste it.

Appropriate, timely and accurate financial reporting has absolutely nothing to do with network access control.


But the best part is the piece on the NetClarity Web site that claims that their product will help “Deter auditors from finding and writing up IT Security flaws on your network”.

And I suppose this really proves my point best of all.

Information security vendors like NetClarity do not have any economic incentive to really reduce data security and compliance breaches that would reduce  sales, making it better business for them  (not for their customers) to sell ineffective products.

This raises an interesting question about information security business models – but that’s a topic best left to another post.

 

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

The Microsoft monoculture as a threat to national security

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 shitload 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.

 

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

Application software in the cloud – power to the people

I think that it might be a novel approach to build a flat cloud security control model centered around consumers (stake holders, users and developers) of business applications software and the performance of the cloud services that they consume.

This might be a more productive and relevant control model than then the current complex, multiple layer, IT infrastructure and compliance-centric cloud security models that are being copied and pasted today.

It’s also more consistent with a technology shift towards consumer devices and services and an emerging transformation of the security industry from an end-user service industry to a B2B product.  Intel bought Mcafee. Two years ago, we still had end user customers. Today we only deal with technology vendors.

The cloud security reference model published by the CSA (Cloud Security Alliance) is a detailed and comprehensive guide to “Security for Critical Areas of Focus in Cloud Computing“.  The latest version was released in December 2009, back when Facebook had less than 80 million members.

It’s a long, eloquently written document with pearls of wisdom like:

Cloud computing is about gracefully losing control while maintaining accountability even if the operational responsibility falls upon one or more third parties.

I could not agree less.

We all use the term  “IT Governance” – as if security of  customer data was dependent on the governor of the IT department. Since we have lots of IT governance and lots of data breaches, we may safely assume that writing procedures while the hackers attack software and steal data is not an effective security countermeasure.

Management information systems, (aka Information technology) is about empowering management with information.

Cloud computing is about replacing the hegemony of management with the freedom of choice of business units.

Cloud computing has nothing to do with gracefully losing control – it’s about getting out from under the thumb of the CIO.

This is why a performance-oriented security control model is a better and more relevant fit for consumers of cloud services. What interests cloud computing consumers are the following questions:

  1. Does the application or service help me sell more, faster and cheaper with something different my customers haven’t heard yet?
  2. Can I deploy (HIPAA, PCI DSS …fill in the blanks) applications in the cloud at a price I can afford?

When we buy software application services (SaaS) using a utility model, then the security should not interest us, since it’s built in.

When we develop our own application software and run it in the cloud using an IaaS (infrastructure as a service) provider then the IT security infrastructure does not interest us, since it’s built into the infrastructure.

What should interest us  is business performance and service costs.

Neither of these are addressed in the CSA cloud security reference model, which is still fixated on familiar infrastructure controls:

This rigidity often manifests in the inability to gain parity in security control deployment in cloud environments compared to traditional IT. This stems mostly from the abstraction of infrastructure, and the lack of visibility and capability to integrate many familiar security controls — especially at the network layer.

Why should we be concerned with parity in security control deployment when I buy a service?

When we buy electricity, are we comparing our utility and safety expertise in electricity generation with the electric company?

I don’t think so.

Consider, a consumer-service provider cloud security control model that is focused  on performance.

The fundamentals of scalable cloud computing systems are fast networking and non-blocking design—the rest is message passing.

Current Web applications running in the cloud are fairly high latency (200-600 ms round trips for Ajax transactions) and demanding on the server infrastructure (forking threads and blocking IO on the Web server for every request).

Looking at business performance we know that time is money. We know that high latency applications are less responsive (making customers unhappy and reducing revenue). Since the cloud service provider charges per CPU cycle,  if the cloud service consumer deploys inefficient applications  his revenue goes down and his costs go up.

Since cloud computing is a utility, it’s a business decision to write inefficient, buggy code and pay more for the privilege.  It’s also a business decision to use services like Microsoft Azure which locks you into the Microsoft application development platforms or Salesforce.com that locks you into the SF.com way of doing things.

There is something counter-intuitive about locking yourself into a cloud computing service.  The price has to be right long term and long term may be a decision that your successor is taking.  Hmm. Food for thought.

Power to people baby.

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