search.noResults

search.searching

saml.title
dataCollection.invalidEmail
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
SPOTLIGHT Cybersecurity


Figure 1: The attacker uses the CnC to instruct infected devices to inundate the IP address of a target system with requests to communicate, thus denying legitimate users


number generator and a SHA-256 hash algorithm for data encryption. They also include APIs for storing, retrieving and manipulating X.509 certifi cates for Transport Layer Security (TLS) integration. In our example of a server communicating with multiple IIoT-enabled devices, the end-to-end communications link can be made far more secure by virtue of unique IDs in the fi eld and encrypted transferred data.


IIoT in Automation


RESTful. Such APIs are popular because they do not require much bandwidth, can be crafted in Python or JavaScript, and they use HTTP to communicate with the cloud. This means data can be created, updated, read or deleted. The use of any REST-based API presents certain cyber challenges. These can be addressed through better authentication for access control, blocking certain payloads (size and/or type that aren’t expected) and access from unknown IP addresses and domains. If the IIoT- based device is just one of few that is part of a well-conceived IT and operating technology (OT) system, none of these solutions should prove too diffi cult to implement.


Secure by design Traditionally, security considerations have always come late during product development, sometimes as late as prototyping. This must change; security


should be considered when specifying a device’s requirements. Its intended length of service in the fi eld and importance of what it does and the data it handles will govern the measures to take. Let’s assume high security is required and consider, for a moment, end-to-end communications. An important element is the device’s identity. How trustworthy is it? Is static data encrypted on the device? Should/can data in transit be encrypted to thwart ‘man-in-the-middle’ interceptions? Thankfully, the OEMs of


microcontrollers are producing some great ICs that are very much geared for high- security IoT operation. Take Microchip Technology’s CryptoAuthentication family of devices, for example. These devices can work alongside the microcontroller or microprocessor within an IoT-enabled systems. IC features include a unique and non-changeable 72-bit serial number (set by Microchip), a 512-bit one-time programmable (OTP) zone, a random


The IIoT is very much part of Industry 4.0 and M2M communication. It has brought great benefi ts. However, IIoT is challenging the Purdue Model, shown in Figure 2, which refl ects the hierarchy of IT and OT systems elements, and comprises six layers:


Figure 2: Since the 1990s, the Purdue Model has been a standard for enterprise and industrial control system networks


• Level 5 = corporate network systems. • Level 4 = IT systems for business logistics (includes databases and servers). • Level 3 = systems for site-wide monitoring and control. • Level 2 = control systems such as HMIs and SCADA software. • Level 1 = basic control devices such a programmable logic controllers. • Level 0 = sensors, actuators, motors and pumps, and so on. The purpose of the Purdue architecture is to assure safe control, noting that safety and security go hand in hand. Within the enterprise zone it has historically been only the enterprise network that has had access to the Internet and the outside world. Malware hitting IT equipment at levels 5 or 4 should not be able to aff ect anything at level 3 or lower because of the fi rewalled demilitarised zone. Today, many OT devices in the manufacturing zone are now IoT enabled. Smart sensors and controllers, along with edge-processing systems, are connected to the Internet. Data no longer fl ows between the Purdue Model levels. There are mixed views in the industry whether the Purdue Model needs to be replaced or enhanced in light of the increased use of IIoT within the manufacturing zone. As stressed earlier, a risk analysis must be performed on any IIoT device relative to its level in the Purdue Model and whether it is playing a role in monitoring, controlling or both.


CONTACT:


Nexus Industrial Memory www.nexusindustrialmemory.com


automationmagazine.co.uk


Automation | November 2021


9


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