The number of IoT (the Internet of Things) devices has exploded in the last several years, with many organizations looking for opportunities to connect devices across a range of business processes to improve operations, increase opportunities for revenue, or get access to valuable business data.
The problem is that in many industries, the devices that collect this data, and the networks they must communicate over, are outdated, past their prime, or downright primitive by today’s standards.
So, how can you find a way to secure devices and networks that can’t work with modern security software?
This is the second in a series of interviews with Lin Nease, a Chief Technologist for IoT at Hewlett-Packard Enterprise, to learn more about what organizations can do to secure their legacy IoT systems and extend their useful life.
🔎 Related Articles: Your Ultimate Guide to Mobile Device Security
Defining the Current State of IoT
Why is there so much legacy technology in the IoT space?
Lin: Today, if you walk around any industrial operation, you will encounter assets that are 20, 30 or more years old. You can see examples in manufacturing, electrical utilities, oil refineries, mining operations, and more.
These assets have a useful life that is much longer than IT assets. That's going to change in the future because more and more of these older or outdated assets are becoming connected computer systems of some sort.
While these assets have never been connected in the past, digital transformation projects in many companies are about to change that.
You can divide the types of assets currently in use today into two classes. There's the class of assets that were built and never expected to be IOT devices. And then there is a second category -- devices which were built specifically to collect data and be used for IOT purposes, but they themselves may be outdated at this point.
Lin: Yes, agreed.
There are the older systems, embedded in operational machines, never intended to be connected. The second class would be proprietary appliances, which we might perhaps call “first-generation” Industrial IoT (IIoT) devices.
These are purpose-built products from various operational technology vendors, who for years created walled gardens for their own software and hardware. They did so to sell a whole solution, and because they solve important problems, they've been able to.
That world is changing however. Now these systems need to be connected to other vendors and other software. That's a different type of legacy.
You can contrast those examples with the ultra-modern IOT devices.
For example, take a high definition, 3D camera that’s being used for some sort of pattern recognition -- let's say surveillance in an airport terminal. That camera is connected directly onto an IP network, works with anybody’s AI solution, and runs modern software that can be managed and patched remotely.
🔎 Related Articles: Your Complete Guide to Building an NSA CSfC Approved Solution.
Why legacy IoT technology isn’t going away
The truth of the matter is that legacy systems aren’t going away any time soon. The “old” technology these processes and systems are built upon still work just fine for their primary purpose, so why spend tons of money to replace them just to bolt on IoT functionality?
Lin: The truth is, the diaper cutting machines, mixing machines, pumps, boilers and compressors that have run operations for years are probably going to be just as viable five years from now.
There is great value to not just outfitting these systems with IoT functionality, but actually prolonging their useful life – something the organization has already invested in.
If we find a way to make a piece of machinery provide value for longer, we’ve increased the project’s ROI.
A big question is whether industry is really prepared for capital equipment to become obsolete on a similar life cycle to computer systems – three to five years. If that does happen, it will be a big problem, as most industries have not truly come to terms yet with the digitization implications.
Beyond just the individual machines or systems going obsolete on a one-off basis, by nature of the type of data that most companies want to capture and use in an IoT application, the collection of that data itself relies on diverse legacy technologies.
Lin: That’s very true. At HPE, we've actually crafted an entire product family around that exact problem. We created a completely new server family called Edgeline, whereby data can be ingested from a rich variety of legacy interconnects and protocols.
Many applications require industrial connections for sensors, like Modbus, Profibus, EtherCAT, CAN bus, and many more. It's an alphabet
soup of various protocols that got separately created over the years.
Once data is ingested, it can be handled like any other data in a modern server system, with your standard TCP/IP networking, and modern streaming protocols. Things like Kafka, MQTT, NiFi... all the latest and greatest stuff.
We’ve had to create a server that sits as a bridge point between those two worlds because they simply don’t work together otherwise. And that's the category of product that has emerged to address some of this separation of old and new.
We call them gateways, or edge servers.
How can you secure legacy IoT systems?
What are the biggest security concerns with taking those outdated pieces of hardware, or outdated network equipment, and suddenly making them all connected?
Lin: When there are devices connected to legacy interconnects like this, they must be “front-ended” onto modern networks in order to communicate.
This is what a gateway system does.
A gateway may connect dozens or even hundreds of compressors’ or pumps’ sensors to IP networks. It collects their data, aggregates it, and sends it onto the IP network -- the modern network -- to the rest of the systems on that modern network.
To the network, it looks like there is just one system doing all the talking, while in reality there are maybe hundreds of them. And from the network perspective, there’s a limited ability to see past that system to the devices on the other side.
Usually, because of the number of devices, we simply can't converse directly with those endpoint devices and must converse through a gateway. That significantly limits the visibility into how they're connected and their individual characteristics. That creates risk, and significantly limits the ability to manage these devices.
Most importantly, this multiplies the difficulty of detecting if these devices have been compromised.
The only way to really guarantee the level of trust you need is through a hardware-based security solution very close to the endpoints themselves.
Depending upon the number of devices you are connecting, you may be able to utilize hardware-based security solutions to be able to individually connect each device to the primary network, rather than a gateway aggregator. This solution is ideal if you can find a cost-effective way to outfit each endpoint device.
Lin: If you are able to use hardware that allows you to connect each of those endpoint devices individually, securely, and cost-effectively, instead of aggregating many of them through a single talker on their behalf, that changes the game.
That would allow these devices to be individually trusted.
Cost is a critical issue here however; If you've got a bunch of $500.00 pumps, you can't afford to add another $500.00 device to each pump.
It's hard to imagine any digital use case for that data sufficiently compelling to double the cost of the asset.
What are the requirements for the security of my IoT system?
What would you say are some of the biggest compliance-related concerns that different industries might have or should be aware of as they're considering outfitting their equipment?
Lin: Well, every industry has compliance criteria, for both safety and security.
While I'm not an expert on all the various compliance criteria specifications, I do know that there's a reliance on things like the NIST standards, which are used for military specification-level IoT deployments.
They require a combination of digital security, physical security, and logical security, and in some cases, industries augment them with things like explosion proofing and tamper-proofing.
There are many, many different criteria out there to secure systems.
Many IoT systems have the added wrinkle of needing to be deployed in certain environments – for instance, being able to survive a fire, extreme temperatures, or a dusty condition.
How to approach deciding on the security aspects of your IoT deployment project
What is the best first step to take in determining how to approach your project deployment?
Lin: There are two viewpoints to start from – network topology and business process benefit.
The topology viewpoint takes into account how your network is arranged, and how many communicating devices you realistically will need. Take a look at how they connected today if they are at all.
Visualizing the topology will help make your next step after that become obvious. You will have a better understanding of what you can and cannot do because the physics of your choices will become more obvious to you when you really draw a topology of it.
The other viewpoint is the reason why you are undertaking the projects or the goals you have for it.
You're doing these things for a reason. What are the processes you’re trying to change as a result of this transformation project? If you’re trying to take a production process, for example, and remove the configuration time of people, then it's going to become evident which use cases will drive the priorities for the project.
You will want to task your people with bringing back information about things that will immediately lead to an ROI discussion. What are the process improvements we expect to see? And then, how big is the physics problem to actually collect the data we need to do that?
