MENU

Secure software foundations for Industry 4.0

Secure software foundations for Industry 4.0

Technology News |
By Julien Happich



In particular, the Industrial Internet Consortium (IIC) and the Working Group for Industrie 4.0 have generated guidelines and recommendations in the form of the Industrial Internet Reference Architecture (IIRA) and the Reference Architectural Model for Industrie 4.0 (RAMI 4.0) respectively. It is naturally true that given the similarity of the remits for each of these documents, there are similarities and overlaps between the two frameworks, as is reflected in the live and current discussions on co-operation between the two organisations.

Both communities acknowledge that strong security is an essential requirement for the Industrial IoT. Indeed, the IIC has recently introduced the Industrial Internet Security Framework (IISF) to provide guidance in this regard, and as the two communities work together to achieve alignment in a number of areas, security has been identified as a key issue.

The security challenge can be illustrated by reference to an imaginary production plant, with many demands on its systems infrastructure. Sensors provide operations owners the ability to collate data such as location, position, speed, temperature, pressure, lock status and vibration about all their assets in near real-time. At a higher security level still, process plant settings or even firmware can be updated remotely perhaps in response to this data, or to changing production demands. And production figures and profitability provide security headaches of a different, commercial kind; sensitive information divorced from the sensors’ engineering data.

Figure 1 shows how RAMI 4.0 abstracts such considerations into a three dimensional matrix, consisting of Layers, a Life Cycle and Value Stream, and Hierarchy Levels.

Fig. 1: Reference architecture model for Industrie 4.0 (RAMI 4.0).

This is a strikingly similar representation to the “Functional Domains” and “Viewpoints” preferred by the IIC IIRA model (Figure 2).

Fig. 2: Representation of IIC Functional Domains and Viewpoints.

To understand how best to provide a secure foundation for either of the schemes, it is useful to reflect that both of these abstractions represent the coming together of the two, traditionally distinct worlds of Information Technology (IT) and Operation Technology (OT). Traditional OT includes built-in security by virtue of its isolation, whereas IT security is focused on protecting enterprise assets. Connecting them together exposes the security of both systems, simply because in each case it implies the provision of a potential means of access they weren’t designed for. 

It is therefore clear that whatever the differences and similarities between the architectures, the isolation of one domain from another is a key characteristic of any compliant implementation. In particular, the compartmentalization of data is essential such that it is accessible only to those who are privy to it.

Secure middleware solutions designed to control and restrict access to information clearly have a potential role to play in any such system. But they represent only one component in a sophisticated software hierarchy, and any protection they provide is immediately undermined if they are implemented on an insecure infrastructure. 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 security when applied to the OT domain. In other words, the implementation layer for any viable solution requires a secure and non-bypassable foundation to underpin the separation provided by the middleware.

Perhaps the key point here is that data is the enabler to making the IIoT work successfully and securely. By implication, that means that the value inherent in the system is created at the endpoints – whether that is an accountant’s database, or a sensor’s temperature reading.

In order for both of those disparate data sources to be uncompromised, then, the foundation of the IIoT needs to provide the OT with its established levels of safety, resilience, and reliability, but must raise the levels of assured privacy and security to protect the IT side of the marriage. Conversely, the IT spouse will need to ensure improved levels of resilience and safety to accompany its exemplary record in terms of privacy, security and reliability.


All of that might be achievable if all of these interconnected systems were to be designed from scratch with this connectivity in mind. Clearly that is not a practical proposition!  A better proposition would be to protect the endpoints themselves by means of a separation kernel based gateway.

 

Separation kernel

Although such an approach is based on principles which are perhaps new to the industrial sector, they are long established elsewhere. Separation kernels have been protecting classified information in government communications systems for almost a decade, and it is well worth reflecting on the applied academic principles that have made them such a success.

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”. The merits of that argument are so convincing that the principle of a separation kernel forms the foundation of the Multiple Independent Levels of Security (MILS) initiative.

Similarly, as long as 30 years ago, 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 separation kernels and least privilege are therefore both centered on the merits of modularization, with the former focused on resources and the latter on system functionality – a point not lost on Levin, Irvine and Nguyen in their paper “Least Privilege in Separation Kernels” where they proposed an amalgam of the two concepts.

Fig. 3:  The superimposition of Least Privilege principles on Separation Kernel blocks results in fine per-subject and per-resource flow-control granularity.

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.

Fig. 4: Simplifying the practical application of the Separation Kernel.

Hardware virtualization

Although the principles of a separation kernel and least privilege are long established, early attempts at implementation relied on a software virtualization layer which resulted in questionable performance in general, and made real time applications unsupportable. It was the overwhelming popularity of virtualization in the enterprise domain which led to silicon designers (including Intel, AMD, and ARM) to scale up the number of cores per CPU and implement advanced support for virtualization in hardware. At that point, a separation kernel moved from merely being a neat theoretical idea, to being a genuinely practical proposition.

There are several embedded hypervisor products which look to achieve similar ends based upon a modified OS architecture. However, for the security credentials of a separation kernel to be optimal, it must deploy least privilege principles to minimize the trusted computing base (TCB) and hence the attack surface, to optimize the protection provided by the gateway.

Separation kernel practicalities

To put that 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. Maybe it is vulnerable to attack from would-be 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.

Fast

To achieve near native performance, the separation kernel will need to introduce as little overhead as possible and leverage the virtualization capabilities of the hardware to the greatest extent possible.

Small

By ensuring the operating system features like drivers, I/O and process management are handled by the subjects, the separation kernel will be very lightweight and less vulnerable to attack.

Practical

The separation kernel will support the reuse of legacy software by presenting a “virtual motherboard” to subjects, such that those subjects can be installed and run just as for a native installation.

Secure

Static configuration will ensure that the separation kernel is immutable once built and deployed, and with an optimally small attack surface.

 

The IoT endpoint

It is easy to see how the principles established in the simplistic lathe example (Figure 4) can be applied to protect the IoT endpoint. Figure 5 illustrates how the interface between any number of data sources and the IT world is protected by means of IoT Gateways, each based on a separation kernel.

Fig. 5: Protecting the IoT endpoint by means of a separation kernel.

In such a scenario, the principle of the plant-facing “trusted subject” is extended to support such services as platform configuration management, monitoring and analysis, and bare-metal security services (such as cryptography) to support data-at-rest (DAR) and data-in-motion (DIM). Secure boot technology ensures that the gateway is no more vulnerable at start-up that at run-time. 


Conclusion

The Industrial Internet Consortium (IIC) and the Working Group for Industrie 4.0 have generated guidelines and recommendations in the form of the Industrial Internet Reference Architecture (IIRA) and the Reference Architectural Model for Industrie 4.0 (RAMI 4.0) respectively. It is naturally true that given the similarity of the remits for each of these documents, there will be overlap between them.

Fig. 6: IISF threats and vulnerabilities to IoT endpoints.

Both communities acknowledge that strong security is an essential requirement for the Industrial IoT. Indeed, the IIC has recently introduced the Industrial Internet Security Framework (IISF) to provide guidance in this regard, and as the two communities work together to achieve alignment in a number of areas, security has been identified as a key issue.

Secure middleware solutions designed to control and restrict access to information clearly have a potential role to play in any such system. But they represent only one component in a sophisticated software hierarchy, and any protection they provide is immediately undermined if they are implemented on an insecure infrastructure.

Data is the enabler to making the IIoT work successfully and securely. By implication, that means that the value inherent in the system is created at the endpoints, and so it is logical to ensure that they are as secure as possible.

An IoT gateway based on the proven technology of a separation kernel provides the ideal foundation for a compliant solution based on either IIRA or RAMI 4.0 due to its security credentials, efficiency in use, and more pragmatically, its ability to support legacy software.

 

About the author:

Mark Pitchford is Technical Manager EMEA at Lynx Software Technologies – www.lynx.com

 

If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :    eeNews on Google News

Share:

Linked Articles
10s