1. A robust, cost-effective security portfolio based on attack analysis  results in robust compliance over time.
2. Executives related well to the concepts of threat modeling / attack analysis. Competing, understanding the value of their assets, taking risks and protecting themselves from attackers is really, at the end of the day why executives get the big bucks.

As I wrote in a previous essay “The valley of death between IT and security“, there is a fundamental disconnect between IT operations (built on maintaining predictable business processes) and security operations (built on mitigating vulnerabilities).

Business executives delegate information systems to IT and information security to security people on the tacit assumption that they are the experts in information systems and security.  This is a necessary but not sufficient condition.

In the current environment of rapidly evolving types of attacks (hacktivisim, nation-state attacks, credit card attacks mounted by organized crime, script kiddies, competitors and malicious insiders and more…), it is essential that IT and security communicate effectively regarding the types of attacks that their organization may face and what is the potential business impact.

If you have any doubt about the importance of IT and security talking to each other, consider that leading up to 9/11, the CIA  had intelligence on Al Qaeda terrorists and the FBI investigated people taking flying lessons, but no one asked the question why Arabs were learning to fly planes but not land them.

With this fundamental disconnect between 2 key maintainers of information protection, it is no wonder that organizations are having difficulty effectively protecting their assets – whether Web site availability for an online business, PHI for a healthcare organization or intellectual property for an advanced technology firm.

IT and security  need a common language to execute their mission, and I submit that building the security portfolio around most likely threat scenarios from an attacker perspective is the best way to cross that valley of death.

There seems to be a tacit assumption with many executives that regulatory compliance is already a common language of security for an organization.  Compliance is a good thing as it drives organizations to take action on vulnerabilities but compliance checklists like PCI DSS 2.0, the HIPAA security rule, NIST 800 etc, are a dangerous replacement for thinking through the most likely threats to your business.  I have written about insecurity by compliance here and here.

Let me illustrate why compliance control policies are not the common language we need.

PCI DSS 2.0 has an obsessive preoccupation with anti-virus.  It does not matter if you have a 16 quad-core Linux database server that is not attached the Internet with no removable device nor Windows connectivity. PCI DSS 2.0 wants you to install ClamAV and open the server up to the Internet for the daily anti-virus signature updates. This is an example of a compliance control policy that is not rooted in a probable threat scenario that creates additional vulnerabilities for the business.

Now, consider some deeper ramifications of compliance control policy-based security.

When a  QSA or HIPAA auditor records an encounter with a customer, he records the planning, penetration testing, controls, and follow-up, not under a threat scenario, but under a control item (like access control). The next auditor that reviews the  compliance posture of the business  needs to read about the planning, testing, controls, and follow-up and then reverse-engineer the process to arrive at which threats are exploiting which vulnerabilities.

Other actors such as government agencies (DHS for example) and security researchers go through the same process. They all have their own methods of churning through the planning, test results, controls, and follow-up, to reverse-engineer the data in order to arrive at which threats are exploiting which vulnerabilities.

This ongoing process of “reverse-engineering” is the root cause for a series of additional problems:

• Lack of overview of the the security threats and vulnerabilities that really count
• No sufficient connection to best practice security controls, no indication on which controls to follow or which have been followed
• No connection between controls and security events, except circumstantial
• No ability to detect and warn for negative interactions between countermeasures (for example – configuring a firewall that blocks Internet access but also blocks operating system updates and enables malicious insiders or outsiders to back-door into the systems from inside the network and compromise  firewalled services).
• No archiving or demoting of less important and solved threat scenarios (since the data models are control based)
• Lack of overview of security status of a particular business, only a series of historical observations disclosed or not disclosed.  Is Bank of America getting better at data security or worse?
• An excess of event data that cannot possibly be read by the security and risk analyst at every encounter
• Confidentiality and privacy borders are hard to define since the border definitions are networks, systems and applications not confidentiality and privacy.

Threat scenarios as an alternative to compliance control policies

When we perform a software security assessment of a medical device or healthcare system, we think in terms of “threat scenarios” or “attack scenarios”, and the result of that thinking manifests itself in planning, penetration testing, security countermeasures, and follow-up for compliance. The threat scenarios are not “one size fits all”.  The threat scenarios for an AIDS testing lab using medical devices that automatically scan and analyze blood samples, or an Army hospital using a networked brain scanning device to diagnose soldiers with head injuries, or an implanted cardiac device with mobile connectivity are all totally different.

We evaluate the medical device or healthcare product from an attacker point of view, then from the management team point of view, and then recommend specific cost-effective, security countermeasures to mitigate the damage from the most likely attacks.

Threat scenarios consider asset values, vulnerabilities, threats and possible security countermeasures. Threat analysis as a methodology does not look for ROI or ROSI (there is no ROI for security anyhow) but considers the best and cheapest way to reduce asset value at risk.

In our experience, building the security portfolio on threat scenarios has 2 clear benefits;

1. A robust, cost-effective security portfolio based on attack analysis  results in robust compliance over time.
2. Executives relate well to the concepts of threat modeling / attack analysis. Competing, understanding the value of their assets, taking risks and protecting themselves from attackers is really, at the end of the day why executives get the big bucks.

Are you sure you do not store any payment card data or PII (personally identifiable information) in some MySQL database?

The first step in protecting credit card and customer data is to know what sensitive data you really store, classify what you have  and set up the appropriate security controls.

Here is a policy for any merchant or payment processor who want to achieve and sustain PCI DSS 2.0 compliance and protect customer data.

I. Introduction

You need to identify and apply controls to the data types identified in this policy. The data types identified below are considered digital assets and are to be controlled and managed as specified in this policy while retained or processed by the organization. You should identify and inventory all systems that store or process this information and will audit these systems on a semi-annual bases for effectiveness of controls to manage the data types.

II. Background

The Payment Card Industry (PCI) Security Standard is a requirement for all financial institutions and merchants that use or process credit card information. This security standard is designed to help protect the integrity of the credit card systems and to help mitigate the risk of fraud and identity theft to the individuals who use credit cards to make purchases for goods and services.

The PCI Security Standard was originally introduced by by VISA as the Cardholder Information Security Program (CISP) and specified the security controls for each level or merchant and credit card processor. In 2004 the major brands in the card payment industry agreed to adopt the CISP standard and requirements and a single industry standard in order to reduce the costs of implementation and assessment and increase the rate of adoption. Most organizations were required to meet all requirements of the PCI security standard by June 30^th 2005 and it is now an ongoing compliance process with merchants, payment processors and issuers.

III. General Policy Statement

All Credit Card Information and associated data is company confidential and will not be transmitted over public networks in the clear. Credit Card information can only be transmitted encrypted and only for authorized business purposes to authorized parties that have been approved to receive credit card information.

IV. Data Classifications of Credit Card Information

Personally Identifiable Information

Data Description and Policy

Any information that is collected about the owner of the credit card such as their name, signature, address, phone number or driver’s license number or social security number will be classified and controlled as PERSONALLY IDENTIFIABLE INFORMATION or PII. As a general rule to help the user identify PII data consider if a reasonable person with a reasonable level of effort could use the information to identify an individual. PII data is confidential to the organization and can only by used for specific purposes which are listed below. Only pre-authorized parties are allowed to receive PII data and only through authorized communication channels.

Examples

The following examples are for illustration only and do not necessarily comprise a complete set of all types of Personally Identifiable Information:

• Name
• Address
• Phone Number(s)
• Drivers License
• Social Security Number

Authorized Uses

• To provide customer service
• To ship products or deliver services to a customer
• To collect or process payment for products or services
• To facilitate planning or to support marketing plans

Authorized Channels for Communication

• Official Electronic Mail System of the Organization
• File Transfer Protocol
• Web Services

Controls

• Encrypt data when stored on magnetic media
• Encrypt data when transmitted over public networks
• Label as confidential when printed
• De-identify data when used for other than authorized purposes
• Retain data for no more than three years
• Destroy data upon three year anniversary

Sample DataSafe Business Rule

PII Data AND Credit Card Data in any channel will be block if unencrypted

Credit Card Information

Data Description and Policy

Credit Card Information will include the credit card number, the type of credit card (such as Visa, MasterCard, Discover, etc.) the security code and the expiration data. In addition to the basic credit card information other information such as the issuing bank or financial institution is considered part of the credit card information. Credit Card Information is considered confidential to the organization and can only by used for specific purposes, which are listed below. Only pre-authorized parties are allowed to receive Credit Card data and only through authorized communication channels.

Examples

The following examples are for illustration and are considered the comprehensive set of Credit Card Information:

• Type of Credit Card
• Name on Credit Card
• Credit card Number
• Expiration Data
• Security Code

Authorized Uses

• To provide customer service
• To support accounting or reconciliation business processes
• To investigate fraud or criminal activities
• To collect or process payment for products or services

Authorized Channels for Communication

• Official Electronic Mail System of the Organization
• File Transfer Protocol
• Web Services

Controls

• Encrypt data when stored on magnetic media
• Encrypt data when transmitted over public networks
• De-identify data when used for other than authorized purposes
• Retain data for no more than three years
• Destroy data upon three year anniversary

Credit Card Magnetic Stripe Data

Data Description and Policy

Credit Card Magnetic Stripe data is information that is automatically read through an electronic credit card reader and includes Track I and Track II data. These two tracks contain the credit card information and the name of the individual authorized to use the card as well as some other service and issuer specific information. The Credit Card Magnetic Stripe Data is considered confidential to the owner and authorized user and can only be used to process a financial transaction. Only pre-authorized parties are allowed to receive Magnetic Stripe data and only through authorized communication channels.

Examples

The following examples are for illustration and are considered the comprehensive set of Magnetic Stripe Data:

• Track I Data – 56 Bytes

• Track II Data – 35 Bytes

• Personal Identification Number

Authorized Uses

The only authorized use for Magnetic Strip Data is to complete an automated, electronic financial transaction.

Authorized Channels for Communication

• File Transfer Protocol
• Private Line or VPN
• Web Services

Controls

• Electronic storage on magnetic media is not allowed – zero retention
• Encrypt data when transmitted over public networks

Credit Card Transaction Data

Data Description and Policy

Transaction data is collected at a point of sale and will often include items purchased, credit card information, date and time, authorization code and transaction amount. These transaction details are confidential to the organization and can only by used for specific purposes, which are listed below. Only pre-authorized parties are allowed to receive Credit Card Transaction data and only through authorized communication channels.

Examples

The following examples are for illustration only and do not necessarily comprise a complete set of all types of Credit Card Transaction Data:

• Authorization Code
• Transaction Number
• Name
• Amount

Authorized Uses

• To process or collect payment for products or services
• To reconcile all financial accounting
• To provide customer service

Authorized Channels for Communication

• Official Electronic Mail System of the Organization
• File Transfer Protocol
• Web Services

Controls

• Encrypt data when stored on magnetic media
• Encrypt data when transmitted over public networks
• De-identify data when used for other than authorized purposes
• Retain data for no more than three years
• Destroy data upon three year anniversary

I have written here, here and here about how to reduce the risk of a data breach of a web site.

Not to rain on the media party, but the actual cost to a online marketer of a hacker breaching a web site or defacing the web site could be very low since card-holders are covered by the credit card issuers and as long as the online commerce site continues operation, a temporary revenue dip might be offset by additional visits to the publicity.

Then again, the cost of a data breach to your operation could be very high, especially if you scrimp on security.

So – what is the right answer?

The right answer is the right security for your web site at the right cost to your pocket, not what Symantec says or what Microsoft says but what your risk assessment says.

In order to implement the most cost-effective security for your web site, you need to do a risk assessment that takes into consideration the value of your assets, the probability of attacks,  current vulnerabilities of your web site and operation (don’t forget that trusted insiders may be the more significant vulnerability in your operation) and possible countermeasures, including the cost of said countermeasures.

Sounds complex, right?

Actually – performing a threat analysis of  your web site can be a fairly straightforward exercise using the free risk assessment software provided by PTA Technologies.

You can download the free risk assessment software here and start improving your security today.

Any questions – feel free to reach out to the professional software security consultants in Israel at Software Associates.

Democracies like Israel, the US and the UK have “a tendency to extremism tempered by having to compromise” (courtesy of D.M. Thomas in his NY Times book review of Philip Roth’s “Operation Shylock“.)

In my previous post “Insecurity by compliance“, I considered the connection between being a free market democracy like the US, Israel or the UK and having  a serious privacy and credit card data security breach problem and my essay “The Israeli credit card breach” delved into the root causes why Israel’s organizations have poor data security.

Following hacking attacks yesterday on Israeli web sites of sites of El Al Israel Airlines Ltd and the Tel Aviv Stock Exchange, Israel Discount Bank and First International Bank of Israel announced that they have blocked access to their websites from outside Israel.

I am not surprised that IDB and FIBI are resorting to primitive methods like blocking IP addresses. If you’ve ever dealt with one, you know that the security management strategy of banking institutions is often highly influenced by internal politics and relies on outsourcing information security operations to security consultants, who naturally want to reduce their personal exposure  as opposed to the banking institution total value at risk.

Shutting down access to a Web site based on geographic source of an IP address is a ludicrous security countermeasure for a hacker – since it is simple to mount the attack from a server or network of Windows PCs in Israel with Israeli IP addresses.

From the government end, there are cries for more Web site security compliance regulation.

I will give the Israeli Ministry of Justice credit for having done nothing for over 20 years on updating the Israeli privacy law.  There is really nothing basically wrong with the law, it just needs to be enforced.  For that, you need police officers who know how to read English – see my post on that problem here.

Even now, I suspect that the Ministry of Justice is just treading water and reacting to the recent spate of credit card and Web site breaches by the so called Saudi hacker.

Security by compliance does not improve data security, especially since attackers can reverse-engineer the minimum security requirements dictated by a standard to look for holes in a company’s defense.

Is a free market democracy doomed to suffer from privacy breaches – by definition?

My father is a retired PhD in system science from UCLA who worked for many years in the defense industry in Israel and California.  At age 89 he is sharp, curious and wired, with an iPad and more connected and easily accessible on the Net than most people are on their phone.

He sent me this item which turned out to be yet another piece of Internet spam and urban legend that has been apparently circulating the Net for over 10 years and has resurfaced just in time for the US Presidential elections.

A democracy is always temporary in nature; it simply cannot exist as a permanent form of government….The average age of the world’s greatest civilizations from the beginning of history, has been about 200 years.During those 200 years, these nations always progressed through the following sequence:From bondage to spiritual faith;
From spiritual faith to great courage;
From courage to liberty;
From liberty to abundance;
From abundance to complacency;
From complacency to apathy;
From apathy to dependence;
From dependence back into bondage

I told my Dad that it looks and smells like spam.  A quick read shows that it is a generalization from a sample of one.  The Roman Empire lasted about 500 years. The Ottoman Empire lasted over 700 years. The British Empire lasted about 200 years from 1783 to 1997 (withdrawal from the Falklands).  The Russian Empire lasted 200 years and the Soviets lasted less than 80. The Byzantine over 1000 and so on… See http://listverse.com/2010/06/22/top-10-greatest-empires-in-history/.

Rumors of the downfall of American democracy are premature, even though the US is more of a service economy than a manufacturing economy today than it was 200 years ago.

The US has shifted over the past 40 years from manufacturing and technology innovation to technology innovation, retail, outsourcing and financial services.    An obvious observation is Apple, with most of it’s manufacturing jobs outside the US, a net worth of a not-so-small country and perhaps, the most outstanding consumer technology innovator in the world. Another, and more significant example is Intel, one of the world’s technology leaders with a global operation from Santa Clara to Penang to China to Haifa and Jerusalem.  World class companies like Intel and Apple are a tribute to US strengths and vitality not weaknesses. In comparison, excluding Germany, Poland and a handful of other European countries, the EU is on the edge of bankruptcy.

In this period of time, has the US improved it’s information security in the face of rapidly increasing connectivity,  mobile devices and apps and emerging threats such as APT (advanced persistent threats)?

Apparently not.

The sheer volume and fragmented state of US data security and privacy regulation is practically a guarantee that most of the regulation will not be properly enforced.

On the other hand, the unified nature of EU data security directives makes it easier to enforce since everyone is on the same page.

We would argue that a free market, American style economy results on more technology innovation and economic vitality but also creates a chaotic regulatory environment where the breach of 300 million US credit cards in less than 10 years is an accepted norm. The increase in compliance regulation by the Obama administration does not impress me as a positive step in improving security.

As my colleague, John P. Pironti, president of risk and information security consulting firm IP Architects, said in an interview:

The number-one thing that scares me isn’t the latest attack, or the smartest guy in the street, it’s security by compliance, for example with PCI DSS 2.0

Security by compliance, he said, doesn’t do a company any favors, especially because attackers can reverse-engineer the minimum security requirements dictated by a standard to look for holes in a company’s defense.

In that case, if a little compliance creates a false sense of security then a lot of compliance regulation will create an atmosphere of feeling secure, while in fact most businesses and Web services are in fact very insecure.

After reading the excellent article  by Sarah Leibowitz-Dar in the Maariv weekend edition, I realized that there is 1 constraint in Israel for improving data security:

בועז גוטמן, מקים המפלג לפדעי מחשב במשטרת ישראל.”

יש היום במשטרה חוקרי מחשב טובים שיודעים לקרוא ולכתוב אנגלית

Boaz Gutman, former Israeli police officer who started the computer crimes unit says that Israeli Police have good police officers who know how to read and write English.  If we had 30 instead of 20 we would be able to handle the case load

That one (1) constraint for improving data security in Israel and preventing credit card breaches is quite simply that most Israelis, including members of Knesset, the Police and Army simply do not understand English.

English after all, is not Israelis’ native tongue.   Israelis all use the Hebrew interfaces on their cell phones, use the Hebrew interface in Microsoft Office and send messages to each other on Facebook in Hebrew.

If Israelis spoke English fluently or at least understood English fluently they would be aware that there is a whole wide world out there where credit cards are stolen and Web sites need to be protected.

But no, we are like a small group of Jews living in a Russian shtetl and we do not know that there is an America out there.

Here we have Ms. Leibowitz and a bunch of  other Israeli journalists getting worked up over a fairly elementary hacking event resulting in the leakage of 14,000 credit cards from Israeli  Web sites.

If they would read English, they would know that in the past 6 years over 300 million credit cards have leaked in America.

In other words, your credit card is already out there. And life just goes on.

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.

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.

A recent post “Can smartphones replace credit cards” wonders whether or not consumers are ready to  trade in their plastic for their cell-phone.

Mobile payment technology has been around for about 10 years and it has not really taken off in a big way – although there are niche applications.  In Tel Aviv for example, you can buy drinks in vending machines with your cell phone and pay for parking.

Clearly it’s not a technology barrier to entry but a cultural barrier to entry.

I had the privilege and then the scars to pay for that privilege, to be the chief technology officer for a startup called One Credit in 2001-2.  The idea was based on the fact that Americans carry around an average of 5 credit cards with a bewildering array of payment terms and conditions, APR, special deals, coupons, travel points, insurance and extended warranties etc. With multiple cards and difficult-to-grok terms and conditions, there is an opportunity to arbitrage between the cards and get the card holder the best deal on every transaction.   The startup tanked together with the rest of the dot.com boom but the idea had some merit apparently, as less than 3 years later, First USA launched a payment card with most of the features of the One Credit card we had designed (and also pitched to First USA among others….).

One of the features in the One Credit card was payment confirmation using location services and a smart cell phone.  If you receive a payment confirmation request for your credit card on your smart phone, and you’re currently in a meeting with a client in Singapore, you can deny the request – or confirm it, perhaps you made a purchase online at Amazon.  Visa launched a payment confirmation service for the Android in the US about 2 years ago – I’m curious how many card holders are actually using the service. As of now (September 2010) the Visa Web site only shows one issuer participating – USBank, which doesn’t suggest widespread adoption.

I would have to do a more detailed threat analysis and consider some of the software, people and networking vulnerabilities involved in using an iPhone or Android for mobile payments, but it seems almost a certainty that mobile payments or at the very least mobile payment confirmation could go a long way towards improving data security of payment cards and reducing (perhaps drastically) the quantity of identity theft due to stolen cards.

So once again – we have the technology to make mobile payments happen but my nose is telling me that the consumers are not ready  yet.

As a consumer, having your online banking account credentials stolen — either via phishing or through password-stealing malware — can be a nasty experience, but it is  not a costly one. The federal Electronic Funds Transfer Act (“Regulation E”), limits consumer liability for unauthorized transactions to $50, provided notice is given within 10 business days, or to $500 provided notice is given within 60 business days. Even so, retail banks often will work to make whole those customers who are victims of online fraud.

On the other hand, SMB that bank online do not have consumer protection. The obligations of a commercial bank and their business customers are spelled out in the agreement that both parties sign;  generally business customers agree to notify their bank of any suspicious or unauthorized transactions on the same day that the transaction in question occurs. There is no guarantee that the bank will be able to block or reverse any fraudulent transfers, and since most SMB don’t perform real time transaction or data loss monitoring – the chances of complying with the agreement are slim.