As most technologists are already aware, the Internet of Things (IoT) is here, and it’s here in force. Not only are we seeing smart sensors and devices used for wide-scale applications, like logistics, municipal applications (e.g., parking, traffic, and air quality), and numerous other use cases, we’re also seeing consumer applications as well: household appliances, automobiles, smoke detectors, and thermostats. There are even some more fanciful applications, like a smart fork that monitors your eating habits to alert you when you’re eating too quickly.
These advances have received, and are likely to continue to receive, quite a bit of industry attention. The IoT is literally everywhere: analysts are covering it, it’s in the daily headlines of the trade media, people are discussing it near continuously in peer networking and at industry events, and entrepreneurs are building businesses around it as we speak. It’s huge.
The latest ISACA Risk/Reward Barometer found that 43 percent of organizations already have—or expect to create in the next twelve months—plans for the IoT. But there’s an elephant in the room: support. Support and, by extension, security.
43% of organizations already have—or expect to create in the next twelve months—plans for the IoT.
These two areas aren’t covered with anywhere near the regularity of other aspects of the IoT. But when you scratch the surface, they’re every bit as important to enterprises as usability and functionality. Support and security considerations not only have far-reaching implications for the IoT now, but as these devices and usage scenarios continue to proliferate, they’re likely to become even more important. As enterprises see more and more network-connected devices come into the technology ecosystem, these two oft-overlooked elements are paramount to ensuring that organizations stay productive and protected in the IoT world.
What’s New About the IoT?
To understand why this is the case, it’s important to unpack a bit about the market forces that are driving IoT in its current iteration. Specifically, why are we seeing such a rapid expansion of embedded computing and networking elements now? Easy: Because the IoT isn’t new. In fact, the concept was discussed as far back as 1982, when a soft-drink machine was integrated into the Internet. And it wasn’t just discussed once and dropped. All throughout the 1990s and the early 2000s, there were discussions about the integration of computational elements into daily life and objects. Believe it or not, there’s even a little-known (and seldom implemented) HTTP response code (HTTP code 418, defined in 1998 by RFC 2324) that allowed the response “I’m a teapot” in the event a web-connected teapot was requested to brew coffee. Granted, this was an April Fools’ prank, so it was never intended to be taken seriously, but it should at least serve to illustrate that the concept was there and being actively discussed almost twenty years ago.
But if all that seems too fanciful, consider that embedded computing and networking capabilities in purpose-built devices have existed in actual production deployment in various industry sectors for years. Consider a hospital for example: The diagnostic equipment, like MRI machines and other imaging devices, are IP-connected, as are biomedical tools like patient monitors, lab equipment, medicine dispensers, and most of the rest of the clinical environment. In manufacturing or energy, it’s industrial control systems. In retail, it’s points of sale. All throughout the corporate world, there are purpose-built “utility” devices that have embedded computing and network capabilities.
The point is that, as a concept, not only is the IoT not new, it’s actually something that many organizations are using to a significant degree already. What’s different now is scale. In the past, adding these networking and computing elements to a device was comparatively expensive and difficult to engineer (for example, due to size and power considerations). From a cost perspective alone, integrating these capabilities could raise the purchase price of a device enough to make that integration impractical. What’s happening now? Costs are coming down. As the costs come down and computational elements become commoditized, it opens up more and more avenues for integration. The costs of allowing new use cases that leverage those integrated components will cease to be prohibitive.
Not only is the IoT not new, it’s something that many organizations are already using. What’s different now is scale.
Why IoT Ups the Ante
Why does this matter from an enterprise point of view? It’s important because it should inform us (indirectly) about the path into the enterprise that network-capable devices are likely to take. Meaning, if it’s economics that are driving the boom (i.e., it’s becoming economically advantageous for device manufacturers to incorporate these elements into the goods they sell), we should expect prevalence to increase quickly and contemporaneously across manufacturers, since competition among manufacturers will cause them to compete among each other to integrate features quickly. If that’s true, we should then expect it to proliferate within our organizations from the grassroots level. This matters from a support standpoint because that means the stage is set for a rapid influx of “shadow” usage. And, from dealing with cloud for the past few years, we all know how challenging shadow usage can be in high volume.
As an example of how this can happen, think about in-place replacement of existing devices. What happens when a default option for a refrigerator is built-in computing capability? Or when a stock option for a new vehicle purchase includes an IP-connected navigation system? If a business unit, remote office location, or whomever (outside of IT) replaces an old and non-IP–connected device/appliance with a new, IP-connected one, what happens? Maybe a remote field office replaces a smoke detector because the old one fails or is worn out. Maybe they happen to choose one with built-in communication capability (for example, to alert the manufacturer about the need for service, or to alert the fire department in the case of an emergency). Who supports that? If it turns out that attackers can remotely gain control of the device because of a security vulnerability, what’s the pathway for getting that remediated? Will the IT department even know it’s there so they can take action?
In a situation like that, the best-case scenario is that the IT department has a way to become alerted to the presence of that device, in which case, though it’s additional overhead on their workload, at least the situation is being remediated. That might not be great, but it’s probably better than the alternative: nobody knows it’s there and it becomes a source of potential (untracked) risk to the organization.
There could be compliance ramifications in addition to security implications. A thermostat, smoke detector, or refrigerator might not seem like a big deal, but keep in mind it’s probably not designed with the kind of robust security you’d expect for a trading floor, retail location, etc. But is it possible that these devices could be installed on those networks? It is. For example, a well-meaning office manager at a retail store might put a smart device on the same network as the points of sale; a well-meaning physician might put a smart TV onto the same hospital network where patient data is flowing. Both of these directly impact the regulatory environment (in the first case, PCI; in the second, HIPAA). Unless you’ve thought it through and have a plan, situations like this translate directly into unmanaged risk.
Building the Plan
The operative phrase in the above is “unless you have a plan.” Without one, a proliferation of smart devices might very well be a source of unmanaged risk. With one, you may still incur some technical risks as a result of these devices (and benefits, of course), but at least you’ll know what and where they are. You can add it to your risk management activities and account for it just the same as you would for any other business activity.
Without a plan, the IoT might be a source of unmanaged risk. With one, you may still incur some technical risks, but at least you’ll know what and where they are.
How do you construct that plan? Obviously, specifics will vary based on factors unique to you: things like your support and security requirements, your unique circumstances, the business you’re in, your risk tolerances, etc. That said, there are a few things that are more likely to be universal. For example, start by defining what the IoT means for your purposes. This can be more complex than it might initially sound; consider that general purpose computing devices come in a variety of different form factors. What’s the difference between a device with different form factor than a laptop or desktop and the IoT? Good question. This why it might be helpful to use operating systems as part of your barometer for what constitutes IoT in your plan. Meaning, maybe it includes anything that runs a nonstandard, proprietary, or “closed” platform (i.e., other than Android, OS X, iOS, Windows, Linux, etc.) Maybe it includes certain categories of devices, like wearables, regardless of OS, but discounts others that you’ve already defined policies and standards for, like mobile phones. So, first step is defining what you mean and what the scope is.
The next step is getting a handle on what you have in this category today, because you almost certainly have something. If you have conference rooms and those conference rooms have TVs in them, chances are pretty good that at least a few are Internet-capable. You’ll ideally want to formulate a strategy that will help you find the devices you’ve fielded today, but you’ll also want it to help you find new devices should they “magically” (i.e., through shadow adoption) appear down the road. Useful techniques for this could include leveraging vulnerability scanning activities; for example, if you do an internal scan of your network, you might scour that output looking for devices that fall into the category you defined (e.g., printers, televisions) For those using 802.1x Port Access Control, this can help you locate (and, of course, enforce) devices.
As you identify devices, you’ll want to build out an inventory of what you find. If you have an inventorying tool that you use already for general asset management or other purposes, consider consolidating this information there. This could be a GRC tool like Archer or Modulo, a support tool like BMC Remedy, a BCP/DR tool, or any other tool that can collect and house this information. If you don’t have one already, keep in mind that there are freeware alternatives (e.g., Spiceworks) and open-source options (e.g., OCS Inventory NG). The point is, you want to have a place where you can capture a master list that you can maintain about which devices are out there, who maintains them, which contacts are responsible for them, what types of device they are, maintenance history, etc.
Lastly, you’ll want to put some thought into who will support these devices from an operational standpoint and what the process will be for doing so. ISACA has consolidated its guidance and research data into nine key questions to ask to improve IoT risk management, including questions about support considerations, monitoring responsibilities, risk management, etc. This can be a useful starting point as you think through operational and management impacts. Because, depending on what the device in question is, it may very well not be the folks you’d expect. For example, in our healthcare example from earlier, there’s very often a specialized biomedical engineering group that’s responsible for maintaining clinical equipment, including IP-connected equipment. Since the stakes are high (these devices can have a health and safety impact on patient care), those folks are uniquely qualified and specially trained for supporting those devices. Point being, there should be a way to determine who maintains what.
From there, support is very similar to what we’ve experienced since time immemorial. You’ll want to have a plan for becoming alerted to, and responding to, security and support notifications from vendors, and conducting incident response activities and other general support hygiene. Even though you’re applying these processes to different types of devices, other than general purpose computing equipment, the tasks themselves haven’t changed.
At the end of the day, the IoT doesn’t have to be new or scary. We’ve had waves of new technologies over the years make their way into our organizations—cloud, mobile...even the PC was new once upon a time. And, in each case, by applying the same principles of sound risk management and IT discipline, we’ve been able to successfully integrate those technologies into our environments to the benefit of our business partners. All that’s required is to keep from panicking, understand the risks, be disciplined, and apply risk management principles.
Industry veteran Rob Stroud is the vice president for Innovation and Strategy, CA Technologies’ IT Business Management organization. Rob is a recognized thought leader and global authority on ITSM, governance, and cyber-security, having contributed to industry knowledge in multiple publications, including COBIT and Guidance for Basel II. Rob is a former chair of the COBIT Steering Committee, the international president of ISACA, and a former treasurer and director of audit, standards, and compliance for the itSMF International Board.