print

IoT Security: New Vulnerabilities

As apps proliferate, are security practices finding their place in the workflow?

The Internet of Things (IoT) has already brought new levels of connectivity and engagement into the lives of so many, yielding everything from small conveniences to extraordinary automation, personalization and efficiency.

But new technologies inevitably bring new security vulnerabilities, and the IoT is particularly susceptible to malicious attacks and the potential exposure of sensitive data. As more devices become connected in new ways, everything from toys to TVs and thermostats becomes part of a larger network of remotely connected items, and those items and connections are often less secure and more exploitable than more commonplace computers and mobile devices.

Internet-connected devices such as refrigerators, Smart TVs, smart thermostats, and connected security systems are sometimes developed and deployed without traditional IT security protocols.

Internet-connected devices such as refrigerators, Smart TVs, smart thermostats, and connected security systems are sometimes developed and deployed without traditional IT security protocols.

The big picture perspective shows a fundamental disconnect between the application development community and IT security frameworks and procedures. Organizations and developers are building new devices and developing new apps very rapidly, and they are not necessarily integrating traditional security standards and practices into their workflow. All too often consumer goods and products are rushed to market in order to beat the competition. This leads, in many cases, to the checks and balances of a security and review process—such as enterprise applications undergo—to be either compromised or entirely absent.

As awareness of these potential vulnerabilities grows, embedded system developers who want to learn how security issues with the IoT can be addressed have many avenues. As developers come to appreciate the nature of these vulnerabilities, they should take the time to familiarize themselves with the principles and practices associated with limiting exposures and closing the security loopholes that are present with so many connected systems, devices and applications.

Nothing to Toy With

The list of high profile security breaches of connected devices is extensive—and growing all the time. One major toy manufacturer was recently burned when it turned out that a significant vulnerability was present in some of their connected toys. Specifically, within the cloud services that the toys communicated with. The services’ vulnerability, coupled with the company’s collecting an unnecessary depth of personal information from its customers, made for a worrying combination. Not only were flaws found in the products, but the excessive sensitive personal information that was being gathered was not secured in the central database and was not being transmitted to their website in a secure manner.

The potential for similar security breaches exists with home appliances, like Smart TVs, refrigerators, smart thermostats and connected security systems. All of these Internet-connected devices are sometimes developed and deployed without traditional IT security protocols.

Arguably the biggest issue contributing to these vulnerabilities is an accelerated development lifecycle that results in apps and products that have been designed and developed without going through rigorous security checks and balances. Timeline and financial pressures from the business side of an organization make it more likely that these expedited processes will continue. Another factor is the relative lack of maintenance and update capabilities in many of these devices. In some common real-world examples where devices or applications were compromised, it has taken organizations up to a year or more to roll out a satisfactory fix.

To put that into context, consider how frequently our laptops and other connected mobile devices are updated with new security patches. Because some of the companies that develop, manufacture and distribute connected devices often do not have the backend technical and development infrastructure in place to address these security issues properly, their ability to respond when vulnerabilities emerge is limited and often sluggish, at best.

Security updates are a concern for many companies in many different scenarios. In the Jeep hack that received so much attention nationally, Jeep owners who were not able to perform the USB software update themselves had to bring their vehicles into the dealership to address the security issue. Expecting end-users to update their software is most likely an ineffective solution.

Code will never be perfect. Much of it is recycled and the threat landscape is always changing as new vulnerabilities emerge. Secure development up-front is critical, of course, but so is offering a way to provide updates going forward. This is one of the issues that can be addressed by following some straightforward security strategies and best practices.

Security Strategies and Best Practices

Think Like a Bad Guy

Developing secure products and applications requires secure coding and development, but also regular, robust and defined testing to evaluate different features as you develop and ensure that finished products are free from security defects. All of that starts with educated and informed developers, and it also helps to have someone involved in testing who thinks like a bad actor and understands how to hack and how to exploit common vulnerability points. This “attacker” can offer invaluable feedback into specific concerns as well as general insight on the malicious party mindset.

Turn Off Unnecessary Features

Another security strategy for developers is to make sure that they are developing in a way that makes it easy to “turn off” features that are not entirely necessary before the products go out the door. Any unnecessary coding or functionality is just another potential vulnerability, and minimizing that exposure should be a priority. ATM manufacturers, for example, had to learn the hard way to strip out nonessential functionality. Some ATMs, which are essentially purpose-built computers, used to run a modified version of Windows XP, and hackers were able to exploit vulnerabilities in the software that had nothing to do with the operation of the ATM.

Trusted source-Dependent Updates

The ability to update devices remotely sounds good, but developers need to make sure that functionality is designed in such a way that the device can only get updates from a trusted source. When possible, have the device run a check on the software to make sure it is from a trusted source before accepting updates. The update process should not only require trusted firmware, but should also be an opt-in feature (making it easy to accommodate less tech savvy users) and should include the ability to opt-out or to rollback an update (either remotely or through a user-initiated process).

Minimize Callbacks and Connections

To the extent that it is possible, products and processes should be structured to minimize callbacks. It goes without saying that any information gathered or transmitted should be anonymized, but it is also important not to gather information that isn’t needed in the first place. Some organizations have a tendency to build systems that call back too often and transmit too much information. The general idea is that while you want those lines of communication open (to allow for updates and fixes), you do not want them too open (any channels should be safe, secure and limited, and only used when absolutely necessary).

The beauty of so many of these connected products is that they are so convenient. In fact, many have smartphone apps associated with them. From a security standpoint, however, that is just another point of vulnerability. And, when you consider for a moment that the network your thermostat is on is the same network that you may rely on to do your taxes and to store and transmit a wide range of sensitive personal information, that vulnerability becomes a very real concern. System developers need to be doing their part to adhere to security principles to protect the consumers.


Barone_thumbSteve Barone is CEO of CBI, a Michigan-based provider of IT risk management services and solutions that help organizations across every industry ensure their data is secure, compliant and available. For more information, visit www.cbihome.com

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • TwitThis