Listen to this article
One of the biggest concerns with the Internet of Things (IoT) is making sure networks, data, and devices are secure. IoT-related security incidents have already occurred, and the worries among IT, security and networking managers that similar events will take place are justified.
“In all but the most restrictive environments, you’re going to have IoT devices in your midst,” says Jason Taule, vice president of standards and CISO at security standards and assurance company HITRUST. “The question then isn’t if, but how you are going to allow such devices to connect to and interact with your networks, systems and data.”
What can organizations do to enhance IoT security? There are plenty of options—including a number of practices that might not be so obvious.
IoT security: start by thinking small
To build better security into IoT, organizations should start with the smallest component in their network infrastructure—the code, says Laura DiDio, principal at research and consulting firm ITIC.
“The majority of IoT devices are very small,” DiDio says. “Therefore, the source code tends to be written in the ‘common tongue’—C or C++ and C# languages which frequently fall victim to common problems like memory leaks and buffer-overflow vulnerabilities. These issues are the network equivalent of the common cold.”
And like the common cold, they are pesky and persistent, DiDio says. “In IoT environments, they can proliferate and become a big and often overlooked security problem,” she says. “The best defense here is to test, test and re-test.” There are a variety of well-regarded testing tools on the market that have been used for IoT devices, DiDio says.
Security and IT administrators can also use stack cookies, DiDio says. These are randomized data strings that applications are coded to write into the stack just before the Instruction Pointer Register, to which data overflows if a buffer overflow occurs. “In the event a buffer overflow does occur, the stack cookie gets overwritten,” she says. The application will be further coded to verify that the stack cookie string will continue to match how the code was initially written. If the stack cookie doesn’t match, the application terminates.
Deploy context-aware access controls
Controlling access within an IoT environment is one of the bigger security challenges companies face when connecting assets, products and devices. That includes controlling network access for the connected objects themselves.
Organizations should first identify the behaviors and activities that are deemed acceptable by connected things within the IoT environment, and then put in place controls that account for this but at the same time don’t hinder processes, says John Pironti, president of consulting firm IP Architects and an expert on IoT security.
“Instead of using a separate VLAN [virtual LAN] or network segment which can be restrictive and debilitating for IoT devices, implement context-aware access controls throughout your network to allow appropriate actions and behaviors, not just at the connection level but also at the command and data transfer levels,” Pironti says.
This will ensure that devices can operate as planned while also limiting their ability to conduct malicious or unauthorized activities, Pironti says. “This process can also establish a baseline of expected behavior that can then be logged and monitored to identify anomalies or activities that fall outside of expected behaviors at acceptable thresholds,” he says.
Hold vendors accountable for their IoT equipment
Organizations as a matter of course hire all kinds of service providers, and in some cases those services are provided through equipment that’s placed on the customer’s premises. In the age of IoT, there’s a good chance the machinery will be connected and therefore vulnerable to hacking and other intrusions.
It’s up to the customer to ensure that there is accountability in place if something goes wrong.
“One place to start is within contracting,” says Brian Haugli, a partner at security consulting firm SideChannelSec and a former security executive at insurer Hanover Insurance Group. “Are your vendors pushing an IoT into your enterprise as part of their services or solutions? If so, you must know about it and see that it’s part of the contracting/procurement.”
Make sure it’s clear who’s responsible for updates and the lifecycle of the equipment, as well as if you’ll have access to it in case of an incident, Haugli says. “I’ve seen HVAC [heating, ventilation, and air conditioning] and printer companies not give up access that led to a stalled response effort,” he says. “Those same vendors would push back on routine patching responsibilities or upgrades” to operating systems.
In some cases, a contract might not specify when the customer would warrant a new piece of equipment with a supporting operating system, and the vendor might be unwilling to take on the cost, Haugli says. As a result, an unsupported and vulnerable device could be allowed to sit on the network far longer than it should.
“If we aren’t articulating our requirements to our vendors, don’t take steps to confirm compliance and aren’t holding them accountable, what basis do we have for expecting these issues to be addressed?” Taule says. “In the same way that hardware OEMs and software companies now all expect to be held accountable to identify and quickly resolve weaknesses in their products, so too should the companies that provide us the IP cameras, medical devices, printers, wireless access points, refrigerators, environmental controls and the untold number of other IoT devices upon which we increasingly rely.”
Companies should apply the controls outlined in common security frameworks to IoT devices, Taule says. For example, include security functional requirements in your contracts; request recent vulnerability scans or assert the right to scan them yourself; obligate the vendors to provide timely updates to address identified weaknesses; and rescan the devices after any firmware updates to ensure that identified issues have been resolved and that no new issues have been introduced.
Defend against IoT identify spoofing
Hackers and their techniques have become more proficient over the years, and this can represent a big threat for IoT security.
“They continually up their game like counterfeiters and forgers,” DiDio says. “The exponential increase in IoT devices means that the attack surface or the attack vector has increased exponentially.”
That makes it imperative that businesses and their security and IT departments verify the identity of the IoT devices that they’re communicating with, and ensure that they are legitimate for critical communications, software updates and downloads.
All IoT devices must have a unique identity, DiDio says. In the absence of a unique identity, an organization is at high risk of being spoofed or hacked from the microcontroller level to the endpoint devices at the network edge to the applications and the transport layer, she says.
Establish ‘one-way’ connections for IoT devices
Companies should limit the ability of IoT devices to initiate network connections, and instead only connect to them using network firewalls and access control lists, Pironti says.
“By establishing a one-way trust principle, the IoT devices will never be able to initiate connections to internal systems, which can limit an attacker’s ability to leverage them as jump points to explore and attack network segments,” Pironti says.
While this will not prevent adversaries from attacking systems that have established connections to them directly, it will limit their ability to laterally move within networks, Pironti says.
Enterprises can also force connections to IoT devices to go through jump hosts and/or network proxies, Pironti says. “By proxying the connection in a funnel point, an organization can then inspect network traffic prior to coming from and to IoT devices, and interrogate [the traffic] more effectively,” he says. That enables it to determine if the traffic and the payloads it carries are appropriate for the IoT device to be receiving or transmitting.
Consider using a segregated network
Many types of control devices, such as thermostats and lighting controls, connect via wireless. However, most enterprise wireless networks require WPA2-Enterprise/802.1x, says James McGibney, senior director of cyber security and compliance at Rosendin Electric, an electrical contractor.
“Most of those devices do not support WPA2-Enterprise,” McGibney says. “Developing a more secure device would be ideal. However, if the environment supports it you could put those devices on their own wireless network, segregated from the production network and allowing Internet access only.”
That would require creating a separate service set identifier (SSID) and virtual LAN and having the capacity to route that traffic through a firewall, McGibney says. The segregated wireless network would be configured and managed from a centralized location, he says.
“We have done this for some devices, [such as] vending machines that require Internet access, which we have no control over,” McGibney says. “We put them on our guest network, which is segregated from production.” It runs on the same hardware but is on a separate VLAN, he says.
Insert security into the supply chain
IoT endeavors typically reach across multiple partners in a supply chain, including technology vendors, suppliers, and customers, and security must take that into account.
“If you haven’t already done so, go to your contracts, finance, or whatever other group in your organization manages supply chain,” Taule says. “Start a conversation and a relationship with them such that approval is not provided for any IoT purchases unless security team concurrence has been provided.”
These departments will eagerly comply with this if security offers to shoulder the burden of work for the analysis, Taule says.
Exactly how to best enhance the supply chain vendor selection process is up to the individual organization, Taule says, but he recommends considering manufacturers that allow independent validation; advocating for a write-protect switch on the device side such that the firmware cannot be updated without your knowledge; and only procuring authentic products rather than counterfeits.