In the IoT & Beyond, Security Resides On The Dark Side, Part Two

Embedded Bits, Bytes & Sensors by Mat Dirjish and Nick Ashworth

In the first installment of this look at the security risks associated with the emerging data wave dubbed the Internet of Things (IoT), we spoke with Captain Brent Chapman of the US Army. Of the numerous attack-and-hack trends emerging over the years, he singled out two practices of particular interest.

First, the easy access to powerful, yet inexpensive computers and free software has caused an increase in "hactivism", characterized by the misuse of computer systems to further a social or political cause. The second trend is hackers abusing weaknesses in non-traditional network-connected products. Using commandeered baby monitors for example, criminals have verbally abused children, sent ransom messages to parents and even used the camera as a reconnaissance tool before burgling the residence.

This time around, I pose the same questions to Nick Ashworth who is the Engineering & Technology Director with Eaton's Energy Automation Solutions business and the Treasurer for IPSO Alliance. He has over 20 years of experience developing connected products for home automation and smart grid applications.

MD: Cyber threats have gone way beyond the antics of mischievous hackers and identity thieves. Although financial institutions are always fair game for cyber thieves, government and military institutions are becoming prime targets for both cyber invasion and terrorism. Currently, what do hackers have in their sites beyond the typical targets such as banks, individual citizens, and commercial outlets?

Nick Ashworth: Most widely publicized security breaches seem to fall into three categories. The first are those that are motivated by national security, political interests or activism. Stuxnet is an example of an alleged state-sponsored virus that was designed (and succeeded) to set back the uranium enrichment program of Iran. In this case, the devices targeted were Siemens industrial control devices. In a report published last week, the US Department of Homeland Security (DHS) states that in December 2015, coordinated remote cyber intrusions at three regional electric power distribution companies resulted in power loss to 225,000 customers in western Ukraine. This incident was linked to a Russian hacking group. Clearly states and/or political hacktivists are using technology as a weapon in this new battlefront.

Secondly are security breaches that are motivated by financial interests. These types of attacks range from spear-phishing attacks on individuals (where a criminal is borrowing the identify of your friend to lure you into a scam or trap), to large-scale financial data compromises (like Target experienced in late 2014). Last month, the IRS revised the number of accounts compromised in a May 2014 incident from 114,000 to 724,000. Personal information (names, social security numbers, etc.) was stolen and used by criminals to attempt to recover tax refunds before the taxpayers did.

Lastly are those motivated by stealing intellectual property. A couple of years ago, the US cybersecurity company Mandiant published a 75-page report on the Advanced Persistent Threat (APT) teams in Shanghai that have been targeting cyber espionage against western companies since 2006. The scale, duration, sophistication and funding of these APT teams makes them a formidable threat to the corporate secrets that are critical to national and economic security.

So what do hackers have in their sights? Anything related to national security, political interests, financial information, intellectual property, or private information. The threats and risks are real. If you haven't been impacted yet, it is only a matter of time. Product developers need to take security seriously and adopt a holistic and layered approach.

MD: Internet security concerns are ever escalating. It seems that the moment a solution against digital invasion is in place, someone or some group finds a way to circumvent it. Is it possible to create an impenetrable system that exists on the Internet or would the system have to be hardwired, standalone and inaccessible to anyone other than authorized personnel?

Nick Ashworth: It may be possible to create an impenetrable Internet solution, but it would be impossible to test it. The almost infinite number of test cases required to address every use (and misuse) case would simply not be feasible or practical to run. While creating a hard-wired, isolated, inaccessible system may come close to being impenetrable, this comes at the significant impact and cost of no longer being Internet-connected. And even then, a research team in Israel recently demonstrated that they were able to hack an air-gapped stand-alone computer in a different room by deciphering leaked electromagnetic radiation.

Instead, the focus should be on creating the least penetrable Internet solution. This is done through adopting a secure development lifecycle (SDL), implementing industry security standards, and regularly updating products with security patches. The DHS recently stated that the Internet of Things (IoT) "also allows every node, device, data source, communication link, controller and data repository… to serve as a security threat and be exposed to security threats." It is very difficult to defend a flat network (everything connected = everything exposed). We need to have defense of depth, or layered security. There need to be borders and zones to isolate and contain breaches. Unfortunately, a flat world is not a secure world.

MD: There have been some reports recently of intruders being able to gain access to systems on a component level. For example, one report indicated that some hackers are able to access a system and gain control of individual devices such as microcontrollers (MCUs), and programmable logic devices and alter the way each operates. They can also change or replace firmware. To do this seems to require advanced engineering skills and knowledge. Is this possible and, if so, where is the inherent system weakness: software, hardware, overall design, or all and any combination?

Nick Ashworth: It is definitely possible for someone to access and modify the "Things" in the IoT. The result of this could be manipulation of the device (turning something on or off), changing the configuration (or the behavior), or updating the firmware to add some undesired features. What makes this possible is the ability/necessity of intelligent connected devices to be remotely configured, controlled and updated by authorized users.

The skills, knowledge and tools required to hack devices are rather sophisticated. The variety and differentiation of IoT devices is extremely high, so it requires more specific knowledge and capability than breaching a secure website. That said, I am not a proponent of security by obscurity. The accessibility of technical product information and off-the-shelf programming tools can make any connected product vulnerable.

The weakness can be anywhere in the system. Not designing with security in mind, or attempting to add security after the fact will likely result in low security robustness. The use of a SDL—layered security, best-practice security requirements and minimizing the attack surface (closing the open windows and doors in your system)—is fundamental to minimizing security risk. Encryption and secure boot technologies are critical firmware security requirements for IoT devices. Refer to the GSMA "IoT Security Guidelines for Endpoint Ecosystem" for comprehensive guidance on securing IoT devices and services. Security has to be approached end-to-end from the outset.

MD: Recently, there has been a good deal of concern surrounding the use of open-source software. More aptly put, the concern revolves around the plagiarism of open-source code by designers facing very tight time-to-market schedules for their products. Rather than invest the time and money to create proprietary code, some designers lift some open-source code, change a few headers, and sign off on it. For devices of little import (toys and standalone novelties) that do not interface with other devices via the web or otherwise, this may not be a big deal beyond the ethical issue of plagiarism. However, in light of more devices on every level becoming part of the Internet of Things (IoT), open-source software opens a veritable playground free of restrictions for hackers. What is your view on this practice? What can be done to limit this practice and to encourage manufacturers to invest in safer code?

Nick Ashworth: Software/firmware continues to become a larger component of embedded design thanks to increasing processor and memory performance coupled with decreasing cost. As a result, it is becoming less economically viable for companies to develop 100% of their code in-house. I believe secure software can and will continue to be built with a combination of open source, licensed and in-house code.

There is concern that open-source software exposes vulnerabilities to hackers and the implication here is that using this software results in a less-secure product. The other side of this coin is that if an active open-source community supports the software product well, the iterations of vetting and improving can ultimately result in a very robust product.

If the open-source product is not well-supported, then you may be left to patch it yourself. A licensed software product removes much of this support risk. You are paying both to use this software and for the software to be maintained. A good software vendor will be quite responsive to addressing security vulnerabilities in its products.

Open and licensed software can both be part of a successful equation in making secure products. It's really a matter of balancing the cost, support and risk equation, and accommodating these components within your SDL.

MD: Is there a difference in the methods of securing individual components – single-board computers, kiosks, semiconductor devices, firmware, etc. – as opposed to the software that controls the application and/or system? What are the concerns surrounding operating systems, like which ones are more secure as opposed to being user friendly yet vulnerable?

Nick Ashworth: The one significant difference to securing an embedded device (the individual components or things referred to above) is the physical vulnerabilities of the device. Take the example of a single-board computer in a TV. This embedded computer may have one or more ports that are used for factory programming or configuration. There may be exposed or hidden connectors that someone can access. Or there may be microprocessors or on-board communication or memory components that are accessible to probes. Designers need to minimize these physical-access vulnerabilities. Embedded devices need to be configured to secure the memory contents, prevent reprogramming through physical ports, and use encrypted communication even between intraboard components.

As far as operating systems go, the concerns are similar to those mentioned in the previous question. It is typically an open-source or licensed piece of software that introduces additional vulnerability and risk. While I don't think usability and security are mutually exclusive, there are definitely some necessary requirements around user or device identity that may impact usability. In fact, if I may put in a plug for the IPSO Alliance, these are two topics we are now tackling—identity and privacy for the IoT.

MD: There is a consensus that soon there be over one trillion sensors tapped into the Internet monitoring everything from a baby's pulse rate to who might be sneaking up to some establishment with evil intent. Aside from a lack of privacy and as much as such an all-encompassing system may offer a level of security, the opportunities for theft and terrorism will probably be limitless. What are your thoughts on the "trillion-sensor world" and what can individuals and organizations do to shield themselves from threats?

Nick Ashworth: First of all, don't panic. While connectivity and risk seem to be growing exponentially, there is a lot of intellectual capital working to improve security technologies. Second, don't put all your eggs into one basket. Just as you diversify your financial portfolio to minimize risk, you should also diversify your technology portfolio. Each technology provider is likely to have different strengths and vulnerabilities. Third, you have responsibility and control. Understand the security and privacy policies of the products you are using. You can always opt out, or disconnect a device if you aren't comfortable with the risk. Be aware that there is also information gathering and sharing without your knowledge and consent. Last, don't be complacent. Stay informed about emerging threats and best security practices, adapt to changing threats and adopt more secure technologies. Security is a journey, not a destination.

MD: According to a Dept. of Homeland Security report, "Seven Strategies to Defend ICSs," issued in December 2015 by the National Cybersecurity and Communications Integration Center (NCCIC), in Fiscal Year 2015, 295 incidents were reported to the Industrial Control Systems Cyber Emergency Response Team (ICS-CERT), and many more went unreported or undetected. The department recommends seven strategies that would have addressed all the breaches and would have protected the safety and reliability of the affected industrial operations. Three out of the seven strategies recommend using hardware-enforced unidirectional communications. What are your thoughts on this approach?

Nick Ashworth: The DHS report recommends using one-way optical communication (opto-couplers) or removable media (sneaker-net) for data transfer in high-security applications. I believe this approach is effective, but obviously has limited scalability. The risk of inbound infection or tampering has been minimized, but the trade-off is the cost and complexity of managing those devices and the limitation of one-way data flow. If there is a need to change the configuration, or update the firmware of these devices to fix a defect or improve the performance, then an authorized user will have to physically access and maintain each instance of the device.

In contrast to Captain Chapman's responses, we not only have agreement but expansion as well. There is a wealth of information here to digest before the next installment. In part three of this article we'll get some more deep insights from Alan Grau, Founder and President of Icon Labs. Until then, check your e-mails. You may find that over 200 crucial emails were hijacked by the spam filter you know nothing about. ~MD

About the Author

Mr. Ashworth has a distinguished track record of over 20 years in product development and leadership in industries including HVAC, appliances, commercial lighting, and smart grid. During this time, he has participated in connected product development involving IP, ZigBee, ISA-100, WirelessHART, and a variety of proprietary wireless communication protocols. Mr. Ashworth holds 15 patents for inventions involving the application of smart technologies for heating, ventilation and air conditioning (HVAC) systems.

At Eaton, he is responsible for technology and engineering within the Energy Automation Solutions business which provides enterprise software, communication infrastructure and end-point devices for monitoring and controlling assets on the electrical grid. Nick Ashworth was the chairperson for the inaugural IPSO CHALLENGE in 2013, which broadened IPSO from promoting and educating to sponsorship of the development of the Internet of Things. Elected to Chairman of the IPSO Alliance in 2013, Mr. Ashworth brings to the Alliance a wealth of engineering leadership experience ranging from NASA to Cyberexe, Invensys, Nivis, and now Eaton.

Related Stories

In the IoT & Beyond, Security Resides On The Dark Side, Part One