Monthly Archives: June 2011

Practical security management for startups

We normally associate the term “small business” or SME (small to medium sized enterprise) with commercial operations that buy and sell, manufacture products or provide services – lawyers, plumbers, accountants, web developers etc…

However – there is an important class of small business operations that is often overlooked when it comes to information security and is the technology startup.   A high tech startup is an SME by all definitions – usually less than 50 employees but it doesn’t buy and sell and neither does it provide professional services.   Unlike other small businesses, a high tech startup is almost purely focussed on product research and development. Almost all startups have a very high percentage of software development. Even if the startup develops hardware – there is still a strong software development focus.

Intuitively – one would say that a primary concern for a startup is IP (intellectual property) protection and that starts with protecting source code.

Counter-intuitively this is not true. There are two basic reasons why source code leakage is not necessarily a major threat to a startup:

1) If the startup uses FOSS (free open source software), there is nothing to hide.  This is not strictly speaking correct – since the actual application developed using FOSS has immense value to the startup and may often involve proprietary closed  source code as well.

2) A more significant reason that source code leakage is of secondary importance is that a startup IP is invariably based on a combination of three components:    Domain expertise, implementation know-how and the implementation itself (the software source code).   The first two factors – domain expertise and  implementation know-how are crucial to successful execution.

The question of how to protect IP still remains on the table but it now is reshaped into a more specific question of how best to prioritize security countermeasures to protect the startup’s domain expertise and  implementation know-how.  Prioritization is of crucial importance here, since startups by definition do not generate revenue and have little money to spend on luxuries like data loss prevention (DLP ) technologies.

Software Associates works exclusively with technology and medical device developers and I’d like to suggest a few simple guidelines for getting the most security for your money:

The startup management needs to know how much their information security measures will cost and how it helps them run the business. Business Threat Modeling (TM) is a practical way for a manager to assess the operational risk for the startup in dollars and cents. The advantages of the business threat modeling methodology are:

  • Threat modeling places the focus on asset management and Value at Risk reduction before acquisition of information and security technologies.
  • Threat modeling helps select  the right countermeasures often prioritizing monitoring before active data loss prevention (for example)
  • Threat  modeling, when done right, quantifies risk in dollar terms. This is particularly important when reporting back to the investors on exposure to data loss of IP.
  • Threat modeling helps justify investments in security, compliance and risk management to the management board – simply because it puts everything into financial values – the value at risk and cost of the security portfolio.

These are similar objectives to GRC (Governance, risk and compliance) systems.

The problem with most GRC (governance, risk and compliance) and ERM (enterprise risk management) systems is that they don’t calculate risk, they make you work hard and they’re not that easy to use.

I think that we can all agree that the last thing that a hi-tech startup needs is a system to manage GRC activities when they’re working to make the next investor milestone.

Startup management needs a simple security management approach that they can deploy themselves, perhaps assisted with some professional consulting to help them get started and get a good feel for their exposure to security and compliance issues.

How does a practical security management methodology like this work? Well – it works by using common language of threat modeling.

You own assets – for example, expensive diamond jewelry stored at home. These assets have a dollar value.

Your asset has vulnerabilities – since you live on the ground floor and your friendly German Shepherd knows where the bedroom is and will happily show anyone around the house.

The key threat to the asset is that an attacker may break in through the ground floor windows.

The countermeasures are bars for the windows, an alarm system and training your dog to be a bit less friendly around strangers with ski-masks.

Using countermeasure costs, asset value, threat probability of occurrence and damage levels, we calculate Value at Risk in financial terms, and propose an prioritized, cost-effective risk mitigation plan.

That’s it – adopt a language with 4 words and you’re on a good start to practical security management for your high tech startup.

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

The cloud concierge

The Israeli ISPs are really really bad.  Just abysmal. It hurts me just to think about the level of customer service and data security incompetence that would make an Iraqi ISP running an operation in a store front beam with pride.

I assume that we are not the only business to suffer from Netvision (and Bezeq International and 012).

Perhaps there is a business opportunity for a “cloud concierge” service  that would provide a VIP front end to the best of the international cloud service providers but with a local presence.  The cloud concierge would help customers select and implement the right product,  application, security and provide a guaranteed SLA using unbunbled services from providers like dnsmadeeasy, rackspace and peer 1.

My wife doesn’t get it. She asks: “What is the concierge angle here?  I reply – “How do you get basketball tickets, a recommendation to a good restaurant and a local metro card in a foreign country without the hotel concierge?”

Hmm., she says. “OK, now I get it. but how are you gonna make money out of it when anyone can google for cloud services?”

Got me there babe. Right to the bottom line. Then again, she already has a celebrity stylist service to buy shoes online. Why on earth would she need a cloud concierge?

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

The Microsoft monoculture as a threat to national security

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

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

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

This was in September 2003.

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

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

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

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

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

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

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

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

Similar to the history of data security breaches of retail systems, the medical device software industry is (or may soon be) facing a steeply increasing curve of data security and patient safety events due to the Microsoft monoculture.  We are not in Kansas anymore – not credit cards being breached, but entire hospital networks infected by Microsoft Windows viruses and patient monitoring devices that stop working because they got blue screens of death.  Since 300 million credit cards have been breached, it is a reasonable assumption that your card and mine is out there. The damage to your credit card being breached is minimal.  But, if your child was on a patient monitor that went offline due to a Microsoft Windows virus and a critical condition was not detected in time; it’s the difference between life and death.

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

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

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

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

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

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

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

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

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


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

Medical device security in a hospital network

Medical devices are everywhere today.  In your doctors office measuring your blood pressure, at your cosmetician (for hip reduction…) and in the hospital for everything from patient monitoring to robot-assisted surgery.

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.

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