Tag Archives: Buggy software

Build management and Governance

Don’t break the build.

There is absolutely no question that the build process is a pivot in the software quality process. Build every day, don’t break the build and do a smoke test before releasing the latest version.

This morning, I installed the latest build of an extremely complex network security product from one of our customers and lo and behold, one of the most basic functions did not work (and has not worked for about 3 revisions now apparently). Wrote a love letter to the customer service and QA managers and chided them for sloppy QA.

An article I saw recently, talks about the “confluence of compliance and governance” and the direct link to software quality. If you read Jim McCarthy’s classic – “Dynamics of Software Development” you will remember the chapter called Don’t break the build.

You may be using Linux make, Microsoft nmake or Apache Ant but in all cases, the build expertise of the person running the build is more important than the tool itself. the development team runs a daily build with a build-meister personally responsible for running the construction of a working system from all the components. If the build breaks he doesn’t go home.

It is better to have a non-programmer do the smoke-test before the final release to manufacturing. A person outside the engineering team does not have the blinders or personal interest to ignore basic functionality that gets broken ( not to mention having motivation to one-up the engineers).

Anyhow, maybe there is still hope if the compliance gurus have discovered software quality.

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

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

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

2009 CWE/SANS Top 25 Most Dangerous Programming Errors

I’ve been telling customers for years that most security exploits are caused by a small number of software defects (you can download my white paper on Software Security and see how to mitigate enterprise software vulnerabilities systematically using Business threat modeling

Still it’s amazing how the trade press are gushing on this – must have been a slow news day – or maybe the SANS/MITRE folks paid a bit extra to their PR people. The SANS Institute have been publishing a SANS Top 10 for years but this work is much more comprehensive and detailed.

Even if there is not cosmic news involved (“validate input”, “don’t give too much authorization” etc…) perhaps the tail wind from DHS will help more software vendors get with the agenda of writing more secure code. Schneier may have his wish come true – if the Top 25 gets written into purchasing contracts.

Cynicism aside this is a GOOD thing – click here for the CWE Top 25 software bugs

I’m looking at a PHP application right now (doing an initial software security assessment and I’m seeing stuff like URL hacking, and non-validated input – stuff like:

SQL Error: ERROR:  invalid input syntax for integer: 
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
Tell your friends and colleagues about us. Thanks!
Share this