There are two obvoius truths we should start with: Mobile security is a mess, and the internet of Things (IoT) is an (often mobile) area of major activity across enterprises, other organizations and even governments today. Mobile security should be an area of major concern for any organization deploying IoT today, but it's a pretty good bet that it's not getting the attention it deserves. And that’s why this column is so important: IoT deployments do, in fact, represent another major exposure to security vulnerabilities that can truly ruin any IT manager’s day.
The good news is that we can address IoT security and IoT security threats just as we address (or, maybe, just as we should be addressing) mobile, network and IT security overall. However, both the IoT security threats and IoT solutions are evolving so rapidly that mobile and IoT security looks more like a moving target than a realizable goal. True, there’s no such thing as absolute security, and there likely never will be--security will continue to be the one element of IT operations where no one is ever “done.” But we can take steps to mitigate the chances that a major security threat will come into play in any given IoT deployment.
Let’s start, then, with what IoT is. We’re going to use a strict definition of IoT as follows: IoT is a form of distributed computing wherein nodes sense, communicate, process information, make decisions and carry out actions without a human in the loop. IoT, then, isn’t new; over the years we’ve given it names like automation, telemetry, sensor-based computing and machine-to-machine computing. What is new, and here’s where the strict definition of IoT comes in, is that communications within IoT are based on the IP protocol stack that is at the heart of the Internet itself. Since the security elements of these protocols are already paramount, we thus have a head start in addressing the security of IoT solutions. In fact, the activities required for IoT security are already well-defined--again, thanks to the “internet” in IoT--so securing IoT is conceptually no different from what’s already good security practice, as follows:
- First, make sure your security policy is functional and up to date. A security policy is a fairly simple document that defines what information is sensitive, who can have access to it and under what circumstances, and what to do in the event of a breach. Don’t even think of deploying any network-based capability without assuring that security policy considerations are met. And never assume that IoT doesn’t need to be secured: While many IoT applications won’t involve sensitive data, the integrity and continuity of these applications might be as critical as it gets. Use a broad definition, then, of “breach.”
- Ensure that the security tools, solutions and procedures required for the IoT application are in place. In general, IoT traffic should be encrypted like any other (using Wi-Fi’s WPA2 Enterprise, IPsec and similar network capabilities), authenticated (typically using some variant of 802.1X), and monitored and managed by both network and application consoles. Again, basing IoT on internet protocols makes all of this relatively easy, although not all IoT vendors currently do a good job here. Functional verification is always a must.
- Conduct regular operational reviews of all IoT (and, of course, all other) applications to check for unusual or suspicious behavior. Hackers do indeed target IoT, and can cause mischief or worse in building systems like security, lighting and HVAC. In the healthcare industry, such breaches can carry severe penalties; Sarbanes-Oxley (SOX) violations are another key concern. So don’t think “sensor;” instead, think “IoT as a mission-critical capability that must be protected like any other.”
A real benefit of putting the internet in IoT is that mobile IoT applications can be just as easily secured as those that are stationary. But, since many non-IP protocols--particularly in the wireless space--are often being used in IoT applications today, we must relax our definition of IoT just a bit to allow for the integration of gateways between non-IP nodes and the rest of an IoT solution. As an example, consider edge devices based on Bluetooth, ZigBee, Z-Wave or some other non-IP protocol interfacing with an IoT solution through a gateway, and that gateway speaking IP on its back end. Such multi-protocol solutions are likely not optimal for a variety of reasons, but this mix-and-match approach can enable solutions that would otherwise be unavailable if we were to require that every node speak IP.
Bottom line: If any IoT solution, including those provisioned through a gateway, does not meet all organizational requirements for security, then it simply must not be deployed. While security breakdowns make the news on such a regular basis that these often appear to be little more than distractions, the fallout from such events can have lasting, long-term, and even devastating impacts on an organization’s reputation and, ultimately, its bottom line. Security and compromise never go together. The next threat is out there, and, especially in the case of IoT, where automation is an essential element, a security failure might go unnoticed until dire becomes the most appropriate description of the situation.