How to protect vital controller data from cyber attack

Industrial control systems, such as PLCs and the like, have become the mainstay of many industries. We are often unaware of how fundamentally intertwined they are in our daily lives.

In process industries, industrial controllers play at least some role in the production of virtually every building material we use. They also run dairies and public utilities like water treatment plants and much more. In manufacturing, industrial controllers are responsible for much of the processing and packaging of many of the consumable items on our supermarket shelves.

The world is highly reliant on industrial controllers, but it is precisely because of their ubiquitous usage across so many industries that they can become targets for hackers and those who seek to disrupt society. Furthermore, the advent of Industry 4.0 and IIoT has meant internet connectivity is now commonplace. But this same connectivity also presents opportunities for penetration into ‘critical infrastructure’, such as food manufacturing. Questions are therefore rightfully being asked about how secure the data within industrial controllers really is.

Cybersecurity

Consider what would happen if a cyber intrusion infiltrated the operation of a plant’s controllers. It would cause mass disruption and huge losses. As such upheaval is unacceptable to society, it’s vitally important that industrial controllers be protected from would‑be hackers and other forms of intrusion.

Protecting IP

The need for data protection and access control is also vital for engineering firms and OEMs who have spent considerable resources and many man‑hours developing programs. The intellectual property is highly valuable to them and must be safeguarded to prevent unauthorised copying.

Security and industrial controllers

Controllers only started supporting serial communication links in the late 1980s. There was no thought of being connected to a LAN or the internet, so there was no consideration given for security either. Once online, users were able to access every aspect of the controller’s memory, without any authorisation verification.

Passwords were soon introduced to restrict program access. However, communication links were not secured (ie, data was not encrypted), meaning passwords could be read directly by a snooping program like a protocol analyser. This meant program protection was ineffective when used over modems.

How industrial controllers now support data security

Modern controllers have been designed from the ground up for a cyber‑enabled world. By adopting many of the well‑established methods used in computerised systems, they have made themselves very robust and resilient. Let’s now consider the array of security features they have implemented.

Controlling user access

Computerised systems, such as banking, rely on a username and password combination to identify users and thereby prevent unauthorised access. The internet can be used for remote connectivity, so username and password information must be sent securely (ie, encrypted). This means packet analysing software cannot directly read these details. Furthermore, controllers can also hold certificates for user identification for secure protocols like OPC UA, which uses X.509.

Controllers can similarly accept encrypted data and store a predefined list of eligible users with their passwords and access level. Users will need to enter their details each time they log in and users not on the controller’s list are prevented from going online altogether.

To prevent users from performing tasks they’re not qualified to do, each user is allocated one of five authority levels (see Table 1). The level of authority determines the privileges available to users at that level. The levels are hierarchical, so the administrator (who is at the top level) has access to every aspect of the controller.

Level of authorisation	Examples of permissible operations
Observer	Can read some data, like controller status and error logs, but not I/O
Operator	Can write to some data areas, but not force I/O or make program changes
Maintainer	Can change operational modes and make minor program changes, like online edits
Designer	Can reset the controller, but not clear the entire program
Administrator	All functions, including adding new users and changing authority levels

Table 1: Hierarchical users authority levels.

The use of passwords

Passwords are highly effective at restricting access, provided some simple rules are followed. Firstly, passwords must not be displayed on a screen; a series of asterisks can instead indicate the number of characters entered. Secondly, the password must have sufficient length and should ideally contain both numerals and letters (both upper and lower case). If we consider an 8-digit password where each digit has 10 + 26 + 26 possibilities, then the number of permutations is 62⁸, which exceeds 218 x 1012! The permutations are reduced somewhat by eliminating easily guessed combinations but will increase exponentially by accepting punctuation characters and allowing passwords of varying lengths. The fact remains that the chance of guessing a properly selected password is negligible.

Security breaches due to compromised passwords

Despite the enormity of the permutations available, security breaches can still occur. One common cause is the use of predictable passwords, such as ‘1234’, ‘password’, ‘qwerty’, ‘abc123’ and the like. Also, many users suffer from ‘password fatigue’, meaning they use the same password for multiple systems. This means once a password is compromised, hackers will have access to all these systems.

Hackers can also use methods to circumvent security. One example is a master password, which can unlock all protection. Once it becomes known for a particular product or model, the information can spread quickly and render the feature ineffective. But perhaps the best-known method is a brute force attack. This is where hackers create a program to generate every possible character combination to enter as a password. Despite the vast number of permutations, if these programs are given adequate time, they will eventually find the password.

Brute force attacks can be thwarted by the controller by allowing only a limited number of password attempts. Delays can then be imposed before the next password is accepted. Users can also be locked out if the number of password attempts exceeds a certain limit. Furthermore, an automatic log‑out can be enabled for users who have successfully logged in but have been inactive for a certain time. This is to prevent unauthorised personnel from accessing the controller, while logged in with someone else’s password.

Copy prevention

Those that seek to copy controller programs illegally can be prevented from accessing the controller. However, programs can still be copied by other methods, like the memory cards built into controller CPUs.

These operations can be foiled by utilising a unique ID built into each controller. This ID can be used during compilation so that a program will only run on that specific controller. So even if a program is transferred via memory card, it cannot run on any other CPU. CPUs can also be made to only run programs compiled to their ID, meaning no other program can be loaded into that controller.

Protection needed in the programming software

The IDE (integrated development environment) used to develop programs for controllers also needs to protect sensitive components, such as function blocks, libraries and CAM tables. Access can be controlled via a password, although password release should only be temporary, in case the programmer forgets to re‑enable the password after access.

Conclusion

Industrial controllers are now an integral part of our society. Keeping their data secure in this highly connected world is therefore of paramount importance. Features built into modern cyber‑enabled controllers can allow them to be used safely. And machine builders can rest assured their IP is well protected by those features.