Basic Requirements for any Network-Connected Device

In a couple of recent blog posts by Jim Boxmeyer (e.g., Help, I was Betrayed by my Cloud Enabled Smart Fridge!), he pointed out our trend toward more and more network-connected devices and the potential hazards that may ensue.  Jim’s account is not exclusively for the future; these sorts of problems exist today.  While Jim made light of the situation, we should be concerned about the ramifications of more and more network-connected devices.  Being betrayed by a refrigerator is one thing.  Consider the implications of millions of refrigerators, televisions, DVD players, printers, game consoles, tablets, computers, weather stations, MP3 players, and book readers.  What if even a small fraction of these were to come under the control of criminal hackers or cyber-warriors?  These devices are connected to the private networks in our homes, stores, offices, manufacturing facilities, banks, power plants, hospitals, military, and many others.  These criminals could steal information, collectively clog networks with DDoS traffic, or act as go-betweens to take over control of critical systems.  As this article is being written, we are aware of a growing botnet that is exploiting network-enabled security camera DVRs.  These devices have many of the attributes that botnet operators desire:

  • They are turned-on all the time
  • They are not protected by anti-virus software
  • They likely have no automated software update process

And we are wondering, what should we do about this growing problem?  In Jim’s blog on Embedded Systems and Security, he suggested the following:

“It is time to educate consumers about the dangers that lurk within embedded devices. Companies marketing these embedded systems need to take security into consideration when developing and selling them.”

Jim is right, but this is not enough.  There should be some basic requirements for any reputable network-connected device, and we should not buy devices that do not satisfy these basic requirements.  While the suggestions below will not inherently make devices any more resistant to hacking or unauthorized manipulation, they can provide some means to correct problems when they arise. (Notice – I said “when they arise” and not “if they arise.”)

Software Update Capability – Every network-connected device should have a means for owners to update the software.  In this age of complex software, there will be flaws in the software for even the most basic products.  Consequently, there must be a way to update the software on any product that provides network connectivity.  And this capability must be something the owner and/or user of the device can control.  Ideally, this process should be automated to a large extent — perhaps entirely.  For example, the device can periodically poll the manufacturer to determine if software updates are available.  And the user should be prompted when updates are available — asking permission to perform the update.  The update process should use a cryptographic check to assure any update is from the authorized source prior to committing the installation.

Support Should Be Readily Available — Support for any network-connected device should include online access to an up-to-date owner’s manual, access to software updates, and software update instructions.  There should also be a clear definition from the manufacturer on the supported product lifecycle – including software.  Generally, product support for appliances is about 7 years.  I think this the software support lifecycle for products should extend the full life expectancy of the product.

Contact Information and Support Forum – There should be a contact to report any problems with the product or software.  The most transparent and preferable is a support forum, where users’ reports of questions or problems can be reported in a publically accessible and searchable location, and responses from the manufacturer are provided.  This not only can help streamline the search for assistance, it also helps consumers understand what they can expect from the product they are buying and determine if fixes are available.

Basic Support Label – Information should be readily marked on the device that helps the owner find support information.  This support information should include at least a URL that points to a website where a user or owner can seek support for the product.  The label should also clearly and unambiguously mark the model number to assure the correct support information can be found for that specific product.  With such exchange forums as Craigslist and Ebay, used items are bought and sold more frequently than ever before.   And with those exchanges, the paper manuals and packaging are not always included.  The new owner needs to know how to assure their purchase can be supported.

System Reset – There should be a way to reset the device to its original manufactured state, including the software load.  If a device is infected with malware, we need a way to be able to restore a known “clean” state.  In some cases a software update may entirely replace the old software image, which may be sufficient.  However, as systems are becoming more complex, we should not expect this type of solution to continue.

No Default Password – In our weekly AT&T ThreatTraq program, we report weekly on literally billions of probes that are conducted on the Internet looking for devices, systems, and applications that are vulnerable.  Often, these probes are looking for systems that are using default and guessable passwords.  There is no reason these probes should ever be successful, but they are successful all too often.  Every device needs to have a “default” setting – the point at which the device has not yet been configured for operation.  Typically, the default setting establishes a well-known password for access to the device, no encryption, easy access, and effectively no security.  This is done for convenience; to avoid product support costs for the manufacturer.  Unfortunately, these devices using default settings are a hacker’s dream, and the savings for the manufacturer can become quite costly for a owner/victim.  Even if there is no defined manufacturer software update procedure as suggested above, a weakly-selected or default password allows hackers to gain access to devices, and often hackers can devise their own software update process and inject malicious software into devices.  A product that is starting from a reset state or “default” setting should not connect to any network until minimally appropriate security settings are configured.  At a minimum, set-up prompts should require the user to define a unique and reasonable password for access from a network interface.

Many of the above suggestions are in common practice in more sophisticated software systems and are common practice with smart-phones.  It is time we recognize any network-connected devices as a sophisticated software system and expect the necessary support to help keep them secure.

The question remains, how do we get enough energy behind this to make it happen? Are you making headway on updates, security, and support for your network-connected device?
Brian Rexroad Executive Director of Threat Analytics AT&T About Brian