Tag Archives: Software security

Microsoft gives source code to Chinese government

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

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

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

Hold on.  That announcement was in 2003.

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

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

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

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

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

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

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

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

See my essay on the economics of software piracy.

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

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

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

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

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

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

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

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

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

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 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 trends

Hot spots for medical device software security

I think that 2011 is going to be an exciting year for medical device security as the FDA gets more involved in the approval and clearance process with software-intensive medical device vendors. Considering how much data is exchanged between medical devices and customer service centers/care givers/primary clinical care teams and how vulnerable this data really is, there is a huge amount of work to be done to ensure patient safety, patient privacy and delivery of the best medical devices to patients and their care givers.

On top of a wave of new mobile devices and more compliance, some serious change is in the wings in Web services as well.

The Web application execution model is going to go through an inflection point in the next two years transitioning from stateless HTTP, heterogeneous stacks on clients and servers and message passing in the user interface (HTTP query strings) to WebSocket and HTML5 and running the application natively on the end point appliance rather than via a browser communicating to a Web server.

That’s why we are in for interesting times I believe.

Drivers
There are 4 key drivers for improving software security of medical devices, some exogenous, like security, others product-oriented like ease of use and speed of operation.  Note that end-user concerns for data security don’t seem to be a real market driver.

  1. Medical device quality (robustness, reliability,usability, ease of installation, speed of user interaction)
  2. Medical device safety (will the device kill the patient if the software fails, or be a contributing factor to damaging the patient)
  3. Medical device availability (will the device become unavailable to the user because of software bugs, security vulnerabilities that enable denial of service attacks)
  4. Patient privacy (HIPAA – aka – data security, does the device store ePHI and can this ePHI be disclosed as a result of malicious attacks by insiders and hackers on the device)

Against the backdrop of these 4 drivers, I see 4 key verticals: embedded devices, mobile applications, implanted devices and Web applications.

Verticals

Embedded devices (Device connected to patient)

  1. Operating systems, Windows vs. Linux
  2. Connectivity and integration into enterprise hospital networks: guidelines?
  3. Hardening the application verus bolting on security with anti-virus and network segmentation

Medical applications on mobile consumer devices (Device held in patient hand)

  1. iPhone and Android – for example, Epocrates for Android
  2. Software vulnerabilities that might endanger patient health
  3. Is the Apple Store, Android Market a back door for medical device software with vulnerabilities?
  4. Application Protocols/message passing methods
  5. Use of secure tokens for data exchange
  6. Use of distributed databases like CouchDB to store synchronized data in a head end data provider and in the mobile device The vulnerability is primarily patient privacy since a distributed setup like this probably increases total system reliability rather than decreasing it. For the sake of discussion, CouchDB is already installed on 10 million devices world wide and it is a given that data will be pushed out and stored at the end point hand held application.

Implanted devices (Device inside patient)

  1. For example ICD (implanted cardiac defibrillators)
  2. Software bugs that results in vulnerabilities that might endanger patient health
  3. Design flaws (software, hardware, software+hardware) that might endanger patient health
  4. Vulnerability to denial of service attacks, remote control attacks when the ICD is connected for remote
  5. programming using GSM connectivity

Web applications  (Patient interacting with remote Web application using a browser)

  1. Software vulnerabilities that might endanger patient health because of a wrong diagnosis
  2. Application Protocols/message passing methods
  3. Use of secure tokens for data exchange
  4. Use cloud computing as service delivery model.

In addition, there are several “horizontal” areas of concern, where I believe the FDA may be involved or getting involved

  1. Software security assessment standards
  2. Penetration testing
  3. Security audit
  4. Security metrics
  5. UI standards
  6. Message passing standards between remote processes
Tell your friends and colleagues about us. Thanks!
Share this

Customer security with software security

If you are an IT person, this article may be a waste of your time. But – if you are in the business of making and delivering products with software inside – read on.

What threats really count for your business?
No question is more important for implementing an effective security and compliance program for your product development. The management, the software developers and security analysts cannot expect to mitigate risk effectively without knowing the sources and cost of threats to company products and the products’ users.

The prevailing IT security model predicates defense in depth of IT systems. The most common strategies are to mitigate external threats with network and application security products that are reactive countermeasures; blocking network ports and services, detecting known application exploits, or by blocking entry of malicious code to the network. Are any of these security countermeasures likely to be effective in the long-term for software applications and software-based appliances? Can attacks on a software product be neutralized with defensive means only? In other words, is there a “black-box” security solution for your products?

The answer is clearly no.

A reactive network defense tool such as a firewall cannot protect exploitation of software defects and an application firewall is no replacement for in-depth understanding of company-specific source code or product configuration vulnerabilities.
This paper presents a rigorous software development process for delivering secure software product starting with a simple notion – “buggy software is insecure software”.

By removing software defects we are in the best position to deliver secure software to our customers.

Download the full article Make your business secure by making your software secure

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

Software security assessments

In a way, every software security assessment is an exercise in software development. The first step in the software security assessment project is requirements analysis. Requirements analysis is concerned with what the system (whether it be a “traditional” application or a rich Web 2.0 application for social networking) needs to do. This involves examining the requirements of the business itself, the users of the application against the backdrop of cost and engineering constraints such as throughput and response time when the application is deployed on a cloud computing platform.

Business Requirements

  • Business Requirements analysis – Describe the business and its it’s customers, suppliers and users, problems, issues and expectations. This is essential when developing a new application, but also crucial when you’’re making significant changes to an application. “Why” do you want to develop the software and “how much” is it going to cost? Is there a ROI (return on investment). Can your team develop and implement the product?
  • P.I.E – – Problems Issues and Expectations – Describe current problems and put the issues and expectations that users have in the current environment into separate categories. An expectation may be crucial to success of the project or it may be a “user satisfaction” feature that can be postponed to Revision 9.5
  • Causes and Consequences – Discuss causes of current system problems and their consequences. You will discover that a problem’s result is often a problem in it’s own right. You need to drill down to the root cause of the problem peeling away the symptoms.
  • Target system tasks – Discuss and observe users as they work with the software application. Remember that the important things are (a) how easy it is to install/start using a product (b) how fast it works and c) how intuitive is the UI. This is particularly relevant to Web-based applications, where the user experience will make or break the application.
  • System Design Alternatives Analysis – Very few systems are new. In alternatives analysis you will consider the strengths and weaknesses of existing approaches including not doing the project at all.

Software security requirements

A business requirements analysis is not enough to ensure that a system meets the real needs of its users or that it will ever succeed in the real world as a product. In fact, reducing a system specification to a set of required functions, without regard to how the functions are used or how they will be implemented in real hardware/software by real people is a guarantee for failure . The design of a new system or major change will usually involve the following steps:

  • Task Decomposition – Business requirements are broken down and mapped into software and hardware modules and features.
  • User stories– A “user story” corresponds to a feature of a system module. Stories are small, typically limited by an estimate to implement the software for a story by one programmer working for one week. The user story needs to stay in sync with the business requirements – and stay away from gold-plating.
  • Data Modeling – Data modeling describes the data elements in the assessed system and the relationships between the data elements. Done in parallel to developing the “user stories” and ensures that the data needed to do the job is on the model.
  • User Interface Design – The user interface needs to be considered at an early stage in the software security assessment cycle. Functional requirements are combined with the knowledge gathered about users and contexts of use to provide the most appropriate methods of interaction.
  • Incremental assessment by prototyping – Assess a little piece of the system with selected routines and a  UI.  Security assessment prototyping allows vulnerability hypotheses to be tested, with resulting feedback incorporated into an iterative process of software defect reduction. Early prototypes may be purely paper-based to test the design or using a the application to test the software in vitro.
Tell your friends and colleagues about us. Thanks!
Share this

Information security best practices workshops

Information Security Best Practices

Every Thursday at 14:00 GMT  we host a best practice security workshop online for business professionals, vendors and consultants. There is a short high-quality presentation and we share  knowledge gained in the  trenches. It’s 20 minutes, it’s free and it’s always a lot of fun.

Register Here you will receive a confirmation email with a link to the webinar.

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

Security Leadership

Gas prices may go down and  electricity may get cheaper –   but In 2009, most of us  will have less money to spend and our clients will be tough on pricing and orders. For information security and compliance professionals it is the time to find, implement and enforce cost-effective security countermeasures. BUT HOW? Continue reading

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