Skip to content
PM Certification

Industrial Internet of Things (IIoT) Tutorial

Rate this post

The industrial internet of things (IIoT): An analysis framework

ABSTRACT

Historically, Industrial Automation and Control Systems (IACS) were largely isolated from conventional digital networks such as enterprise ICT environments. Where connectivity was required, a zoned architecture was adopted, withfirewalls and/or demilitarized zones used to protect the core control system components. The adoption and deployment of ‘Internet of Things ’(IoT) technologies are leading to architectural changes to IACS, including greater connectivity to industrial systems. This paper reviews what is meant by Industrial IoT (IIoT) and relationships to concepts such as cyber-physical systems and Industry 4.0. The paper develops a de finition of IIoT and analyses related partial IoT taxonomies. It develops an analysis framework for IIoT that can be used to enumerate and characterize IIoT devices when studying system architectures and analyzing security threats and vulnerabilities. The paper concludes by identifying some gaps in the literature.

Introduction

The concept of Industrial Automation and Control Systems (IACS) is well established. These systems often referred to as Operational Technology (OT), are employed in diverse industries including manufacturing, transportation and utilities, and are sometimes referred to as cyber-physical systems (CPS). Since the term Internet of Things (IoT)  was first used in 1999, it has been applied to connected devices in consumer, domestic, business and industrial settings. Although there is a sign ficant amount of literature attempting to define IoT, its uses, and its typical components, it is rarely made obvious how any of this applies in the industrial setting.

Because current definitions of IoT invariably imply a similar approach to the high-level architecture of a system, the ubiquitous use of the term IoT to refer to the use of digital technologies in the industry is unhelpful as it hinders the analysis of alternative system architectures, including the location and nature of the data or information processing, and associated performance and security issues. The aims of this paper are to improve on existing defi nations of Industrial IoT (IIoT) and to propose a framework for IIoT components as a basis for analyzing the use and deployment of IoT technologies in industrial settings. In undertaking this research our aim was to establish a framework that allows us to analyze the nature of IIoT devices and their uses, which is to be used as part of a vulnerability and threat analysis process for these devices. By being able to characterize the devices in a systematic manner, we anticipate being able to analyze cross-cutting threats and vulnerabilities and identify patterns that may be obscured when focusing on the technology employed or sector speci fic issues. This paper is structured as follows: Section 2provides some further background to CPS, IACS, and the Industrial Internet, setting it against the background of Industry 4.0. Section 3provides our analysis and defination of IIoT, which builds on existing explanations that are presented. Section 4presents our framework. Finally, Section 5 identifies gaps in the current literature that need to be addressed in future work.

Background

Whilst researching IIoT we have reviewed a wide range of academic literature and found that when combining the search terms:

(“ Industrial Machines ”OR “Industrial Systems ”) AND “Internet ”OR ( “ Industrial Internet ”) AND “Machines ”

The following terms were amongst those most regularly found:

Cyber-Physical Systems (CPS), Industrial Control Systems (ICS), Supervisory Control and Data Acquisition (SCADA), and Industrial Internet.

Although not an exhaustive list, it does represent the most commonly used terms in both academic and relevant non-academic literature, for white papers and corporate blogs. In the rest of this section, we define Industry 4.0 and review the above terms before moving on to develop our de finition of IIoT and the taxonomy.

https://doi.org/10.1016/j.compind.2018.04.015
Received 7 December 2017; Received in revised form 21 March 2018; Accepted 20 April 2018
⁎Corresponding author.
E-mail address: [email protected] (H. Boyes).
Computers in Industry 101 (2018) 1– 12
0166-3615/ © 2018 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY license (http://creativecommons.org/licenses/BY/4.0/).

Industry4.0

The first three industrial revolutions are characterized as being driven by mechanical production relying on water and steam power, use of mass labor and electrical energy, and the use of electronic, automated production respectively [3]. Whilst the supposed fourth industrial revolution ( ‘Industry 4.0 ’) was first proposed in 2011 in the context of the goal of developing the German economy [4]. This revolution is characterized by its reliance on the use of CPS capable of communication with one another and of making autonomous, decentralized decisions, with the aim of increasing industrial e fficiency, productivity, safety, and transparency.
There is a considerable overlap between the concept of Industry 4.0 developed in Germany and the Industrial Internet concept (see 2.6), which originated in the United States. The defi nation of the latter now encompasses change for both business and individuals:

“…the industrial internet is an internet of things, machines, computers and people enabling intelligent industrial operations using advanced data analytics for transformational business outcomes, and it is rede fining the landscape for business and individuals alike”.
A de finition of ‘Industrie 4.0 ′a term which, in its English cognate, the authors treat as synonymous with IIoT, is:

“…we define Industrie 4.0 as follows: Industrie 4.0 is a collective term for technologies and concepts of value chain organization. Within the modular structured Smart Factories of Industrie 4.0, CPS monitor physical processes, create a virtual copy of the physical world and make decentralized decisions. Over the IoT, CPS communicate and cooperate with each other and humans in real time. Via the IoS [Internet of Services], both internal and cross-organizational services are o ffered and utilized by participants of the value chain. ”

Cyber-physical systems (CPS)

Whilst there are a number of defi nations of CPS[7–11] , this paper uses: “A system comprising a set of interacting physical and digital components, which may be centralized or distributed, that provides a combination of sensing, control, computation and networking functions, to in fluence outcomes in the real world through physical pro-
cesses. ”
What sets CPS apart from more conventional information and communications systems (IT or ICT) is the real-time character of their interactions with the physical world. Whilst both CPS and ICT systems process data and/or information, the focus of CPS is on the control of physical processes. CPS uses sensors to receive information about, in- including measurements of, physical parameters, and actuators to engage in control over physical processes. CPS often involve a large degree of autonomy. For example, CPS often have the capacity to determine whether to change the state of an actuator or to draw a human operator ’s attention to some feature of the environment being sensed.

Industrial automation & control systems (IACS)

IACS or ICS is a collective term typically used to describe di fferent types of control systems and associated instrumentation, which include the devices, systems, networks, and controls used to operate and/or automate industrial processes. Descriptions of ICS from authoritative American and European organizations are respectively:

“ Initially, ICS had little resemblance to traditional information technology (IT) systems in that ICS were isolated systems running proprietary control protocols using specialized hardware and software. Many ICS components were in physically secured areas and the components were not connected to IT networks or systems. Widely available, low-cost Internet Protocol (IP) devices are now replacing proprietary solutions ”; and

“Today ICS products are mostly based on standard embedded systems platforms, applied in various devices, such as routers or cable modems, and they often use commercial o ff-the shelf software ”and “ command and control networks and systems designed to support industrial processes. The largest subgroup of ICS is SCADA ”.

Supervisory control and data acquisition (SCADA)

SCADA has been described as:

A system that allows an operator, in a location central to a widely distributed process, such as an oil or gas field, pipeline system, or hydroelectric generating complex, to make setpoint changes on distant process controllers, to open or close valves or switches, to monitor alarms, and to gather measurement information;

Similar to a Distributed Control System with the exception of sub-control systems being geographically dispersed over large areas and accessed using Remote Terminal Servers. Where a Distributed Control System (DCS) is a supervisory control system typically controls and monitors set points to sub-controllers distributed geographically throughout a factory; and

SCADA applications are made up of two elements: the process/ system/machinery you want to monitor and control, which can take the form of a power plant, a water system, a network or a system of traffi c lights; and a network of intelligent devices that interface with the first system through sensors and control outputs. This network, which is the platform system, provides the capability to measure and control specific elements of the first system.

The nature of SCADA has led to con flicting views as to whether it forms part of the IIoT ecosystem. For example, discussion of SCADA system forensic analysis within IIoT contrasts with a view that SCADA is simply the predecessor to IIoT especially as SCADA systems have evolved to connect to the internet but do not have the analytics and level of connectivity that is found in IIoT.

Industrial internet

The concept of an Industrial Internet was first articulated by General Electric (GE), and described as:

“ The defi nation of the Industrial Internet includes two key components: The connection of industrial machine sensors and actuators to local processing and to the Internet; The onward connection to other important industrial networks that can independently generate value. The main di fference between the consumer/social Internets and the Industrial Internet is in how and how much value is created. For consumer/social Internets, the majority of value is created from
advertisements ”.

This description clearly separates the Internet and the Industrial Internet, although in both cases the function of the Internet is to provide wide area networking. More recently the Industrial Internet has been defi ned as:

“… a source of both operational e fficiency and innovation that is the outcome of a compelling recipe of technology developments. The resulting sum of those parts gives you the Industrial Internet —the tight integration of the physical and digital worlds. The Industrial Internet enables companies to use sensors, software, machine-to-machine learning and other technologies to gather and analyze data from physical objects or other large data streams— and then use those analyses to manage operations and in some cases to offer new, value-added services ”. From this definition, it is apparent that the authors consider a key component of the Industrial Internet to be the ability to analyze data, which is corroborated by a statement later in their report, in which it is stated that “⋯Big Data analytics is the foundation of the Industrial Internet…”. This desire to collect and analyses data is a feature in common with Industry 4.0.

Industrial internet of things (IIoT)

Whilst there are numerous IoT defi nations, those of relevance to industrial application make explicit the kinds of smart components that get embedded into ordinary objects so that those objects can count as IoT devices, and form constituents of cyber-physical systems (CPS). Three relevant defi nations are:

Adefinition for the IoT would be a “group of infrastructures, interconnecting connected objects and allowing their management, data mining and the access to data they generate ”where connected objects are “sensor(s) and/or actuator(s) carrying out a specific function that are able to communicate with other equipment ”[24] ;

• “The terms ‘Internet of Things ’and “IoT” refer broadly to the ex- the tension of network connectivity and computing capability to objects, devices, sensors, and items not ordinarily considered to be computers. These “smart objects ”require minimal human intervention to generate, exchange, and consume data; they often feature connectivity to remote data collection, analysis, and management capabilities ”; and

“The IoT represents a scenario in which every object or ‘thing ’is embedded with a sensor and is capable of automatically communicating its state with other objects and automated systems within the environment. Each object represents a node in a virtual network, continuously transmitting a large volume of data about itself and its
surroundings …”.

On the basis of these, an initial defi nation of IIoT might be the use of certain IoT technologies –certain kinds of smart objects within cyber-physical systems –in an industrial setting, for the promotion of goals distinctive to industry. Similar simple defi nations were found in our literature search, for example:

“ The Industrial Internet of Things (IIoT) is the use of Internet of Things (IoT) technologies in manufacturing ”; and

“Industrial Internet: A short-hand for the industrial applications of IoT, also known as the Industrial Internet of Things, or IIoT ”.

Such a simple concept is not sufficient for our purposes in this paper, however. We need something substantive and a precise conception to inform our proposed IIoT framework. The simple conception does provide a template for a definition of IIoT, for it correctly attempts to define IIoT by appeal to two essential features: (a) the kinds of technologies that are used in an IIoT setting and (b) the distinctive aims and purposes to which those technologies are put. We need a de finition which has that structure, but which gives us a more substantial ex- pension of (a) and (b).

An advantage of the simple concept is that because it makes it clear that the relevant technologies are used for purposes distinctive to industry, it satisfies the basic criterion of enabling us to distinguish IoT devices from IIoT devices. For example, devices such as smart bike locks and smart kettles are not useful from the point of view of industry per se, the simple conception correctly classic fies those items as non-IIoT devices. Despite this advantage, the defi nation remains uninformative nevertheless.

A further pitfall to avoid when attempting to arrive at a de finition of IIoT is defining IIoT in terms of some other notion, which is not obviously di fferent from the notion of IIoT itself, which would render the de finition uninformatively circular. That sort of problem is exemplified in the industry-driven literature by, for example:

“The IIoT vision of the world is one where smart connected assets (the things) operate as part of a larger system or systems of systems that make up the smart manufacturing enterprise”.

Since ‘smart manufacturing enterprise ’is essentially an industrial enterprise that exemplifies fies the features of IIoT, this definition is also uninformatively circular.

In seeking to formulate an improved conception of IIoT we searched the contemporary academic and industry-driven literature for more informative defi nations than those already cited. We found a few that improved on the simplistic and circular defi nations already presented. Ade finition that improves incrementally over the simple de finition is:

“Industrial Internet or Industrial Internet of Things (IIoT) is built for bigger ‘things ’than smartphones and wireless devices. It aims at connecting industrial assets, like engines, power grids and sensor to cloud over a network ”.

This defination goes beyond the simple conception by making it explicit that it is industrial assets which are counted as connected in an IIoT setting, and it tells us a little about the nature of that connection: that the relevant assets are connected to a cloud, over a network. A second defi nation which adds some further details is:

“ The Industrial Internet of Things (Industrial IoT) is made up of a multitude of devices connected by communications software. The resulting systems, and even the individual devices that comprise it, can monitor, collect, exchange, analyze, and instantly act on information to intelligently change their behavior or their environment –all without human intervention ”

The central advantage of this still admittedly vague de finition is that it makes it clear what the function of IIoT devices is: to monitor, collect, exchange, and analyze information so as to enable them to change their own behavior, or else instruct other devices to do so, without human intervention.

A number of researchers writing in German, o ffer a cluster of definitions of IIoT that share a focus on the kinds of technologies which are put into operation in IIoT settings and the ways they are put to use in those settings. It is suggested that a central element of IIoT is its reliance, in an industrial setting, on objects, systems and machinery which has been upgraded to the status of a CPS, so that products and services can be guided through the supply and value chains in an autonomous manner. Another perspective is that IIoT relies not just on CPS, but also on embedded systems, cloud computing, edge computing, the generic technologies associated with the smart factory, and associated software. A further insight relates to the aims and purposes of IIoT technologies, suggesting that they should not merely function to enable autonomous production, but enable real-time information to users, consumers and other processes. The defi nation of Industrie 4.0 in Section 2.1sheds light on the kinds of technological processes utilized as part of IIoT, and how those processes are applied in promoting the values of the relevant industries whilst also making it explicit how IIoT technologies are connected to other features of the industrial-technological landscape, such as Smart Factories and the Internet of Services (i.e. a “thing ”as a service, e.g. Power as a Service or Mobility as a Service).

We are now able to provide our own working defi nation of IIoT. It has the same structure as the simple conception we started out with: IIoT is defi ned by appeal to the kinds of technologies which compose it, as well as by appeal to the distinctive uses to which those technologies are put, but builds in more details that the simple conception:

Industrial Internet of Things: A system comprising networked smart objects, cyber-physical assets, associated generic information technologies and optional cloud or edge computing platforms, which enable real-time, intelligent, and autonomous access, collection, analysis, communications, and exchange of process, product and/or service information, within the industrial environment, so as to optimise overall production value. This value may include; improving product or service delivery, boosting productivity, reducing labor costs, reducing energy consumption, and reducing the build-to-order cycle.

IIoT: an analysis framework

Before developing our analysis framework, we reviewed existing published material on industry-focused IoT taxonomies and a range of industrial material, in particular manufacturers ’white papers, case studies and technical articles describing specific products or implementations. We identify fied seven published IoT taxonomies in the academic
literature, which address the IoT as a whole and are not specifically focused on IIoT.

Review of existing IoT taxonomies

In undertaking this research our aim was to establish a framework that allows us to analyze the nature of IIoT devices and their uses, which is to be used as part of a vulnerability and threat analysis process for these devices. None of the taxonomies outlined above provide sufficient coverage of the characteristics of devices to support our objectives. The specific limitations of the taxonomies can be summarised as follows:

(a) the device-centric taxonomy [35]–this approach provides useful characteristics at the device level (e.g. energy, communication, functional attributes, local interface, hardware and software resources), but does provide information about the role of the device, its physical or architectural locations, and the sector in which it is being used;

(b) the IoT stack-centric taxonomy  -whilst some of the characteristics (e.g. service, data, interaction and thing) addressed in this approach may be of value the stack does not relate to the conventional IACS hierarchy that is described in the Purdue Model. We considered the concept of service in this taxonomy to be flawed as a particular device may contribute to fulfilment of multiple business objectives;

(c) the IoT sensor taxonomy [38]–the characteristics (e.g. motion, position, environment, mass measurement and biosensor) used by this approach are useful for devices that have a sensing capability, but this is only a subset of the range of IIoT devices;

(d) the IoT-based smart environment taxonomy [39]–this is of limited utility from a security perspective as its emphasis is on classical fication of the networking elements (e.g. communication enablers, network type, technologies, local area wireless standards, objectives and characteristics), the technology elements are very broad and the objectives (e.g. cost reduction) are di fficult to apportion at device rather than system level;

(e) the IoT architecture taxonomy [40]–this combines a mixture of business architecture and technical characteristics (e.g. applications, enabling technologies, business objectives, architectural requirements, IoT platforms architecture types and network topologies), but given the use of only six classic fication elements is of limited value for classifying devices;

(f) the Industrial Internet of Things taxonomy [41]–the approach is immature in terms of the classic fication criteria (e.g. reliability, real-time, data item scale, module scale, runtime integration, distribution focus and collection focus) with only single examples given for each criterion, and the six criteria would not provide us with sufficient granularity to compare and contrast the security pro file of individual devices;

(g) the domain or sector-based IoT taxonomies–this is helpful in addressing the business use to which a device is being put, however, this taxonomy does not address the technical or architectural aspects of device design and deployment as it identifies the type of device but not its characteristics.

Whilst none of the existing taxonomies meet our needs, as they are either too high level or incomplete from a device characterization. perspective, we can draw upon them and our own investigation of current IIoT proposed and actual solutions to develop an analytical framework for IIoT devices. We also considered the theoretical foundations of cyber manufacturing and the work published by the CyPhERS project, for example. However, neither of these publications provide the framework we were seeking as a basis for analyzing devices.

Given the limitations of the published literature, we have developed a framework for characterizing IIoT devices. We have not sought to call it a taxonomy as it does not have a branching structure based on a single root, nor is it an ontology, given inconsistent use of many of the technical terms and the propensity for product marketers to create
new jargon to di fferentiate their products.

Our approach, which is described in more detail below is to characterize devices based on six categories, with each category having a number of sub-categories:

•Industry sector;
•Device location;
•Connectivity;
•Device characteristics;
•Device technology;
•User type.

Each of the remaining sub-sections sets out the rationale for including the category within our framework, providing a diagram that illustrates its breakdown and a rationale for the proposed structure. In setting out our framework we provide examples of each category using a programmable logic controller (PLC) as the device.

Industry sector

The industry sectors illustrated in Fig. 1are relevant to the severity and nature of threats to an organization and the IIoT devices deployed in the organization’s operational systems [45]. All of the sectors make use of IACS to varying degrees, and there is likely to be increased use of IIoT based on industry trends reported by market research companies as referred to in Section 4.1. With the exception of retail, the subcategories listed above are generally recognized as the critical infrastructure of developed economies. Retail has been included to re flect the criticality of supply of essential supplies to citizens and to re flect the increasing technical complexity of many retail outlets, for example, the building automation, management and security systems deployed in their premises. The breakdown of the Manufacturing sector is adapted from the report on digital manufacturing commissioned by the UK government.

Using this category the PLC might be described as:

Location

In Fig. 2, we propose a taxonomy that considers the location of the IIoT device from a number of perspectives, which are relevant in terms of the device ’s exposure to risks from both cyber and physical security perspectives.

Four sub-categories are proposed:

(a) Ecosystem–There are a number of models o ffered for IoT ecosystems [47–50], but these are generic and not specifically related to IIoT implementations. An ecosystem model that does directly related to industrial applications is illustrated in Fig. 3. The proposed class fication scheme is adapted from this model but extended to include the wider enterprise IT to accommodate the convergence of information and operation technologies, and adjacencies. In the Thing class, we have included a sub-class “Monitor ’ to accommodate devices that provide a wider functionality than measurements, e.g. a CTV camera.

(b) Purdue Model –the Purdue Model for Control Hierarchy is a well-recognized model in the manufacturing industry that segments devices and equipment into hierarchical functions. This model has been used by international standards organizations to specify a zone and conduit model for IACS security and is also used in a variety of security [56]and safety guidance material. The model illustrated in Fig. 4, uses the concept of zones in order to subdivide Enterprise and ICS networks into modules that function in a similar way.

(c) Physical –this element seeks to characterize the environment that the device is installed, which therefore allows the level of physical security vulnerability to be considered. For example, devices that are located externally are likely to be much more susceptible to physical damage, theft or being interfered with, as well as being exposed to the elements and a variety of natural hazards.

(d) Mobility –this element provides an indication of whether the device is only used in a fixed location or may be moved around, on its own or as part of a system. Mobile devices are likely to require a wireless communications mechanism to convey data and permit con figuration and/or control, thus exposing the device to the threat of interference or jamming. In addition, there may be a need to track or geolocate the device so as to correctly interpret the data it provides.


Using this category the PLC might be described as:


Connectivity

The proposed connectivity characteristics are illustrated in Fig. 5, the aim of using these is to identify the essential features of the networking or communications connectivity between the device and the IIoT system within which it operates.

The five proposed sub-categories are explained as follows:

(a) Mechanism –the focus of this sub-category is on the physical mechanism used to convey any communications to or from the device. Two classes that may appear unusual are no connectivity and physical connectivity. The former relates to devices that may be recording changes to the environment, where measurement data is stored in the device for later recovery on its retrieval and decommissioning, for example, an IoT-based dosimeter. The latter relates to devices in hazardous or extreme environments, for example, an IoT device employing ultrasonic communications rather than RF
signals in an in a flammable or explosive environment.

(b) Nature –whether the communications are in real-time or near real-time, implying continuous connectivity is required, or whether data can be stored and forwarded either on a schedule or on request.

(c) Initiation –this relates to how communication is initiated;

(d) Protocols –this relates to the protocols used to establish and manage the link and to convey information, examples of the three classes are Infrastructure (IPv4, IPv6, 6LoWPAN, UDP); Discovery (mDNS, HyperCat, UPnP); and Data protocols (MQTT, XMPP, LLAP,
REST, SOAP).

(e) Link security –this focuses on the level of security and trust involved in establishing and operating the connectivity.
Using this category, the PLC may be described as:

Device characteristics

The focus of the proposed device characteristics illustrated in Fig. 6, is on the functionality of the device, specifically how important it is to the system it is part of, the function the device provides, and how it is managed.

The proposed sub-categories are justified as follows:

impact on the overall operational process and how easy it is to repair or replace a faulty or malfunctioning device. The greater the impact and the more difficult it is to replace or repair, the greater the security risks arising from any attempts to attack or interfere with the device. Safety-critical devices clearly need to be engineered and designed to higher standards than those where the is little impact and they are easy to replace.

(b) Function –this class is used to describe the principal function(s) of the device. When considering a device with analytic functions, the nature of the algorithm(s) used is relevant.

(c) Relationships –this class is intended to allow understanding of how the device relates to other devices and the processes, systems or environment within which it operates. For example, a temperature sensor in a room may be linked to an aggregating or control device, as its role is to measure the temperature in the space that it is installed in, it is part of an environmental conditioning process and it will be a ffected if a door or window is opened or left open in the
space within which it is located.

(d) Management interface –relates to how the device is con figured, turned on/o ffor otherwise controlled.
Using this category, the PLC may be described as:

Technology

The proposed technology characteristics of the IIoT device are illustrated in Fig. 7. These focus on technical features that may constrain or in fluence device design or the ability to address vulnerabilities once the device has been deployed.

The power source, energy use and hardware characteristics are relevant as they can constrain the processing capacity of the device, which in turn a ffects the design of security mechanisms used to protect the connectivity and may limit the ability to patch or update the device once deployed. The operating system, software type, and updatability are relevant given the launch of IoT botnets, for example, the Mirai botnet, as they represent a potential vulnerability and if not updateable may limit the ability to respond to botnet malware. The identity of the device manufacturer and a unique identifier are

important for configuration management purposes.

Given the nature of IIoT devices and their extensive use of software, the concept of trustworthiness is an important technical characteristic. This sub-category references the publicly accessible specification (PAS 754), which provides a framework designed to cover all aspects of the system and software lifecycle, as defi ned by ISO/IEC 15288. Of particular relevance is the trustworthiness level matrix, which considers the degree of trustworthiness required from a component, composed sub-system or system is dependent on software and the potential impact. Thus, for a component where the software provides the sole source of trustworthiness if the impact is deemed significant or critical a high level of trustworthiness should be required and demonstrated.

Using this category, by way of example, an Arduino-based PLC can be described as:

User

The proposed user characteristics, as illustrated in Fig. 8, are intended to allow identification of who or what the device is interacting with. The proposed user types are either a human or machine, for example where the device is sensing and providing machine-to-machine communication for system control or monitoring purposes. With regards to the user interface, a device may be:

(a) headless, i.e. there is no indication of device status, measurements or operation;

(b) direct, either passive (e.g. a room thermostat displaying temperature but not allowing user control) or active (e.g. a device with an interactive touch-sensitive display that allows interrogation of the device status and may permit some control of it);

(c) indirect, i.e. the device can be interrogated via another device in the IIoT system.

Using this category, the PLC may be described as:


Discussion, gaps and recommendations for future research

The approach used to develop our analysis framework is consistent with that used by MITRE in the development of their MAEC method used for malware attribute enumeration and characterization. As with the development of MAEC, it is inappropriate to employ a taxonomy based on a single top-down tree structure as specific instances or applications of an IIoT device may result in its classification under multiple branches of the tree. The value of our proposed multi-dimensional approach is that it allows classification of an IIoT device based on pre-de fines attributes that can be used in systematic studies. Depending on the nature of a study, the researcher can decide which categories and classes to employ, thus allowing the focus to be narrowed or broadened to suit the specific research question. For example, if the focus of a study was on software vulnerabilities, the researcher could choose to ignore the industry sector and user type, and focus on the following categories:

device location and connectivity –to allow assessment of the degree of exposure of the device to potential attacks;
device characteristics and technology –enabling assessment of the nature and criticality of the software, ease of software updates and systematic risks associated with the processing platform and operating system in use.


systematic collection of information about IIoT devices. It was developed as part of a research initiative investigating IIoT security issues. The data collection and analysis is ongoing, however, the development of this framework potentially allows comparison of threats and vulnerabilities between di fferent sectors ad application in much the same way as the MAEC approach discussed above.

Having presented our analysis framework, during our research several observations were made which the authors believe to constitute gaps that could be addressed by further research. This recommendation are not presented in any order of importance; we note that each is critical to ensuring future understanding, resiliency and security within IIoT ecosystem, and therefore make no judgment as to their relative importance.

Mapping the IIoT ecosystem and threat landscape

There are a number of publications available that explore and analyse issues of security and privacy relating to IoT in general, there is little work specifically focusing on the IIoT ecosystem. We propose using our taxonomy, to explore and better understand the IIoT ecosystem and associated threat landscape, so as to identify vulnerabilities and potential security and/or privacy concerns.

Limited research on OT and ICT convergence

Whilst there is some work, primarily analyst or vendor, driven, which directly states or implies that IIoT is the result of convergence between Operational Technology (OT) and traditional information and communication technologies (ICT). For example, it is suggested that:

‘… merging IT and OT isn’t an easy task. Merging these two areas requires well-defined, scalable standards that span from assets to data centers and vice-versa. It’s also crucial that these standards are secure, otherwise critical and expensive operational assets can be vulnerable. All these concerns can be tackled by following the concept of ‘Enterprise Architecture’.’
The above approach is indicative of a lack of understanding of the differences between conventional enterprise ICT systems and the cyber-physical systems that are found in industrial applications. In contrast, a better-informed assessment [68] of the security challenges faced in securing IoT devices recognized some of the constraints:

“These current security mechanisms, based on ‘traditional public-key infrastructures will almost certainly not scale to accommodate the IoT’s amalgam of contexts and devices”.

In this assessment, the authors were taking into account the limitations of IIoT devices, for example, sensors, actuators and RFID tags, where there are processing, power and economic constraints limiting the use of strong encryption.

In addition to these technical issues, there is also the mismatch between the relatively short lifespan of many ICT devices and the relative longevity of IACS devices, which are often expected to have a lifespan an order of magnitude longer than their ICT counterparts. We propose to use our analysis framework as a basis for exploring the IT/OT convergence issues.

Providing solutions to brownfield issues

Legacy systems, i.e. a brownfield site, inject complexity into a wide range of cases. A compelling argument has been made  regarding the need for developers to considering the issue of brownfield IIoT:

…how important in industrial IoT (IIoT), such as smart buildings, bridges, roads, railways and all infrastructure that has been around for decades and will continue to be around for decades more.

Further research is required to consider the implications of installing IIoT devices in an operational architecture, where security has been implemented using the zones and conduits inherent in the Purdue Model. As with the topics of security and scalability of IIoT, circular conversations are occurring, solutions have required that address both greenfield and brownfield installations, and again the relative longevity of IACS device needs to be taken into account.

Limited research on the safety and security of IIoT devices Safety and security should be paramount in industrial systems to
prevent harm and minimize the threat to personnel, assets and the environment. There is increasing industry recognition that safety and security are related, for example, that connectivity brings both opportunity and risk and that poor security threatens safety. This is also recognized in international functional safety standards. With traditional IACS systems, the application of the security principles is based on international standards, which advocate the use of security
models aimed at delivering defense in depth, particularly with reference to connections between different layers in the Purdue Model and segregation of processes.

The adoption of IIoT undermines these established practices by creating new connectivity from systems to enterprise or cloud-based systems, thus increasing the potential for safety and security related breaches. There is a current lack of consistent approaches to the combined assessment of safety and security risks inherent in the deployment of IIoT solutions. A combined framework has been proposed [74], but further work is required to codify its use and test its applicability in industrial plants.

Conclusion

In conclusion, having laid out the background including an overview of related terms in section two, we provided a survey of existing definitions of IIoT in section three and developed our own definition which we hope improves on those. In section four we then provided an analysis framework for IIoT devices which provides a practical classification schema for those with an interest in security-related issues surrounding IIoT. The use of the schema has been illustrated by examples at the end of each of the sections describing the six categories. Finally, in section five, some gaps in the IIoT related literature were identified, which we propose should be addressed as part of our continuing research.