Engineering organisations across almost every industrial sector are not short of guidance when it comes to designing, developing and deploying an industrial internet that is interoperable, safe and secure. In particular, the Industrial Internet Consortium (IIC) and the Working Group for Industry 4.0 have generated guidelines and recommendations in the form of the Industrial Internet Reference Architecture (IIRA) and the Reference Architectural Model for Industry 4.0 (RAMI 4.0) respectively.
Figure 1 illustrates the RAMI 4.0 model, expressed as a three-dimensional matrix consisting of Layers, a Life Cycle and Value Stream, and Hierarchy Levels. This is a strikingly similar representation to the “Functional Domains” and “Viewpoints” preferred by the IIC IIRA model (Figure 2). In recognizing the key role of security in the industrial internet architecture, the IIC has released the Industrial Internet Security Framework (IISF). Acknowledging that strong security is an essential requirement for the Industrial IoT, both IIC and Industry 4.0 are collaborating to achieve alignment on several aspects of IoT, and security has been identified as a key issue to address in these IIoT designs.
The IISF provides extensive guidance on security considerations in industrial IoT including identifying areas of vulnerability & implementation guidance on technology usage to minimize security threats. To provide a secure foundation for either architecture, it is useful to reflect that both abstractions represent the amalgamation of the two, traditionally distinct, worlds of Information Technology (IT) and Operational Technology (OT). Traditional OT includes built-in security by virtue of its isolation, whereas IT security is focused on protecting enterprise assets. The promise of the IoT can only be realized when these disparate systems are connected to each other, which exposes the OT side to new security threats that they were not designed to mitigate. It could be argued that the complex and monolithic software stacks prevalent in the IT domain, with their inherently large attack surfaces, do not offer the requisite level of protection when applied to the OT domain. The most appropriate paradigm to apply in such an IT-OT scenario should provide isolation between domains, while maintaining controlled flow of information between these two domains. A secure software foundation for Industry 4.0 needs to provide the OT with its established levels of safety, resilience, and reliability, but raise the levels of assured privacy and security to protect the IT side of the nexus. Conversely, the IT domain will need to ensure improved levels of resilience and safety to accompany its exemplary record in terms of privacy, security and reliability. Ideally these interconnected IT-OT systems would be designed from scratch with connectivity in mind; clearly not a practical proposition unless those designs are greenfield implementations. However, for most brownfield designs, a better proposition would be to protect the systems using strong isolation techniques as outlined in the IISF. One of the recommended techniques in the IISF is the usage of a separation kernel to provide this level of isolation between different domains and still provide controlled flow of information. A compliant deployment to achieve this isolation requires a secure and non-bypassable foundation if higher layers are to operate with the necessary reliability and security.
Although the separation kernel is based on principles which are perhaps new to the industrial sector, they are have been used successfully in environments that protect sensitive data. Indeed, separation kernels have been protecting classified information in government communications systems for almost a decade. The concept of a separation kernel was first mooted by John Rushby in 1981, who suggested that it should consist of “combination of hardware and software that permits multiple functions to be realized on a common set of physical resources without unwanted mutual interference”. Similarly, Saltzer and Schroeder suggested that “Every program and every user of the system should operate using the least set of privileges necessary to complete the job”. This simple and common sense “least privilege” approach becomes imperative where applications of differing criticality are run in close proximity to each other. The concepts of the separation kernel and least privilege are both centered on the merits of modularization, with the former focused on resources and the latter on system functionality. Figure 4 illustrates least privilege “Subjects” (active, executable entities) and “Resources” superimposed on separation kernel “blocks”, showing the support for per-subject and per-resource flow-control granularity. The consequence of these key concepts allows the realization of isolation & controlled flow of information between multiple domains of different criticality, that can be directly applied to the IT-OT isolation requirement to achieve IIoT designs that offer superior levels of security, safety and reliability.
To put this theory into a practical context, consider a lathe which is required to generate production data (Figure 5). In turn, that data is to be shared via the cloud, perhaps with an on-call plant engineer.
The cloud facing subject in this example might be a general purpose operating system, such as Windows or Linux. This environment is vulnerable to attack from malicious hackers. But it is important that the hackers cannot gain access to plant facing subject – perhaps an RTOS or bare-metal application – even if the cloud facing subject is compromised. A separation kernel implemented in accordance with the principles of least privilege will have several key attributes to make it optimal for such a scenario:
Static configuration will ensure that the separation kernel is immutable once built and deployed, and with an optimally small attack surface. The isolation that is provided between the IT and OT environments keeps the two domains separate and secure.
To achieve near native performance, the separation kernel can introduce minimal overhead and leverage the virtualization capabilities of the hardware to the greatest extent possible.
By design the separation kernel is very lightweight and less vulnerable to attack. Since the separation kernel is built small by design traditional operating system features like drivers, I/O and process management are not present and thus provide an extremely small footprint for the platform.
The separation kernel supports the reuse of legacy software such that those subjects can be installed and run just as for a native installation. This exemplary IIoT use case utilizing the separation kernel reflects the key design principles outlined in the IISF and can serve as a blueprint for IIoT system design that provides a high degree of security, safety and reliability.
If the promises of Industry 4.0 are to be realized, the worlds of Operational Technology (OT) and Information Technology (IT) must be combined such that the reliability and security of the OT domain is never compromised. The Industrial Internet Security Framework (IISF) provides guidance in terms of how this might be achieved. In an industrial IoT endpoint, where the OT and IT domains coalesce, the proven technology of a separation kernel can provide the secure and non-bypassable foundation which is required to guarantee the security and reliability demanded by IIoT systems as envisioned by Industry 4.0, and the IIC.