The Definitive IoT Security Policy Checklist
OK, so given what I said last time, you’re probably thinking that IoT security isn’t a special case in any way – whatever your current security policy states applies to IoT in exactly the same way as any other security consideration. And you’d be mostly right.
IoT has some additional considerations, however, worthy of addition to any security policy, and these are as follows:
- Adapting the basics – As we saw with the examples presented last time, IoT devices have to this point been notorious for having lax to non-existent security. The obvious considerations are unsecured connections and failure to change default network and device passwords, perhaps because IoT devices often lack a contemporary user interface with which to quickly and easily do so. This is, however, changing, thanks to the greater availability of management apps or built-in Web-server functionality, and vendors who take security more seriously. Even with these improvements, however, it’s unlikely that IoT devices will be in compliance with very many authentication policies today, and I’ve personally never seen two-factor authentication in any IoT device.
It goes without saying that all network traffic should be encrypted, and any IoT device that does not support such encryption must be rejected from any further consideration. It’s not easy today to integrate IoT devices into mobile device management (MDM) and overall enterprise mobility management (EMM) strategies and solutions (including management consoles and directory services), even though the need is obvious.
Finally, only cleared (trusted) personnel should be allowed access to management systems that configure, monitor, and control IoT (and any other) solutions. Background checks, regular training and reinforcement, and management oversight and audit are all essential.
- Establish strategic fit – The value of IoT in everyday applications from healthcare to smart buildings to municipal government is growing, but any IoT functionality must fit with overall organizational and IT objectives, strategies, policies, and procedures. A rule we follow at Farpoint Group is to always say no before we say yes – any IT functionality, from new hardware to traditional applications, apps, and, yes, anything related to IoT must be evaluated for performance, strategic and mission fit, reliability, and especially security. All IoT functionality including security must be verified in isolated and non-mission-critical beta deployments before an (always staged) rollout is begun. No volume deployments can be permitted until the proposed solution passes a functionality and security checklist – no exceptions!
- The configuration challenge – This is a major issue for me. We really need a standard for IoT device configuration, ideally from an industry standards body or trade association, and ideally with open-source implementations available. Configuration must include, of course, setting user-visible features via a common user interface, but also firmware updates, and both with more than just lip service to security. We need standard mechanisms for reporting and monitoring – in other words, for integration into already-deployed management systems. The hodge-podge of techniques currently deployed is an invitation to security problems, and must be addressed immediately.
A final consideration is the choice of IoT communications technology. There are many to choose from in the IoT world, from Bluetooth to ZigBee, Z-Wave, 6LoWPAN, Thread (a protocol), and many more, including proprietary, in which case gateways and their security become critical.
While the choice here will almost always be made by the vendor of a specific device, Farpoint Group believes that Wi-Fi will be by far the most important technology for IoT networking. Why? Simple. Wi-Fi is already ubiquitous throughout the world today, in governments, organizations, residences, public spaces – everywhere, and thus Wi-Fi-based IoT solutions can leverage existing network infrastructure and capacity with little to no added cost or effort. IoT is really just another class of applications, and contemporary Wi-Fi can easily support any application requirements today.
Important for our discussion today, Wi-Fi already has the inherent over-the-air security required, in addition to the throughput and traffic prioritization essential to provisioning the capacity required by any application. Wi-Fi can easily handle time-bounded traffic, including real-time streaming high-definition video. Low-power, low-cost, and small-form-factor implementations are widely available.
Wi-Fi also continues to advance in terms of overall capabilities, driven by both the IEEE 802.11 Working Groups as well as the Wi-Fi Alliance. In short, if there’s another wireless technology that can fit the totality of the IoT bill, I’d like to hear about it. Yes, some very-wide-area applications will require LTE services, but these will be used only when absolutely necessary – LTE, after all, operates over licensed spectrum and thus there’s a real cost involved, and LTE can’t offer anything close to Wi-Fi’s capacity. 5G? Wi-Fi is already there!
So all of this begs the question: What can Wi-Fi system and network-equipment suppliers do to make the vision of robust, available, and secure IoT a reality? Plenty. More on that next time.
All Posts In This Series: