April 1, 2017
As the universe of connected products continues to expand, the security of the Internet of Things (IoT) has to be a primary concern of all stakeholders—and that holds true for the designers and engineers who will play a key role in making sure connected assets, consumer products and machinery are fully protected.
Security should be a top concern for any company designing a connected product. The IoT cannot reach its full potential unless consumers and other end users trust those devices to protect their security and privacy. So how do you protect deeply embedded endpoint devices with limited memory/processing resources?
It will require a mix of traditional security approaches, predesign discussions between engineers and security experts, and strict testing and quality assurance processes.
The IoT is already under attack by hackers and malware. In 2014, security firm Proofpoint found that an Internet-connected refrigerator helped send more than 75,000 spam and phishing e-mails. Seehotel Jägerwirt in Austria had to pay ransom to hackers after they infiltrated the hotel’s computers, preventing them from creating keycards for guests. In October 2016, Internet infrastructure provider Dyn got hit by a botnet attack that took down a number of websites and caused outages and network congestion across the United States. Mirai malware appears to be the culprit. The malware leveraged several hundred thousand different IoT devices, including CCTV (closed-circuit television) video cameras and digital video recording systems from XiongMai Technologies. Mirai searches the web for IoT devices that use factory-default passwords.
Image courtesy of National Instruments.
If there were similar attacks on systems that affect public safety (utilities, hospitals, connected vehicles), the results could be catastrophic.
“It’s never been so easy for attackers to gain access to the IoT ecosystem,” says Jason Hart, chief technology officer for data security solutions at Gemalto. “There are multiple attack vectors at multiple levels, and from the manufacturer’s point of view, they need to consider risks from all those different ‘personas’ that are present in the IoT.”
“There are millions of devices being added to the network that you just plug in and they work,” adds Mark Baugher, principal security architect at IoT platform provider Greenwave Systems. “You don’t have to change a password, and they may not even have a user interface.”
According to Baugher, IoT systems present unique problems when it comes to security. Many devices are “headless,” so there is no user interface (or a user to input credentials/passwords). Semantic gateways also present a problem because of the lack of encryption and authentication during the data handoff. Commands may be processed in plain text between secure connection points.
“If I’m talking with a device on a Zigbee network, I can identify the gateway, but not the device,” Baugher says. “I’m trusting the gateway to handle that. You lose authentication end to end. Any encryption that was on the wire gets terminated once you move to a different connection.”
Engineers and quality assurance teams will have to ensure these devices have sufficient protection against these IoT vulnerabilities. There should be rigorous testing on applications, platforms and hardware prior to release.
Currently, low-cost connected devices have entered the market with few (if any) security protections. They have default passwords that are difficult or impossible to change, or may lack data encryption or authentication capabilities. Often, this is because manufacturers want to lower the price or make the devices easier to use.
“We do see challenges in adhering to security and still allowing ease of use,” says Jamie Smith, director of embedded systems at National Instruments. “It takes a significant amount of software investment to provide both. You don’t need to lose ease of use to have a secure system, but it takes work to enable that.”
IoT Security Issues
The IoT presents a number of troublesome security problems. Information could be intercepted and replaced in transit. Data from the connected device could also be manipulated, for example, to throw off sensor readings or alter test results. Packets could be sniffed or retransmitted. Encryption keys could be stolen and used to set up false nodes on a network. IoT nodes could also be hijacked and used for denial-of-service (DoS) attacks (as was the case with the Dyn incident). Hackers could also, conceivably, gain control of operational systems within the connected device—a possibility that has been demonstrated several times with connected vehicles and smart home systems.
The data passed back and forth from devices to the network could also be compromised. “In IoT, data integrity will be paramount,” Hart says. “We assume data is correct and that data is being used to make decisions. But if it’s incorrect, we don’t realize that until the data has moved downstream. That’s the biggest vulnerability of the IoT. We’re going to see more integrity-based attacks.”
These vulnerabilities have consequences beyond the specific connected device. The presence of those insecure items (particularly low-cost webcams) on the network and their sheer number make it possible to launch DDoS attacks.
The U.S. Federal Trade Commission (FTC) takes this problem very seriously and has been willing to prosecute at-fault companies that did not take reasonable steps to secure their networks, products or services.
Making the Security Connection
Fixing these security issues starts early in the design process and will require engineers to apply traditional security fixes in new ways. According to embedded software specialist Wind River in its “Security in the Internet of Things” report:
“Unfortunately, there is no ‘silver bullet’ that can effectively mitigate every possible cyber threat. The good news, though, is that tried-and-true IT security controls that have evolved over the past 25 years can be just as effective for IoT—provided we can adapt them to the unique constraints of the embedded devices that will increasingly comprise networks of the future.”
“We need to revolutionize the way we develop hardware and software and secure the development lifecycle,” Baugher says. “These technologies have to be incorporated at the beginning and be part of the daily work practices of the engineers.”
“There’s not only security measure or policy, but several that are layered one on top of the other,” says David Gascon, CTO and co-founder of Libelium. “You start by ensuring you are only communicating with nodes or gateways that are part of the same network.”
There should also be device-to-gateway encryption, and from the gateway to the cloud. Libelium uses an encryption chipset close to the main microcontroller in instances where there isn’t enough energy available for open source libraries. “We use small chips, write information to the chip and it returns it in encrypted form,” Gascon says. “That’s a good alternative when you are dealing with constraints on an end node.”
For embedded systems and controls, there should be a capability to whitelist apps and enable elements with the (often) Linux platform that enhance security. “People should have strong Linux skills and a strong level of consultative security experience,” NI’s Smith says. “They can build security features starting at the OS and working up to the application stack. That’s what is built into the edge nodes that we provide.”
Other approaches can include:
- Standard encryption techniques, including encrypting payloads and using app-level encryption as well as transport encryption.
- The use of “salt” or random data within hashed data to make it more difficult to compromise.
- Rate limiting, which can help prevent attacks that involve automatically entering possible passwords multiple times.
- Secure booting, so that the integrity of the device would be verified using digital signatures.
- Access control that is based on role-based protections. Privileges should be limited so that if a hacker does compromise credentials, the damage can be minimized.
- Deep packet inspection or a firewall to provide control over data that terminates at the device.
- The ability to authenticate patches and updates without consuming large amounts of bandwidth.
In the case of Libelium, the company uses AES 256 libraries for privacy and RSA 1024 for authentication, as well as an encryption circuit that allows data to be encrypted without external software units.
Not all of these protections will be necessary in every instance. Device constraints will require some re-engineering of these security approaches. Many IoT devices have to minimize power consumption, have limited connectivity, and not much onboard memory or processing capacity. But security can still be achieved without significantly increasing costs.
“People think that making something easy to use, you have to remove a level of security. That’s not the case at all,” Hart says. “Security can be baked in from day one. The technology is there to do it.”
“You have to understand the type of data you are creating and consuming,” Hart adds. “What data is coming in and going out? Once you understand that, you can understand the type of risk you are exposed to and apply the right security controls.”
“This often doesn’t happen at the design stage,” Baugher says. “A big cultural sea change needs to happen before we have the skills and practices in place to do this. Those risks have to be assessed upfront.”
Role of QA
Post-design, quality assurance teams will play a critical role in making sure that systems are tested against security weaknesses. That will largely mean leveraging existing security standards.
“We really don’t need new standards,” Hart says. “You identify the risk and apply the security measures already available in industry; follow best practices. There are enough standards out there that can be repurposed here.”
The FTC has issued best practices for IoT security. Other government agencies are jockeying for position when it comes to regulating connected devices.
There have been suggestions of developing ratings similar to UL ratings for electrical safety (a group called I Am the Cavalry has developed a five-star rating system), but the threat of accidental malfunction is not exactly comparable to protecting against deliberate attacks or sabotage. The Industrial Internet Consortium also offers guidance.
QA should include agile testing methodologies, prioritizing code revues and repeat analysis. Developers and testers should work together more closely from the outset of a design project.
Leverage independent third-party services to conduct this type of penetration testing. Most companies don’t have adequate security staff, so involving third parties in security validation at all stages of design and development is critical.
In January, NI debuted its Industrial Internet of Things Lab at the company’s Austin, TX, headquarters. The facility is focused on a number of IoT applications (including advanced control for manufacturing and asset monitoring for heavy equipment) and serves as a showcase and as a working laboratory.
According to Smith, the company follows industry and other compliance standards (including from the Industrial Internet Consortium) when testing and validating security of IoT systems. “By participating in IIC testbeds, we can bring together multiple vendors to connect devices and put them up against the security paces outlined in the standards,” Smith says. “Over time we do more work on those testbeds from a security perspective. As we add new capabilities to hardware or management software, we can look at those changes through a security lens.”
In the end, it will be incumbent on designers to create systems that can recognize and react to threats. “In the airport we have a mantra: ‘If you see something, say something,’” Smith says. “We need to have that as part of these edge devices. If they see a request or change in behavior that is odd to the device, they may be able to determine if they are being spoofed or receiving false commands. The edge device needs to communicate to a higher level of the stack that something is happening.”
For more info:
About the Author
Brian Albright is the editorial director of Digital Engineering. Contact him at [email protected].Follow DE