Feature: Industrial electronics
Figure 1: Memory buffer overfl ow type attacks
or JavaScript, and use HTTP to communicate with the cloud. T is means data can be created, updated, read or deleted. T e use of any REST-based API presents certain cyber challenges.
T ese can be addressed through better authentication for access control, blocking certain payloads (of unexpected sizes and/or types) or access from unknown IP addresses and domains. If the IIoT-based device is part of a well-conceived OT system, none of these solutions should be too diffi cult to implement.
Starting early Traditionally, security considerations have always come late during product development, sometimes as late as the prototyping phase. T is must change – security must be considered when specifying a device’s requirements. Its intended length of service in the fi eld, the importance of what it does and the data it provides/receives will govern the measures to take. Let’s assume high security is required for, say, 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-middle’ interceptions? T ankfully, microcontroller OEMs are producing some great
ICs geared for high-security IoT life. Microchip Technology’s CryptoAuthentication family of devices, for example, works alongside the microcontroller or microprocessor within IoT-enabled devices. Security features include a unique and non-changeable 72-bit serial number (set by Microchip), a 512-bit one-time programmable (OTP) zone, a random-number generator and an SHA-256 hash algorithm for data encryption. T e ICs also include APIs for storing, retrieving and manipulating X.509 certifi cates for transport layer security (TLS) integration. T us, for a server communicating with multiple IIoT- enabled devices, the end-to-end communications link can be made far more secure through unique IDs and encrypting transferred data.
IIoT in Industry 4.0 In IIoT settings, there’s something called the Purdue model (Figure 2), which refl ects the hierarchy of IT and OT system elements. It comprises six layers: • Level 5 = corporate network systems; • Level 4 = IT systems for business logistics (including databases and servers);
www.electronicsworld.co.uk December 2021/January 2022 33
• Level 3 = systems for site-wide monitoring and control; • Level 2 = control systems such as HMIs and SCADA soſt ware; • Level 1 = basic control devices such as programmable logic controllers;
• Level 0 = sensors, actuators, motors, pumps, etc. T e purpose of the Purdue architecture is to ensure safe control,
where safety and security go hand in hand. Within the enterprise zone, historically it was only the enterprise network that had access to the Internet and, thus, the outside world. Malware hitting IT equipment at levels 5 or 4 should not be able to aff ect anything at level 3 or below because of the fi rewalled zone. Today, many OT devices in the manufacturing zone are 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. T is has led to mixed views in the industry whether this model should be replaced or enhanced in light of the increased use of IIoT within the manufacturing zone. Ultimately, it is important to perform a risk analysis on any IIoT device relative to its level in the Purdue model, and whether it plays a role in monitoring and controlling, or both.
Figure 2: Since the 1990s, the Purdue model has been standard for enterprise and industrial control system networks
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
