Successfully implementing IoT requires a change-management approach. Last week’s post discussed how to build your coalition and how to address everyone’s top concern: cost. This week’s post discusses five more common stakeholder concerns:
Posting data to – or transferring data via – the internet seems to be the source of many IT department nightmares – and rightfully so. Hacking is an international industry, producing seemingly weekly announces of security breaches. Hence, putting data online – particularly data related to critical equipment may seem like it would jeopardize your security.
However, many IoT solutions and platforms consider security a core element. For example, Amazon’s Web Services platform regularly employs third parties – i.e., benevolent hackers – to assess security, identify vulnerabilities, and fix them before malevolent hackers can exploit the gap.
IoT security assessments consider security from multiple aspects:
- DATA AT REST
Data housed in applications and databases – whether on-premises or in the cloud – is said to be “at rest.” Most organizations rely on conventional perimeter-based defenses, such as firewalls and anti-virus programs, to protect data at rest. However, hackers find these troves of data irresistible; hence, the Broadband Internet Technical Advisory Group and Cloud Security Alliance recommend employing a combination of hardware and software encryption techniques to ensure the security and integrity of your data at rest.
- DATA IN USE
Data “in use” by an application or gateway must be readily accessible to users and devices, making it the hardest form of data to secure. With in-use data, the security depends on the strength of your authentication procedures and the number of users and devices accessing the data.
- DATA IN FLIGHT
But what about your data when it’s traveling, such as from the device to the cloud?
Well-established internet communication protocols armed with modern cryptography algorithms make it virtually impossible for hackers to decipher data in transmission. But while many IoT devices support multiple security protocols, few enable them as part of their initial configuration. At a minimum, IoT devices that connect to mobile applications or remote gateways should employ HTTPS, transport layer security (TLS), Secure File Transfer Protocol (SFTP), DNS security extensions, and other secure encryption protocols.
Additionally, decoupling information-only data from action data — i.e., using encrypted, one-way, outbound communications — limits your vulnerability should your data-in-flight be intercepted. Wherever possible, set your IoT devices to “fire and forget.” Instead of waiting for a ping requesting a measurement — indicative of a two-way channel — the device will automatically generate a measurement on a pre-established interval or upon a triggering event, push the measurement to the gateway or to the cloud, then discard the measurement data.
Using a mix of public and private infrastructure can also help protect your data in flight. For example, consider the following diagram of a typical Motors@Work installation: Even if a hacker uncovers and manages to decrypt both communication pathways using public infrastructure, s/he lacks sufficient information for them to damage our clients’ assets. For example, if the hacker intercepts and decrypts data at Point A, s/he will only see current, voltage, and an asset ID number; at Point B, s/he will only see Motors@Work’s content for one work request. Removing the context needed to understand the data and the ability to use the channel to send a signal back to the asset minimizes the data’s value to a hacker. Then, having operators validate data and determine whether to accept the asset performance management (APM) system’s recommendation creates an air-gap between EAM and SCADA. Finally, using a private (e.g., RF), encrypted network for your SCADA control signals hardens the system’s feedback leg.
2) Your technology infrastructure
Often, Motors@Work clients have instruments tied into SCADA that generate the data we need to provide our analytics and insights. Or, even if they lack power monitoring equipment, SCADA’s network potentially could provide the communication infrastructure needed to connect new instrumentation. Yet, almost universally when our champion asks to tie into SCADA, IT replies, “Our network is super secure and cannot be used to send information to an IoT platform” — and rightfully so.
As discussed under the security of in-flight data, the most secure networks rely on one-way, outbound-only communication. SCADA, being a supervisory control network, necessarily must handle control signals going to your equipment.
There are two ways to ensure secure data transmission to your APM: First, connect the APM to SCADA’s historian. The historian, a database record containing all instrument readings and control actions, typically resides in a demilitarized zone, or DMZ, where it can be accessed by internet-connected applications; however, these applications can only view the data stored in the historian. Only SCADA can write to this database, typically by sending an interval-based outbound signal to the historian. Many enterprise asset management (EAM) systems use SCADA historian data to populate dashboards.
The second option involves using an independent infrastructure, such as cellular service, to directly send data to the IoT platform without connecting it to SCADA. Direct cellular data upload is a great solution for facilities that lack networking infrastructure. Typically, you can connect up to five devices to a single cellular gateway device, and all you need is a 120-Volt outlet to power for the cellular gateway. Several companies offer pre-configured cellular instruments, making it possible to deploy and connect hundreds of instruments within days.
3) Available public communications infrastructure
Perhaps using a cellular gateway to connect IoT instruments sounds great — except you don’t get phone reception at some of your more remote sites. And building your own infrastructure would simply be too costly. So don’t.
Although LTE-M and LTE-NB use existing cellular towers, these low-powered, wide-area networks provide much broader coverage. Even if you don’t get a strong-enough signal for voice calls or 4G-LTE data, you may still be able to access LTE-M.
4) Immaturity of IoT standards
Understandably, nobody wants to be the one who invested in IoT’s version of Betamax. Analysts equated protocols emerging from the early IoT industry as a “cacophony of discordant musicians.” Waiting to see which standard or protocol would win lead many organizations to delay their IoT investments.,
While some IoT standards are still in development, and there’s still a lot of fragmentation in the market, standards affecting currently available devices were generally ironed out in 2016 and 2017. The Open Connectivity Foundation joined the Open Interconnect Consortium in pushing a united protocol. And IEEE published its draft p2413 standard for IoT architecture, creating a universal language for IoT that would greatly reduce the effort required to share data betwixt competing platforms. That means regardless which platform you pick, you’ll soon be able to share data across all IoT devices and platforms.
5) Procuring IoT
Implementing IoT often involves procuring devices and services that don’t have IoT in their name, such as instrumentation, communication networks, storage, and data management consultants. The complexity of procuring these services and the lack of the IoT label can make it difficult for stakeholders to see how the multitude of pieces fit together. But, as we’ll discuss next week, the right plan can streamline this complexity and help you communicate each piece’s importance to the overall project.
How will IoT benefit your organization? For more practical ways to use IoT to make smarter asset management decisions, email us at firstname.lastname@example.org.