Posted by Tim Matteson

Originally Posted by: Shawn Wasserman

Shodan search results show that over half a million devices use the 10-year-old OpenSSH 4.3 software. This puts all these devices at risk.

One doesn’t have to look too far to realize how vulnerable the Internet of Things (IoT) can be. It just takes a quick search on IoT search engines like BullGuard and Shodan.io.

During a presentation at PTC LiveWorx 2016, Rob Black, senior director of product management at PTC, outlined how black hat hackers could get into over half a million connected devices using an old software known as OpenSSH 4.3.

OpenSSH is a secure shell (SSH) protocol used to allow users access to networks from a remote location. It’s harmless, even useful, if used by the right user in a controlled way.

Unfortunately, a popular version of the software, OpenSSH 4.3, has been out for about a decade. As a result, it has developed a laundry list of vulnerabilities that hackers can use to gain access to systems.

According to the Shodan IoT device search engine, over half a million devices on the ‘net still use this outdated software.

“Half a million devices are on the open Internet with 10-year-old software that allows you to tunnel inside to their network. Who thinks that’s good?” Black rhetorically questioned. “This is one example. One search. One software. One version of a software. There are millions of exposed resources on the Internet.”

The scary thing is that Black explained that some search results will bring up IoT devices associated with power plants and wind tunnels. According to AdaptiveMobile, a mobile network security company, up to 80 percent of connected devices on the IoT do not have the security measures they need to protect us. Once you find a device on Shodan, you can see many characteristics on that device which will help hackers get into it.

These attacks can even prove deadly depending on the IoT application. Take an integrated clinical environment (ICE) like an IoT-enabled hospital. Without proper security, many types of attacks have the potential to risk lives. According to a report published by the Industrial Internet Consortium, these attacks fall into five categories.

Five IoT hacking attacks that can risk lives. Examples from an integrated clinical environment (ICE). (Table from the Industrial Internet Consortium.)

Engineers are designing these IoT devices, sensors and edge points. To ensure that hackers are kept at bay, these engineers need to understand and learn from their software engineer and IT cousins.

“From a design point of view, engineers need to learn about hacking security. You need security at the edge point to make an intelligent analytic device,” said Michael Wendenburg, CEO at Michael Wendendenburg Online Redaktion. “If you hack into that point, you hack into all this data. Engineers are not prepared for that.”

Black agreed, saying, “It’s our role as practitioners of IoT is to really manage those devices that we have in a smart way.”

How Do IoT and Cloud Security Differ?

Black explained that unlike in cloud security, humans may not be in the loop when it comes to IoT security. It’s not feasible for millions of users to be there to hit “Okay” to update software in billions of devices.

An engineer might think that as long as the cloud system utilized by the IoT device is secure, then all is well. However, there are differences between an IoT system and a cloud system.

Black explained that on the cloud, users and applications are both managed. There are security tools and permissions put into place. On the operations side, servers will be secured and ports will be closed and audited. This takes a lot of testing, but it’s been done before. IoT security, on the other hand, adds complexity.

“Cloud security has been around for a long time and there are lots of good strong practices and management around cloud applications. For IoT, the key difference is we connect things,” clarified Black. “A lot of the challenge is the number of devices to manage and the differences between these devices.”

“There are a bunch of new issues out there like rogue sensors and rogue data sources,” said Andy Rhodes, division head of IoT at Dell. “If you’re orchestrating a turbine or a damn and someone hacks into that and changes the settings, then there are catastrophic issues.”  

Here are some other key differences between cloud and IoT applications:

• IoT has a stronger potential for damage as water mains can be shut off, power plants can become critical and cars made unresponsive on the road.

• IoT has a diverse number of devices, operating systems and protocols making it hard to consolidate and standardize as companies grow and products change.

• Human interactions with all the devices is not scalable. For instance, humans many not be there to hit “Okay” for an update.

The key is to work together. Engineers and IT professionals need to demolish their silos and learn from one another to make the IoT ecosystem secure. However, just because the IT crew has the ecosystem covered on the cloud doesn’t mean the devices and sensors are secure.

“IT [Information Technology] knows how to do security and a lot of this is still traditional IT security working alongside the OT [Operations Technology] people to understand how to secure the sensors as well,” described Rhodes. “You need [security on the device] and network security on the IT side because data flows two ways so you have to secure both ends of that spectrum.”

How to Manage Your Connected Device

Black demonstrating an IoT security architecture.

With current IoT trends, if your device isn’t connected to the Internet, it soon will be. Otherwise, it will not keep up with the 30 billion other connected devices Gartner expects to see in the market by 2020.

So the question may not be whether to get into the IoT market given all the security risks. It should be a question of how to manage connected devices with all these security risks.

Black demonstrated what a simple IoT architecture might look like. It includes devices within a firewall, wireless devices outside the firewall and having those devices connecting into the IoT platform. Then, all of this will be used in an application that will use the data from the devices to perform a function. All of these systems, applications and development tools used to make the system must be made secure.

The issue is that because all of these different systems are under the control of various organizations on the vendor, customer and public levels, it can be confusing to establish who is really responsible for all of this IoT security.

“I argue that for IoT we have a shared security responsibility,” noted Black. “This is not a one-entity responsibility. It is shared between the providers of the infrastructure, service, platform, application and the end customers.”

Importance of User Roles on IoT Security

Given all of the organizations and users that might be associated with one IoT system, defining roles for these organizations and users is of high importance.

Each user and organization will have different roles, which will define levels of control over the IoT system. For instance, you don’t want to give your customers visibility into and control over all of the IoT devices on your ecosystem. This could make the data of your other customers insecure, as competitors might gain insights due to the information on your system and the lack of roles governing the system.

However, a maintenance team that services all the devices sent to customers will need to see which devices from each customer will be up for servicing.

The key takeaway is that as your system grows on the IoT, much of this role management should be automated. Otherwise, the role management will not scale with the IoT system if a human remains in the role assignment loop.

“From a visibility and permission standpoint, what you really want are mechanisms to drive that behavior,” instructed Black. “When new devices are added, if you have a manual process, that is not going to scale when you [have] tens of thousands of devices. You are going to need a system that drives this behavior automatically. You just need to set the rules beforehand to ensure the users are put in the right groups.”

Division of Systems is Key to a Secure IoT Ecosystem

The division of permissions shouldn’t just be between roles. It should also be between systems within the IoT device itself. Engineers must design some systems and subsystems to be independent and separate from all other systems. This will ensure that if a hacker compromises your device, they will not be able to take control of key systems.

After all, there is no reason for an entertainment system in a car to be linked to the steering, brakes and accelerator of a car. As the WIRED video below shows, though, this was the case with the Jeep Cherokee. As a result, hackers were able to mess with one reporter’s drive on the highway with hilarious outcomes—but the joke isn’t funny anymore if people actually get hurt.

“The way some of these systems are designed, if you have access to this you have access to multiple design elements in the car,” said Frank Antonysamy, head of engineering and manufacturing solutions at Cognizant. “The way we are dealing with this is to isolate as much as possible and then get the data.”

“When you look at it from a system design [perspective], in an automobile for example, there is still a fair amount of isolation written into the design,” said Antonysamy. “Because I have access to my control panel doesn’t mean I have access to the accelerator. That kind of design-based isolation is critical at least until we get a zero-vulnerability scenario.”

Eric van Gemeren, vice president of R&D at Flowserve, explained that the automobile industry and other IoT device creators can learn a lot from the process industry on the separation of systems within a design.

“In the process industry, it’s different from having a car that’s IoT-enabled and someone can hack into it,” said van Gemeren. “In the process industry, there are well-established IEC [International Electrotechnical Commission] and ISO [International Organization for Standardization] standards for safety and compliance. The control communication network is always separate and independent from the diagnostics and asset management network. It’s very clear that when you design that solution, there are certain features and functions that will never be available through wireless, in a discrete controlled domain, with an entirely different protocols and with robust security on top of it.”

“A lot of the stuff we are talking about in the IoT space is all about gathering outbound asset information,” added van Gemeren. “You can’t send back control information or directions that can hijack the device.”

In other words, van Gemeren explained that if a safety system like fire suspension sprinklers were installed in a process plant, they will need to be on an isolated system.

Do Your Devices Need to Talk to Other Devices?

Black explained the scenarios in which you need to use device-to-device

When people think about the IoT, many of them think of connected devices communicating with each other over the Internet.

Though there are situations when the data should be sent to the cloud, there are also situations where it is faster and more efficient for devices to talk to each other directly.

“You could go up to the cloud and negotiate up there and bring it back down but that is not using bandwidth efficiently and what happens if you lose network connectivity? Will your devices fail? Do you want them to be dependent on the network?” asked Black.

When connected device need to talk directly, you will need a way to authenticate the devices mutually as well as a method of authorizing the devices to an appropriate level of interactions.

“It doesn’t make sense for one car to have the authorization to turn on the windshield wipers for another car,” joked Black.

The Importance of Provisioning and Approval of an IoT Device

This brings us to another key step in setting up a secure IoT system: ensuring your processes can set up provisioning and approval for device-to-device communication, data ownership, de-provisioning and more.

“Any process that runs off of administration approval will fail on an IoT scale,” remarked Black. This is similar to the creation of roles the human needs to be out of the loop. Black added, “You can’t design a process based on admin approval—it might work for a hundred devices but it won’t work on a large-scale system.”

Unfortunately, you can’t just let all devices interconnect without a provisioning and approval process either. Take the Superfish scandal, for example. The program was intended to provide advertisers with a way to show ads based on a user’s Internet searches.

This sounds innocuous enough until you realize that, at the time, all Lenovo laptops had the same self-signed certification key for all the laptops that shipped out with the program. This allowed for man-in-the-middle hacking attacks that could intercept the Internet communications of any Lenovo laptop with the Superfish program still installed.

“Ensuring trust when you’re bootstrapping a device is challenging even big laptop manufacturers can make mistakes,” said Black. “We need to think through some of those processes to see how do we get secrets onto a device. You need a well-defined mechanism for establishing trust on your device.”

One method Black suggested to get your devices onto your IoT system with secure provisioning and approval is to use your enterprise resource planning (ERP) system. If your ERP system were connected to the IoT system, then the provisioning and approval process will expect to see the device. Not only would this system be secure, it can also be made scalable as there will be no need to have a human in the loop.

The Importance of De-Provisioning When You Re-Sell a Connected Device

Black explained the importance of factory resets and de-provisioning when selling used devices.

There is a lot of confidential information that can be stored on a connected device. Therefore, if users aren’t careful, they could be giving a hacker everything they need to get into the system when re-selling these devices.

The average user would know enough to delete their personal and business data from the device, but there still might be information on the re-sold device that can open doors to hackers.

For instance, the device might store digital keys that were used to encrypt the data you were sending and receiving from the Internet. If you were to sell that equipment without changing those keys, then whomever you sold that equipment to could now be able to decrypt all of the data you sent and received while operating the device. Assuming the hacker intercepted that data in full knowledge that you were to sell the equipment, they now have gathered a lot of information on your personal or business operations.

As a result, engineers should design easy to use de-provisioning procedures for the users of their devices.

Whose Data Is It Anyway? Where the Contract’s Made Up and Protection Should Matter.

Black asked the question: Whose data is it anyway?

One point of contention for the development of IoT security is the question of who owns the data.

Is it the device manufacturer, systems operator, device operator or the maintenance operator?

Will the answer be dependent on the IoT device application?

These questions need answers if robust security measures are to be put into place. Otherwise, the right information might end up in the wrong hands.

“We’ve seen a range of responses about data ownership and a lot revolves around privacy,” said Colm Pendergast, director of IoT technology at Analog Devices. “To a large extent, it will come down to negotiations between various partners in an ecosystem.”

“[Who owns the data] is a question that is always on the table,” said Chris May, account executive at ARIDEA SOLUTIONS. “It depends on the type of data being acquired. If it’s general weather data, then people are not very concerned. The weather is the weather… When you get to environmental data, it’s a completely different story. They are very protective of that data. [What] If the wrong person gets that data and they don’t understand how to interpret it? [What] if they can’t understand it’s a sensor being recalibrated and they think a water shed was contaminated? It would be massive lawsuits.”

It appears that though 54 percent of surveyed consumers might be comfortable sharing their data with companies, the reverse is not always true.

Alternatively, Black used an example of a medical device company. If the company is sold, then it makes sense for whomever buys the company to also own the data. After all, it will, in theory, be using said data to service the same clients. It isn’t in the client’s interest for the data to start at point zero.

However, does the answer of selling data ownership change with the scenario? What if, instead of a company being sold, it’s a house? Who owns all the data of the smart home—the previous tenants or the incoming tenants? It might be useful for the new tenants to know the power usage history of the house so they can budget their expenses, but do you want strangers to have data like that?

“When you think about how many different entities are involved with an IoT implementation, there are a lot of them,” said Black. “Some of them probably have rights to some of that data and some it’s probably better if they don’t have it.”

Before security walls are put up for an IoT device, these questions must be answered. Otherwise, an owner of the data might be cut off from their property. This can lead to some serious legal ramifications. On the other hand, not understanding where the line in the sand is for data can also open up security risks.

“If there was one single challenge that people are concerned about and has slowed IoT deployments is the question of security and integrating security solutions all over that technology stack. It is one of the bigger challenges,” said Pendergast.

However, one solutions to the IoT data question may not lie with the engineers, programmers or designers. It might be in the hands of public relations educating the public about IoT security and what data is and isn’t being collected.

“We deal with the medical device market and we constantly face the issue that we can’t send patient data—and we are a cloud-based platform, so that is a challenge,” said Puneet Pandit, CEO of Glassbeam. “We are not taking the patient data; we are taking the operation data. I think that is a constant question. There is a lot of education that has to be done in the industry to clarify what IoT data means at the end of the day. People have created security barriers for all the right reasons, but in the context of IoT you are taking machine and operational data and that isn’t something that is included on data privacy.”

Reducing IoT Attack Surfaces: Do You Need Access to the Open Web?

Shodan is only able to show the IoT devices that are on the open web. The number, as well as types, of devices that it can find is certainly scary.

“[Security is] still the top-two or -three concern of customers when you read surveys and speak to them,” said Rhodes. “What you’ve basically done is you’ve opened up a surface of attack either as a gateway or the things themselves.”

Does your device need to be on the open web? Do multiple surfaces of attack need to exist? The answer is no—not if engineers design the device to be the one to initiate communications.

“Different IoT solutions have the capability to perform device-initiated communication,” said Black. “That means that from a connection standpoint, if your device initiates communications, then that device is exclusively paired with one server on the cloud. That device is only going to communicate with that server.”

In other words, the device won’t be generally available on the Internet.

“It’s something to think about. Can I communicate with this device from every [access point] on the earth or is it tied to a single server? Because you are really reducing your attack surface with that kind of capability,” Black explained. “You reduce your attack surface so you are not worried about everything in the world. You are only connected to a very limited set of servers.”

If your device can connect to any endpoint on the Internet, then any hacker at any location could in theory send a command to that device. However, if the device is connected only to one server via a device-initiated communication, then only that server can send commands. The theory is that your server will be within internal IT infrastructures and securities.

However, there is a downside to device-initiated connectivity. You will have to rely on the device to connect to the system in order to initiate an update or collect data. In other words, you can lose connections to the device as soon as a customer changes firewall securities or the network is interrupted. 

As a result, if engineers chooses to use device-initiated connections for an IoT system, then they will need to inform the customer. The customer will need to understand if the firewall and network connection isn’t interfering with the connection.

“We’ve seen a lot of software partners changing their architecture to support intermittent connectivity,” said Gerald Kleyn, director of engineering at Hewlett Packard Enterprise (HPE). “In some cases, if the weather gets bad and [satellite communication] goes down, then when it comes back up it starts releasing things that have been stored on the edge back up to the cloud.”

What to Do When You Find a Vulnerability on Your Connected Device

The longer your device is in the real world, the more likely it is that a vulnerability will be found. As a result, engineers will need to design software update compatibility into their devices.

“You need a software distribution mechanism that will work for all of your devices that’s scalable, secure, flexible and efficient,” said Black. “It needs to be flexible because all your devices are different, so they need different processes and procedures.”

“You need to be able to say, if the install isn’t going right, that you need to hold back and notify your system. You need to be able to say, ‘do this for North America first, or Europe or everyone but that customer that doesn’t want updates,’” added Black. “Without a plan, you will be sad when the next Heartbleed comes out. You are going to have to patch. So what is the mechanism you are going to utilize?”

This all must seem very complicated, but much of this IoT security issues will be answered when you choose the IoT platform to run, manage design the system. Black says that when choosing your IoT platform, keep these three main security challenges in mind:

1. Managing the complex interactions between devices and user

2. Patching security updates to your devices in an easy and secure fashion

3.  Reducing the risk by mitigating cyber-attacks form finding your device