As both development and deployment of Internet of Things devices and apps rapidly escalate, so do the threats and potential threats. Being proactive in defenses is a good thing, but can pretty much only defend against known threats. The real challenges are the hackers response to proactive defenses, thereby creating newer and more unique attacks.
In this third chapter of our look at embedded IoT security, we speak to Alan Grau, Founder and President of Icon Labs. A 2014 Gartner "Cool Vendor" and 2015 Gartner "Select Vendor", Icon Labs is a leading provider of security solutions for IoT and embedded devices, including the award winning Floodgate Defender and Floodgate Security Framework. Founded in 1992, Icon Labs is headquartered in West Des Moines, Iowa. Alan has graciously agreed to provide us with expert insights on the subject IoT/Embedded security.
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?
Alan Grau: Everything, and by everything I really do mean everything. There was a report recently of a security vulnerability found in a talking Mattel Barbie Doll. While it is easy to dismiss vulnerabilities in these types of devices as unimportant, we shouldn't. A hacker may be able to steal credentials to a Wi-Fi network from an IoT device like a front door lock or connected refrigerator. This gives them a beachhead from which they can then attack other devices on the network.
It's critical to think more broadly about the security implications of the device itself. While a security vulnerability in a consumer device may not be as critical as a security vulnerability in a nuclear power plant, the consumer device may be part of a larger network and can allow a hacker to penetrate that network. So it's about more than just protecting the device itself.
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?
Alan Grau: Security is in many ways an arms race and, as you point out, hackers are very clever and very adept at finding ways to exploit security mechanisms. The key is to add appropriate levels of security; to make it more expensive for the hacker (in terms of time and computing resources) to exploit a device or system than the gain from hacking the system.
The real problem is that most embedded devices on the market today are completely on the other end of the spectrum. They were designed with little or no security and, as a result, many are very easily exploited. In most cases we need to start by getting the basics of security into place within embedded and IoT devices. Until we have done that, the question of impenetrable systems is not really relevant.
The next step for companies who have already implemented strong security on their devices would be to perform an external security assessment. Hire a group of experts to look at your device and see what weaknesses they can find and begin addressing the issues they raise.
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?
Alan Grau: In many cases, these types of attacks do not require the level of expertise one might think. Easily available on the Internet are many exploit kits and hacking tools that incorporate known attacks developed by experts. Like many other areas of computing, tools exist today to automate tasks that used to require a great deal of expertise.
That said, security for MCU-based devices has lagged behind the security for desktops, laptops, and servers. Creating a highly secure device requires hardware features to support security along with the software security components to use this hardware. For example, secure boot is a critical feature that is used to ensure that the device is running authentic software and to prevent hackers from executing malicious firmware on the device. To implement a strong secure boot solution requires a combination of hardware and software components.
This is part of what makes security a hard problem to solve. It cannot be solved completely in hardware or completely in software. Both must be included to build a secure device.
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?
Alan Grau: First, open source is here to stay and using open source software in commercial products, provided that companies follow the licensing guidelines of the open source package they use, should not pose a problem. The debate on security of open source vs. propriety software is not new. Most open source projects are large and complex. Because of this they end up with many security vulnerabilities. But many propriety software solutions suffer from the same problems.
One main difference is that the security vulnerabilities of open source solutions are widely known and therefore easily exploited. But security by obscurity is not a solution. To ensure security, companies must invest in building secure products. This includes developing quality code that is free from defects that can be exploited by hackers, and building in appropriate security controls such as secure boot, secure firmware updates, security protocols, authentication and so on.
The question of how to get companies to invest in security is a greater challenge. This requires a shift in thinking. As a society we have made safety a priority and have invested very heavily in safety. Preventable death or injury is just not acceptable. As a result, our cars, toys, homes and virtually all products are much safer. The same societal prioritization is required to achieve security.
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?
Alan Grau: Some of the methods and concepts are definitely the same. All devices, for example, should implement secure boot and validate that the firmware and software running on the device are valid before allowing it to execute. Critical data should be encrypted, no matter the type of device. In addition, critical operations should be isolated to protect them from malicious users and code.
I think one of the problems in many embedded devices is that companies have focused on security at the OS level and ignored security at the device level. They develop a device using an RTOS that is reasonably secure but leave a gaping security hole at the application level. Examples include use of industrial automation protocols such as Modbus/TCP that have no security controls at all.
Security can only be achieved when ALL the elements in the system are secured. Attention must be paid to secure hardware elements, security controls, and the security of the operating system, applications and communication.
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?
Alan Grau: This comes back to societal acceptance of insecure devices. As a society we said it was not acceptable that people be killed or injured by the machines we build. We then invested in training, technology, and processes to improve safety. It took a long time but we have made tremendous strides in safety.
The entire system must be addressed to achieve security. Today the short term gains of getting to market faster outweigh the advantages of security. But this is starting to change. Device OEMs, network providers and platform developers are becoming more security conscious and starting to build security into their devices and networks. We must accelerate this, but we are starting to move in the right direction.
On an individual level, there is less we can do. If a company produces an insecure product the consumer can either live with it or not buy it. For those products with built in security, users must enable security, change default passwords, and use strong passwords.
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?
Alan Grau: This is a really interesting whitepaper. On the one hand, what it shows is that basic security techniques actually work. If the seven basic strategies they outlined had been widely used, then the attacks that were reported would have been blocked. I am a huge believer in implementing the basics when it comes to security. It's just common sense to lock the doors on your house at night or lock your car door.
But just implementing basic security can lead to a false sense of security. Hackers did not use more advanced techniques because more basic attacks were successful. If you park your car in a bad neighborhood and leave the door unlocked with a big pile of cash in the back seat, someone will likely open the door and steal your cash. Saying that you could have stopped the theft by locking your doors is clearly ridiculous. Someone could smash your window, pick the lock, or show up with a tow truck and steal the entire car.
If the basic security measures had been in place that does not guarantee that hackers would have given up and gone home. They would have dug deeper into their bag of tricks and tried something else. Would they have still gotten in? In some cases, I believe the answer is yes, which is why we need to implement more advanced security capabilities.
I am in no way trying to say that the approaches outlined in this report are not effective or should be abandoned or ignored. They provide a strong foundation for security and we must start with the basics. It is important to look at the overall security architecture of our devices and networks, along with policies and training we provide to the people using our systems. Only by addressing the entire system can we achieve security.
Alan has certainly presented a lot of things to think about. And he has certainly made it clear that, even though we are making headway, there is much work to be done in securing our IoT. In the final chapter we will be talking to Indegy CEO Barak Perelman. Hopefully, he will help us put a few more nails in the hackers' balloons. ~MD
SIDE NOTE: If IoT security is becoming a serious issue for you and your company, you'll be glad to know that Captain Brent Chapman will be speaking on the topic "Going Tactical in the IoT" in the Embedded LIVE Theater at Sensors Expo, San Jose, CA on Thursday 6/23/2016 from 11:45 AM - 12:15 PM. Here's a brief description what Capt. Chapman will be talking about:
"The nation's critical physical infrastructure depends crucially on networked systems to include SCADA and ICS. Used in sensing, monitoring, and gathering data, these systems pose several unique and interesting security challenges particularly when used in complex cyber-physical networks. I'll explore trends in security and how the Department of Defense aims to stay innovative and agile in an ever-changing operational environment." Of course, it will only be helpful if you register and attend!
About Alan Grau
Alan Grau is President and co-founder of Icon Labs, a leading provider of security software for IoT and embedded devices. He is the architect of Icon Labs' award winning Floodgate Firewall. Alan has 20 years of embedded software experience. Prior to founding Icon Labs he worked for AT&T Bell Labs and Motorola. Alan has an MS in computer science from Northwestern University. He speaks and writes prolifically on security of IoT devices.
About Icon Laboratories, Inc.
Icon Labs, a 2014 Gartner "Cool Vendor" and 2015 Gartner "Select Vendor", is a leading provider of security solutions for IoT and embedded device, including the award winning Floodgate Defender and Floodgate Security Framework. Founded in 1992, Icon Labs is headquartered in West Des Moines, Iowa. For more information, visit http://www.iconlabs.com
Related Stories
In the IoT & Beyond, Security Resides On The Dark Side, Part One
In the IoT & Beyond, Security Resides On The Dark Side, Part Two