search.noResults

search.searching

note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
Embedded


Secure software foundations for Industry 4.0


Arun Subbarao, vice president, Engineering & Technology at Lynx Software Technologies talks about the security challenges with software foundation for Industry 4.0


E


ngineering 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).


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 realised 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


Figure 2: Representation of IIC Functional Domains and Viewpoints


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


Separation kernel principles Although the separation kernel is based on principles which are perhaps new to the industrial sector, they 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.


Figure 1: Reference architecture model for Industry 4.0 (RAMI 4.0)


In recognising 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.


Industrial Internet Security Framework (IISF) The IISF provides extensive guidance on security considerations in industrial IoT including identifying areas of vulnerability and implementation guidance on technology usage to minimise security threats.


24 July/August 2017


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


Components in Electronics


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 realised 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 modularisation, with the former focused on resources and the latter on system functionality.


The consequence of these key concepts allow the realisation of isolation and 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.


Exemplary IIoT use case using a separation kernel 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. It should be secure: 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. I should also be fast: to achieve near native performance, the separation kernel can introduce minimal overhead and leverage the virtualisation capabilities of the hardware to the greatest extent possible. It needs to be small: 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. And finally it should preserve existing software investments: the separation kernel supports the reuse of legacy software such that those subjects can be installed and run just as for a native installation.


Conclusion If the promises of Industry 4.0 are to be realised, 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.


www.lynx.com www.cieonline.co.uk

Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56  |  Page 57  |  Page 58  |  Page 59  |  Page 60  |  Page 61  |  Page 62  |  Page 63  |  Page 64  |  Page 65  |  Page 66  |  Page 67  |  Page 68  |  Page 69  |  Page 70  |  Page 71  |  Page 72  |  Page 73  |  Page 74  |  Page 75  |  Page 76  |  Page 77  |  Page 78  |  Page 79  |  Page 80  |  Page 81  |  Page 82  |  Page 83  |  Page 84  |  Page 85  |  Page 86  |  Page 87  |  Page 88  |  Page 89  |  Page 90  |  Page 91  |  Page 92