The Internet of Things (IoT) and Technical Debt: Why It Matters

by James Stanger | Aug 14, 2019
A man uses his smartphone to unlock a door with a smart lock

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+.

4 Comments

  • Aaron

    Friday, August 23, 2019

    You are correct, organizations can commit to following secure software development lifecycle steps. They can even hire people like myself who have a solid background in both software development and Quality Assurance. Yet many times upper and middle management will still choose to circumvent those steps because of the inferred pace of competition in IoT. It's a false inference IMO, one driven by a short term point of view.

  • Oliver Bailey

    Monday, August 26, 2019

    There are a lot of topics this article does not cover. First, IoT is a fairly new acroynm for a technology that has existed for over 35 years. Second, embedded communications more often than not,cfalls outside of traditional IT management because it is device to device communications developed, designed, and managed by engineering specialists with different skill sets. Finally, many of the non-Internet Protocol (IP) systems, are not detected by TCP/IP monitors, because they operate on encrypted ports and in some cases have encryption hardware that is physically replaced every 2-3 days. Should these systems even fall under IT is a question that first needs to be asked. We have WAN based systems that are very secret, have worked for 40 years and have never been compromised. They are not detected by TCP/IP sniffers nor even disclosed to IT departments in many cases. We should be moving more critical mission systems to non-traditional WAN based systems that have higher levels of encryption and less traditional ways of detection for critical control and device to device communications.

  • BN Aseh

    Wednesday, August 28, 2019

    The issue comes about because organizations always seem to be running out of time and the concept of competition and hitting the market first and making that BIG profit often push the personnel at the helm to hasting production. This haste gives such short timeframes for software engineers to meet deadlines that they have no option but to skip vital SECURITY steps. The results is a sweet baked cake placed in a basket with holes through which hackers envy and easily stretch their arms to share; thus causing havoc and instability to the organization's security posture. Security, therefore, should be thought of at the early stages of the inception of building software and should be tested at every step of the SDLC.

  • Someone

    Friday, September 13, 2019

    Oliver has the correct idea. The last thing we need is “IT” “professionals” putting more of their hands in IOT. Yes, IOT is just a buzzword for what the automation industry has been moving towards for decades. The people calling this “Operational technology” are the “IT” crowd, not actual professionals in the engineering, manufacturing, industrial automation, and other related fields. IT should stay where it belongs, as computer and network infrastructure support, supporting the fields doing the actual technical work. The worst thing for this was the day companies started putting IT goofballs in high level corporate positions, the CIOs we are now stuck with. Interestingly, we continue hearing about corporate networks bring compromised.... The nature of many industrial, medical, etc. devices and their applications makes their usual function far more critical than the fact they are networked, and they need to work regardless of “IT” policy, incompetence, the need for mandated OS updates, etc. These areas should be left under the engineering, computer engineering, automation, biomedical equipment, etc fields, worked on by engineers and engineering techs. IT has spilled into everything, with the uneducated corporate impression that everything dealing with technology is “IT” . Rather than give IT reign over yet another area they can “manage” incompetently, leave the critical devices, networks, and applications to engineering, manufacturing, and automation. We can handle that. Keep IT at their help desks, and doing the great job they do with corporate business networks and data infrastructure. Just kidding! The actual technical field people can send them the data they need to back up, lose, etc.... or really just take care of all of it themselves.

Leave a Comment

Boost your Career with a Certification

Find out more about our Certifications

How to get Certified

4 Steps to Certification

Already certified? Let us and others know!

Share Your Story