The current state of the internet of things (IoT) has been at the top of people’s minds. And why wouldn’t it be? Businesses are using IoT more than ever before. Unfortunately, I’ve found that IT and cybersecurity folks are often left out of IoT implementations at key points.
This wasn’t a surprise to me. CompTIA has been researching how IoT devices are being used worldwide for some time, including in the 2019 Trends in Internet of Things study. Many of the discussions I’ve had with IT pros centered around the myriad security issues surrounding IoT and how to resolve them.
These security issues revolve around an unspoken truth: as an industry, we tend to skip certain steps in the development process, hoping to resolve them later. This practice is called technical debt. And like financial debt, it needs to be addressed before it gets out of control – especially when it comes to IoT.
What Is Technical Debt?
Technical debt happens when a device or piece of software is created and a person or organization consciously (or, sometimes, unconsciously) decides to skip certain steps to quickly release some software or piece of hardware.
The idea is that eventually they will pay back that debt. Ever felt a bit burned when you realize that your new, wonderful operating system seems to be more beta quality than production ready? Ever had your operating system or browser fall victim to a security bug that should have been caught? Well, then, you’ve experienced the results of technical debt. It’s happened to all of us.
IoT as SCADA 2.0
If you are familiar with industrial control systems (ICS) and supervisory control and data acquisition (SCADA), you may find that their development is similar to that of IoT. IoT is more of an evolutionary step in ICS than a revolutionary step: the IoT world is borrowing the same protocols, software development approaches and procedures from the ICS world, which has been networking physical devices for decades. Manufacturers, the oil and gas industry, the energy sector and many other industries have been using ICS and SCADA systems since at least the 1980s.
What does that mean from a practical perspective to the brave new world of IoT? First of all, it explains why early IoT devices have poor, non-updateable firmware, no secure software upgrade paths, little to no authentication and virtually no encryption. After all, most ISC and SCADA systems didn’t, either. Many still don’t.
Many industries are doing their best to apply workaround technologies to their SCADA systems. They can’t update the operating systems or firmware of the software that controls robots, power grids and water delivery systems, so, they install intermediate firewalls, sophisticated security information and event management (SIEM) software and other tools to monitor the issues.
I now refer to IoT as SCADA 2.0. Why not? If IoT is best explained as adding IP addresses to any device, I would image that we should consider IoT an evolutionary extension, really, of what ICS systems have been doing for some time, now.
A lot of folks have started using the term operational technology (OT) as the master concept that contains ICS/SCADA and IoT devices. Yes, operational technology folks started thinking in terms of how to manage dams, pipelines and power grids. But, many of the same principles apply. I would imagine that moving forward, IoT will be discussed as a subset of OT.
Putting IP Addresses on Old Devices
Believe it or not, but the most common IoT devices have existed for years without an IP address. And according to CompTIA's IoT study, companies are spending more time adding networking functionality to existing hardware than they are creating new hardware.
Adding network functionality to old devices is not very easy, but it seems like it should be. You add small (IoT) devices to intermediary physical devices. These then connect to the legacy physical device. The smaller devices contain programming that tells the intermediary physical devices to get the larger, legacy physical equipment to do certain things. This is how organizations are making legacy dams, power grids and other devices ready for remote network administration.
The good thing about this process is that we can better manage our power grids and other foundational services. The potential danger is that we don’t always follow secure software and hardware development standards as we move forward.
Why Can’t We Update IoT Devices?
The way IoT devices are rushed to market makes them pretty difficult to secure, in even the most basic ways. Too often, organizations make decisions to skip vital steps during the software and hardware development process, incurring technical debt, as described above. It is important, though, to understand that incurring technical debt is usually more than the practice of accidentally creating sloppy code.
Incurring technical debt is usually a choice, where an organization commits to fixing that software in the future. The concept is similar to what happens when a responsible person borrows money. That person incurs a debt that they have promised to eventually pay in full. Similarly, incurring technical debt implies that the organization will live up to its implied promise to make good software.
The problem is that many organizations don’t take active steps to re-pay their technical debt. As a result, quality suffers, and problem code ends becoming the root cause of many defects across the business. Security breaches and buggy software combine to make stakeholders lose confidence in the organization. We all, then, suffer – the result of unpaid technical debt.
How to Manage Technical Debt
To get out of technical debt completely, the industry needs to get together and conform to best practices. Organizations can commit to following secure software development lifecycle steps.
But it’s really up to companies to actively manage the debt that they’ve incurred. Heaven knows, I (somewhat) manage my personal debt. If I can do it, then organizations can take the time to manage the IoT devices they use and create.
The most productive way of tackling conscious technical debt is to actively manage development teams so they follow up on any debt that they incur. Follow-up is essential. Development teams will need to review documentation and code to identify the nature of the technical debt and then budget time to address issues in the code.
In the case of accidental, or reckless, technical debt, code reviews, customer input and bug bounty programs can help remediate issues. Organizations are accountable for ensuring regular time is set aside to resolve any technical debt before it piles up or is affected by new changes in the business.
Third, it’s necessary for IT workers of all stripes to learn more about IoT, as well as security. CompTIA Security+ covers security practices for IoT and embedded systems, so IT pros tasked with working on IoT devices can get up to speed on how to protect their devices and networks.
As operational technology evolves to include IoT and a multitude of devices find their way onto your organization’s network, it’s imperative to take steps to protect it. Until industry standards are established, IT pros need to lead the way in securing IoT.
Download the exam objectives to see what’s covered by CompTIA Security+.
