Product security: Not just bells and whistles

Security must be considered in every aspect of the product life cycle, from the initial drawings on a whiteboard through the first and all subsequent development cycles.


A vulnerability was disclosed this past week affecting insulin pumps made by Johnson & Johnson. These devices, controlled via a wireless remote, lack any means of ensuring that only the intended remote could control the pump. A motivated individual in close proximity to the user could, in theory, cause their injury or death by significantly increasing the amount of insulin being administered.

There have been numerous similar product vulnerabilities disclosed in recent months, including a disputed report involving cardiac devices made by one manufacturer. Some have said that unaddressed vulnerabilities are common in healthcare because it is such a financially sensitive industry, with its leaders not wanting to spend extra money to get a more secure product that performs the same medical function. As the hosts of the Down the Security Rabbithole podcast said in this week's broadcast, however, all industries are finally sensitive.

Sadly, the problem is not restricted to healthcare. Recent example in other areas include vulnerabilities in the popular Nest Thermostat, and the lack of authentication between sensors and the base of the Simply Safe alarm system, with no ability to change the firmware to correct it. While none of these are thought to be serious at this point, it indicates a disturbing pattern that pervades a variety of industries, including those that make internet of things (IoT) devices, as well as more traditional hardware and software products.

Why does this pattern of vulnerabilities exist? I would suggest that it is caused, in large part, by the failure of product developers to include security as a part of the architecture of their products from the beginning.

Some months ago, I was asked by a company planning a new software product in a key industry to advise them about how to properly include security during the development of the software. I spent a good bit of time with them, and they were quite attentive to what I had to say. At the end of the consultation, they assured me that they would incorporate security in a development sprint later in the product cycle.

My interaction with this company highlights the real problem we face with product security today. Security must be considered in every aspect of the product life cycle, from the initial drawings on a whiteboard, through the first and all subsequent development sprints, and through product documentation, support, training and enhancements. I would suggest that it is impossible to "hang" security onto an existing or partially developed product like a bell or whistle.

If we continue to develop products like we always have, with security as an add-in, or at best, an unloved product stepchild, we will continue to see the same insecure results. Instead, we must learn to design products that incorporate strong security in the basic architecture of the product, and continue to improve it in subsequent versions, taking into account new vulnerabilities and hacking techniques.

If you are planning or developing a product, hardware, software or IoT, keep the following points in mind:

Security needs a champion

If left to the whims of product designers or developers, security will almost always be subordinated to fancy features that make the product more attractive from a sales standpoint. Sadly, as the saying goes, pay me now, or pay me later.

If you ask Johnson & Johnson if it wishes it had focused more on security from the beginning of its insulin pump design, I have no doubt about what the answer would be. To ensure strong security, someone who is removed from the product functional design must be designated to ensure that security is considered during all phases of product development, starting with the first day of planning.

Assess your risks

I suspect my regular readers may be tired of hearing me recommend formal risk assessments, but they are essential to good security design and ongoing maintenance. You need to figure out what your risks and vulnerabilities will be early in the process, and have a plan to address them. This assessment must be updated regularly. You can get guidance for this from my article "The dreaded risk assessment."

Follow industry best practices

There are a variety of good sources for guidance on secure product development. Look for such guidance specific to your particular industry, or more general sources, such as Future-proofing the Connected World, developed by the Cloud Security Alliance.

Scan early and often

In recent months, I have looked at formal risk assessments for a large number of products. I am still amazed at the number of developers who do not run full vulnerability scans on their products. More surprisingly, some of them are household names most would recognize.

Vulnerability scans must be part of your routine process for intermediate versions, as well as the final product. It is also helpful to have scans performed periodically by a disinterested third party, to avoid any bias on the part of product developers.

Plan for failure

As noted above, Simply Safe discovered that its alarm system was subject to compromise because its sensors did not encrypt transmissions to the base station, allowing an attacker to spoof a sensor. This would likely be a relatively easy problem to fix, except that Simply Safe made no provision for the product's firmware to be upgraded.

Realistically, we will never be able to squeeze all vulnerabilities out of products, in part because this is a moving target. Assume, therefore, that vulnerabilities will ultimately be found. Continue to test your products against the latest hacking techniques and exploits, and design in a means of updating the products.

Bottom line: Product vulnerabilities will always exist, to some extent. By including security in the design of a product from its first outline drawn on a napkin at lunch, you will minimize unpleasant surprises down the road, and be ready for them when they do happen.

Copyright © 2016 IDG Communications, Inc.

Make your voice heard. Share your experience in CSO's Security Priorities Study.