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

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.

Software Associates specializes in helping medical device vendors achieve HIPAA compliance and improve the data and software security of their products in hospital and mobile environments.

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.

I.             Introduction

A threat analysis was performed on a medical device used in intensive care units. The analysis considers the security implications of deploying the devices inside a hospital network. Different stakeholders have different security and compliance concerns and therefore different agendas.

• Hospital IT management  - do the medical devices create new entry points for viruses and malware in the enterprise network?
• Medical device vendor and patient care staff – can we assure availability and integrity of the monitoring data?
• Hospital management – can we comply with HIPAA and reduce the risk of data leakage?

System configuration

The embedded system configuration is based on an Intel processor running Windows XP Embedded.  The devices are not members of a Microsoft Active Directory domain and do not have Internet connectivity.

The threat analysis process

A data collection phase employed face to face interviews with software and hardware developers and directly examined the medical device software and hardware. We identified potential attackers, entry points, threats, vulnerabilities and security countermeasures (those already implemented and those that might be implemented).  Following data collection, we performed a threat analysis using the PTA (Practical Threat Analysis) methodology summarized in Appendix A and described at length on the PTA Technologies web site.

Threat model entities

Our threat model uses four base classes; mapping assets to vulnerabilities, threats that exploit vulnerabilities and countermeasures that mitigate vulnerabilities.

For example:

The key assets were medical device availability, the hospital enterprise network and patient confidentiality. We received input from hospital IT management regarding annual rates of occurrence of virus and malware attacks (rare) and phishing attacks on hospital employees (the usual email-borne pharmacy scams etc…).

II.           Top unmitigated threats

After building the threat model with the four base classes and their relationships, we estimated the probability of threat occurrence, percent damage to assets and risk mitigation effectiveness.   Trusted insider information leakage event frequency was estimated as twice/year in the threat model, while virus, denial of service and malware attacks frequency were estimated to be rare (less than once every 3 years).  Hospital IT were primarily concerned with the health of their enterprise network (as opposed to the availability of the medical devices) – described in threat T017.

The 5 most severe unmitigated threats in our model (shown below), are derived using the PTA calculative method (http://www.ptatechnologies.com/?action=4pta), which takes into account estimated asset value, threat probability and  percent damage due to a threat event.

The TXXX identifiers in the left hand column refer to the entities in our model.

Removing electronic Protected Health Information (ePHI) from the medical device

Unauthorized disclosure of ePHI (T002) was nominally the most severe threat at the start of the analysis due to compliance (HIPAA) / patient privacy concerns.

Protected health information (PHI) is any information in the medical data set that can be used to identify an individual and that was created, used, or disclosed in the course of providing a health care service such as diagnosis or treatment.

Following the threat analysis, it was decided to remove all personally identifying information and use an alphanumeric designator, displayed on the medical device screen and at a central management station. Nurses can respond quickly to alarms of changes in patient signs (heart/respiratory rate) reported by a particular bedside unit without being exposed to personally identifiable information.

After removing ePHI, the risk assessment changed and the threat of the medical device infecting the hospital enterprise network (T017) then became our primary concern.

III.          Recommended countermeasure plan

Using the PTA quantitative threat model, we then calculated a prioritized plan of security countermeasures as shown in the following table. The below table is sorted according to recommended priority of implementation in terms of risk mitigation effectiveness. After implementing the below countermeasures, the calculative model estimates a residual risk of less than 3% to system assets.

Security countermeasures plan

The TXXX and CXXX numeric identifiers refer to threat and countermeasure entities in our threat model.

Patch management

The question of patch / update management always arises in the course of a threat analysis of medical devices;  the results are perhaps counterintuitive for typical IT managers:

• IT policy of running automated Windows Update on Windows PCs in the office is not necessarily a relevant countermeasure for embedded medical devices.

• Although FDA 510(K) recertification of the medical device may not be necessary when applying security patches – running Windows Update is practically impossible in an embedded device that does not have Internet access. The medical device vendor would typically apply patches to the embedded image as part of ongoing device field maintenance.

We note that an ICO medical device  is a specialized (not COTS) embedded device that does not have Internet or removable device connectivity. The device does not run MS Office, does not run IE and is not connected to the Internet and therefore has a much smaller threat surface than a typical Windows PC installed on the hospital network.

For these reasons, we focused our efforts on security countermeasures that would reduce the most severe threats – ePHI leakage, software defects and USB access to the medical device itself.

IV.         Propagation of viruses/malware in the enterprise network

One of the key security concerns when operating networked, Windows-based embedded medical devices is whether new entry points for viruses and malware are created in the enterprise network.

We sub-divided this concern into 3 separate threat scenarios:

1. Can the medical devices be infected from the enterprise network?
2. Can the medical devices be infected via USB devices?
3. Can infected medical devices propagate malicious software back into the enterprise network?

Can the medical devices be infected from the enterprise network?

The short answer is no.

The medical device analyzed in the study uses Windows XP Embedded and a proprietary TCP/IP messaging protocol in order to communicate with a central management station.

The operating system itself is hardened, does not run Windows shell, does not run IE and shuts down all unneeded services such as SMB and RPC. In addition, it runs a Windows Firewall instance that blocks all ports except the TCP/IP listener ports.

Although a dedicated attacker with the right skill set might be able to sniff traffic, reverse engineer the protocol and fuzz, there is always the question of whether or not the value of the asset justifies the cost of the attack.  In this particular medical device, considering the hardware configuration and use of a proprietary messaging protocol; we felt that the medical device was not particularly vulnerable to such attacks.

1. 2. Can the medical devices be infected via USB devices?

The short answer is yes – potentially by anyone who inserts an infected USB removable storage device.

We have addressed this vulnerability in countermeasure C048 – “Implement an IO-board hardware toggle for enabling/disabling USB ports”. We also strongly recommended migration to Linux – with no USB auto-run functions (see next section).

1. 3. Can USB-infected medical devices propagate malicious software back into the enterprise network?

The short answer is yes.

Although the proprietary request/response communications protocol used by the units cannot be used to transport files to other Windows PCS, a worm such as Conficker can exploit vulnerabilities in Windows services, disable the Windows firewall and propagate from the source computer to the hospital network on an arbitrary port between 1024 and 10000.

V.           Future: segregation of bio-med and IT domains

While hospital IT systems typically use Microsoft Windows; for an embedded medical device, we highly recommend using Linux due to its ease of maintenance and resistance to USB exploits and worms such as Conficker that exploit Windows software.  A suggested minimal configuration should consist of an up-to-date Linux kernel, QT, touch-screen, network support and a main loop to run the medical device application.  A more detailed discussion of the proposed Linux implementation is beyond the scope of this article. See the excellent article “The Top 10 mistakes embedded Linux developers make for some guidelines“.

VI.         Summary

A threat analysis of a networked medical device was performed and a mitigation plan of countermeasures was produced, including recommended priority of implementation.  As a result of the analysis, it was decided to modify the medical device design and not to store ePHI. This is obviously the most effective countermeasure possible for HIPAA compliance and protecting patient privacy. In addition, a decision was taken to migrate the medical device OS platform to embedded Linux to eliminate typical Microsoft Windows network and removable device vulnerabilities.

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.

Which Linux?

From: ” Snapshot of the Embedded Linux market March, 2004″
http://linuxdevices.com/articles/AT8693703925.html

Which Vendor?

From: ” Snapshot of the Embedded Linux market March, 2004″
Instead of rolling their own OS from scratch, embedded developers now roll their own OS from Linux source. The barchart shows that, collectively, embedded Linux vendors including MontaVista, Metrowerks, TimeSys, Denx, Sysgo, LynuxWorks, and FSMLabs have supplied Linux for only 22 percent of projects during the last two years, projected to reach 24.2 percent over the next two years.

http://linuxdevices.com/articles/AT8693703925.html

9 – Then Pick a Platform

• Most people immediately turn to Intel for a platform.
• If you are running high performance commodity systems this makes sense.
• For smaller embedded systems the Intel X86 architecture isn’t necessarily the best choice.

Which Processor?

ARM — including StrongARM and XScale architectures – are gaining on x86 as the most popular processor architecture for embedded development. This year’s results show that trend continuing. And, for the first time, embedded Linux developers are projecting that they’ll base more projects on ARM than x86 processors in their projects during the next two years.

http://linuxdevices.com/articles/AT8693703925.html

8 – We are not in Kansas anymore.

• Linux is a disruptive technology. A once in a generation paradigm change.
• If you don’t change your methods of dealing withsoftware support, you will not benefit.
• Let’s examine the issue of support in Open Source Systems.

Commercial vs. Open Source Knowledge Base – cost and access

Who Do You Turn To?

• There are three viable approaches in dealing with support issues in Linux.
  • Get support from a large foreign software company.
  • Get support from a smaller local software company
  • Support yourself.

Support:
Large Foreign Company

• There are a number of fairly large companies that support embedded Linux:
  • IBM
  • Montavista
  • RedHat
• You have to be careful of ” vendor lockin”
• Why go to Linux and then sell your soul to the devil?

Support: Small Local Company

• There are a number of local companies that can provide support for embedded Linux.
• The nice thing about this approach is that the local companies are not at a disadvantage since there is no proprietary or hidden software in the embedded Linux solution.
• Just look around you, there is plenty of talent in this country.

• No ” vendor lockin” .

Support Yourself:

• Since everything is open you can provide your own support.
• This is definitely the most effective, but it needs the largest investment of time and talent.
• There is a lot of help available on the Internet and recently published books.

7 – I want it to run real fast.

Well boy you need real time.

Real Time Systems

• A large amount of confusion exists about the uses of commercial RTOS’s
• This confusion is largely propagated by companies that sell RTOS’s.
• The use of RTOS’s in embedded systems is mostly a historical anomaly.

Real Time Systems

• Real time systems are optimized to minimize worse case latency (the response time).
• Interrupt latency is usually the criterion that defines how “Real Time” the operating system is.
• RTOS are usually needed to control hardware that has strict time constraints.

Embedded Systems

• Embedded systems are systems with limited human interaction.
• These systems are sometime very small but not necessarily.
• The embedded computer market is huge The shipment volume of embedded systems is much larger than the PC computer market.

Latency vs Throughput

RTOS
Linux
Real Time – Says Who?

• The majority of realtime systems aren’t.
• Embedded systems are often misclassified as realtime systems. However, most systems simply do not require realtime capabilities, in fact these capabilities are detrimental.

• Realtime requirements are often simply designed out through the use of a deeper hardware FIFO, scatter/gather DMA engines and custom hardware.

So You Still Want Real Time!

• There are a number of approaches that can be used to provide Real Time Response:
• Soft Real time: There are various low latency patches to the standard Linux kernel:
  • Montavista’s
  • Redhat’s
• Hard Real time: The are a number of hard real time kernel patches:
  • Rtai
  • RtLinux

6 – Posix RealTime Extensions

Posix.4 RealTime Extensions to Linux

• Posix.4 adds realtime facilities to Posix.
• This standard add the facilities typically used in RTOS’s.
• In my opinion using these facilities are a recipe for trouble.
• There are no standard Linux programs that use these facilities, just look at your favorite Linux distribution.

Use Linux’s Strong Simple Abstractions

• Linux supports some very powerful abstractions that should be preferred over many weaker techniques.
• The major strong abstractions of Linux are:
  • Files
  • Processes
  • Memory spaces
  • IPC

5 – Java

• While this is difficult to classify as a mistake, it is worth noting that virtually no standard Linux programs are written in Java.

• Sun itself uses GnomeGtk for its desktop, which is written in C. If Java is so good why doesn’t Sun use it.
• Sun releases a SUSE version of Linux, without any Java programs, and dubs it the ” Java Desktop System” .

4 – Scaling

• Embedded environments many times have restrictive resources and the software must be properly scaled to run on the platform.
• Things that are appropriate for a large enterprise server, such as Apache, PHP, graphical toolkits that are familiar to many Linux users are just too big for restricted embedded hardware.
• Trying to squeeze these large programs into small flash memory is just no fun.

3 – Threads

• The main problem with threads is that they are hard to use correctly. Even for experts,development is painful.

http://www.cc.gatech.edu/ccg/people/rob/software/threads/ousterhout_threads.html

Why Threads are Hard

• Synchronization:
  • Must coordinate access to shared data with locks.
  • Forget a lock. Corrupted data.
• Deadlock:
  • Circular dependencies among locks.
  • Each process waits for some other process.

Why Threads are Hard, cont’d

• Achieving good performance is hard:
  • Simple locking (e.g. monitors) yields low concurrency.
  • Finegrain locking increases complexity, reduces performance in normal case.
  • OSes limit performance (scheduling, context switches).
• Threads not well supported:
  • Hard to port threaded code (PCs? Macs?).
  • Standard libraries not threadsafe.
  • Kernel calls, window systems not multithreaded.
  • Few debugging tools (LockLint, debuggers?).

Debugging Threaded Programs

If Not Threads Then: EventDriven Programming

• One execution stream: no CPU concurrency.
• Register interest in events (callbacks).
• Event loop waits for events, invokes handlers.
• No preemption of event handlers.
• Handlers generally shortlived.

• Main loop architecture.

Process Based Concurrency

Process Based Concurrency Another Alternative

• Use processes for concurrency rather than threads.
• Synchronize processes with event based IPC.
• Advantages:
  Simpler and surprisingly more efficient synchronization than threads.
• send/rcv is self synchronizing and buffered.
  No race conditions. Much simpler to debug. Trivial to distribute.

Process Based Concurrency

P1 P2 P3 P4
Event Based Manager
Process Based Threading
Another Alternative

• Instead of sharing all memory, create processes with a shared memory region.
  • This allows you to minimize the interaction of the processes to a well defined subset of the total memory space of the application.
  • Thread safe libraries are not needed.
  • Use POSIX 1003.1b semaphores to synchronize shared data.
  • No performance hit.

2 – Use the Source Luke

• The source is your friend.
• The GPL creates a unique situation that makes many embedded devices transparent.
• The WRT54G wireless router is a case in point.
• Linksys (a Cisco company) shipped this box without any indication that the software was GPL’ed
• Someone noticed that this was a Linux box and sent an email:

The Letter

From Andrew Miklas <>
Subject Linksys WRT54G and the GPL
Date Sat, 7 Jun 2003 22:41:23 0400
Hi,
Awhile ago, I mentioned that the Linksys WRT54G wireless access point used
several GPL projects in its firmware, but did not seem to have any of the
source available, or acknowledge the use of the GPLed software. Four weeks
ago, I spoke with an employee at Linksys who confirmed that the system did
use Linux, and also mentioned that he would work with his management to
ensure that the source was released. Unfortunately, my emails
to this
individual over the past three weeks have gone unanswered. Of course, I also
tried contacting Linksys through their common public email
accounts
(
 pr@linksys.com,
 mailroom@linksys.com) to no avail.

Linksys Releases The Source

• Linksys eventually released the sources.
• You can just download it from their web site.
• This launched ” The Little Engine That Could” .
• They have done very well with this product.
• If you want to design an embedded Linux product just look at the completely transparent design of the WRT54G for a guide on how to design an embedded system.

1. GPL Violations

• Israeli companies tend to ignore the finer details of legalities.
• Violations of the GPL are a serious matter.
• Recently the GPL has been upheld in its first court test in Germany.
• The authors of netfilter, Linux’s firewall, has been granted an injunction against Sitecom Germany GmbH for GPL violations.

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:

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.

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

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.

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

It is ironic that the FIFA 2010 World cup computer game doesn’t run on Ubuntu.  It would have been a huge marketing coup and poetic justice if the game software was released for Ubuntu in a GPL license.

This got me thinking about open source licensing and it’s advantages for developing countries, which really got my hackles up  after reading the Seventh Annual BSA and IDC Global Software Piracy Study – that screams:  Software Theft Remains Significant Issue Around the World

The rate of global software piracy climbed to 43 percent in 2009. This increase was fueled in large part by expanding PC sales in fast-growing, high-piracy countries and increasing sales to consumers — two market segments that traditionally have higher incidents of software theft. In 2009, for every $100 worth of legitimate software sold, an additional $75 worth of unlicensed software made its way onto the market. There was some progress in 2009 — software rates actually dropped in almost half of the countries examined in this year’s study.

Given the global recession, the software piracy picture could have taken a dramatic turn for the worse. But progress is being outstripped by the overall increases in piracy globally — and highlights the need for governments, law enforcement and industry to work together to address this vital economic issue.
Below are key findings from this year’s study:

• Commercial value of software theft exceeds $50 billion: the commercial value of unlicensed software put into the market in 2009 totalled $51.4 billion.
• Progress on piracy held through the recession: the rate of PC software piracy dropped in nearly half (49%) of the 111 economies studied, remained the same in 34% and rose in 17%.
• Piracy continues to rise on a global basis: the worldwide piracy rate increased from 41% in 2008 to 43% in 2009; largely a result of exponential growth in the PC and software markets in higher piracy, fast growing markets such as Brazil, India and China.

I would not take the numbers IDC and BSA bring at face value. The IDC/BSA estimates are guesses multiplied several times. They start off by assuming that each unit of copied software represents a direct loss of sale for software vendor – patently 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 )

Back when I ran Bynet Software Systems – we were the first Microsoft Back Office/Windows NT distributor in Israel. I had just left Intel – where we had negotiated a deal with Microsoft that allowed every employee to make a copy of MS Office for home usage. Back in 1997 – after the Windows NT launch, the demand for NT was almost totally inelastic – Not There, Nice Try, WNT is VMS + 1 etc. We could not give the stuff away in the first year. Customers were telling us that they would never leave Novell Netware. Never. But, NT got better from release to release and the big Microsoft marketing machine got behind the product. After two years of struggle and selling retail boxes and MLP for NT, demand picked up. Realizing that there IS price elasticity of demand for software – Microsoft dropped retail packaging and moved to OEM licensing, initially distributing OEM licenses via their two tier distribution channel and later totally cutting out the channel and dealing directly with the computer vendors like HP, Dell and IBM for OEM licenses of NT, XP and 2000, 2003 etc. Vista continued with this marketing strategy and most Vista sales were not retail boxes but pre-installed hardware. After Windows 7 released – users have been upgrading en-masse, proving once again the elasticity of demand for a good product.

Microsoft (who are a major stakeholder in BSA) probably don’t have a major piracy problem with operating system sales. Let’s run some numbers. In 2008 –  Microsoft Windows Vista sales were at about a 9 million unit/quarter run rate. Microsoft June 2008 quarterly revenue was $15.8 BN. Single unit OEM pricing for a Windows operating system  is about $80 and in a volume deal – maybe $20. Let’s assume an average of $50/OEM license. This means that the operating system  accounts for about 50*3*9/15800 = 8.5% of Microsoft revenue.

The BSA Global Piracy Study states that the “median piracy rate in is down one percentage point from last year” – 1 percent of 8.5 percent is meaningless for Microsoft – in dollar terms – BSA work to reduce piracy is less meaningful than a 7 percent drop in the US Dollar rate in 2009.

Microsoft might have a problem with their cash cow – Microsoft Office. Microsoft Office 2007 retails for $450 but is available in an academic license for less than $100. Open Office 2.4 runs just fine on Windows 7 and XP and retails for $0. At those prices, sizable numbers of users are just sliding down the elasticity curve – calling into serious question the IDC/BSA statistics on software piracy.

But there is more to software piracy than providing software at a reasonable price. In poor areas of the world – assuming that the BSA efforts at combating software piracy are successful - only the very rich would have access to applications like Microsoft Office. The middle and lower class people won’t have the opportunity to become MS Office-literate because the prices would be too high. For that I only have three words -download Open Office – the free and open productivity suite.

Finally – I can only anonymously quote a senior Microsoft executive who told me a number of years ago that off the record, Microsoft didn’t mind people copying the software and using a crack because it was a good way of introducing new users to the technology and inducing them to buy the new, improved and supported release a year or two later.

The people that develop embedded medical devices based on Intel platforms know that Windows is vulnerable.

Lacking embedded Linux know-how, medical device developers often end up adopting Windows and Visual Studio as a default. Using Windows is a security-blanket for developers who grew up in the Microsoft Windows monoculture and are scared of the Linux command line.

But – make no mistake using Windows in networked embedded medical devices is a mistake.
This is big mistake #1.

The top 2 threats to a medical device are software defects and software updates.
Consider the implications of updating patient monitoring devices in a hospital with an infected USB stick or an infected Windows notebook.

In product development (and medical device are  no exception),  the support and version update process  is often something  left for the end of the project. At that point, when the product manager asks how are we going to update the software in the field – the hands raise in favor of  USB memory stick updates as an “interim” solution.

It is crucial to use threat analysis on systems of networked medical devices in order to arrive at the right, cost-effective countermeasures (apropos the management challenge of large number of VLANS…). Threat analysis must be an integral part of the SDLC (software development life cycle) – done early in the process and validated from time to time whenever there are significant design, configuration or environmental changes.

Threat analysis enables a medical device vendor and the hospital security team to have an objective discussion on balancing the need to protect the hospital network asset with protecting the availability of the medical device  itself and concomitantly – the safety of patients that are dependent on the device – patient monitoring is the first example that comes to mind.

Unfortunately many device vendors and their hospital customers use a system management model based on Microsoft Windows and business IT management practices. This is big mistake #2.

Medical device vendors need to assess their software security and not assume that an embedded medical device running Windows XP   is no different from any other Windows PC on the network running Office 2007.

To use an analogy from the world of real time embedded systems – consider avionics as key to safety of the pilot and success of the mission. Avionics are not managed like a network of Windows PCs and neither should medical devices on the hospital network.

A medical device in a hospital network – whether it monitors patients, assists in surgery or analyzes EEGs – is an embedded device in a extremely heterogeneous and hostile environment that should simply not be vulnerable to Microsoft Windows malware.

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.

As you may have read recently, Cybercrime is now costing the UK $43.5 billion and around $1 trillion globally.

Sponsored by security and compliance auditing vendor nCircle, the Webinar pitch didn’t cite any sources for the $1 trillion number nor the $43.5 billion number.

A little googling revealed the UK government report UK Cyber crime costs UKP 27BN/year. Published on the BBC’s website, the report offers a top-level breakdown of the costs of cybercrime to Britain using a fairly detailed scheme of classification and models. Regardless of how badly UK businesses are hit by cybercrime, there are several extremely weak points in the work done by Detica for the UK government.

a) First  - they don’t have any empirical data on actual cybercrime events.

Given the number of variables and lack of ‘official’ data, our methodology uses a scenario- based approach.

Which is a nice way of saying

the UK government gave us some money to do a study so we put together a fancy model, put our fingers in the air and picked a number.

b) Second – reading through the report, there is a great deal of information relating to fraud of all kinds, including Stuxnet which has nothing to do with the UK cyber crime space. Stuxnet does not seem to have put much of a dent in the Iranian nuclear weapons program although, it has given the American President even more time to hem and haw about Iranian nuclear threats.

What this tells me is that Stuxnet  has become a wakeup call for politicians to the malware threat that has existed for several years. This may be a good thing.

c) Third – the UK study did not interview a single CEO in any of the sectors they covered. This is shoddy research work, no matter how well packaged. I do not know a single CEO and CFO that cannot quantify their potential damage due to cyber crime – given a practical threat model and coached by an expert not a marketing person.

So – who pays the cost of cyber crime?

The consumer (just ask your friends, you’ll get plenty of empirical data).

Retail companies that have a credit card breach incur costs of management attention, legal and PR which can always to leveraged into marketing activities. This is rarely reported in the balance sheet as extraordinary expenses so one may assume that it is part of the cost of doing business.

Tech companies that have an IP breach is a different story and I’ve spoken about that at length on the blog. I believe that small to mid size companies are the hardest hit contrary to the claims made in the UK government study.

I would not venture a guess on total global cost of cyber crime without empirical data.

What gives me confidence that the 1 Trillion number is questionable is that it just happens to be the same number that President Obama and other leaders have used for the cost of IP theft – one could easily blame an Obama staffer for not doing her homework….

If one takes a parallel look at the world of software piracy and product counterfeiting, one sees a similar phenomenon where political and commercial organizations like the OECD and Microsoft have marketing agendas and axes to grind leading to number inflation.

I have written on the problems associated with guessing and rounding up in the area of counterfeiting here  and software piracy.

Getting back to cyber crime, using counterfeiting as a paradigm, one sees clearly that the consumer bears the brunt of the damage – whether it’s having her identity stolen and having to spend the next 6 months rebuilding her life or whether you crash on a mountain bike with fake parts and get killed.

If consumers bear the brunt of the damage, what is the best way to improve consumer data security and safety?

Certainly – not by hyping the numbers of the damage of cyber crime to big business and government. That doesn’t help the consumer.

Then – considering that rapid rollout of new and even sexier consumer devices like the iPad 2, probably not by security awareness campaigns. When one buys an iPhone or iPad, one assumes that the security is built in.

My most practical and cheapest countermeasure to cyber crime (and I will distinctly separate civilian crime from terror ) would be education starting in first grade. Just like they told you how to cross the street, we should be educating our children on open, critical thinking and not talking to strangers anywhere, not on the street and not on FB.

Regarding cyber terror – I have written at length how the Obama administration is clueless on cyber terror

One would hope that in defense of liberty – the Americans and their allies will soon implement more offensive and more creative measures against Islamic and Iranian sponsored cyber terror than stock answers like installing host based intrusion detection on DoD PCs