Industry has come a long way from the days where the only security was physical security. In a typical control room in 1970, the ability to physically touch buttons and knobs was all that was needed to effect process changes. Fast-forward to the present, and the interfaces available are far more powerful, and they can be configured to limit access to authorized users.
A modern HMI is more than simply an interface for an operator to start equipment. It usually serves as the first point of contact with the control system and the process. As such, HMIs are used for troubleshooting poorly functioning equipment, for investigating process deviations, for recovering from an upset, and for manually operating equipment during downtime periods to verify correct operation following reassembly after maintenance tasks. Beyond this, there are administrator tasks related to the HMI itself, such as adding new users, or loading new patches or anti-virus definitions to the underlying PC.
For most sites, not every one of these functions is the job of the same person. It is typically best practice to identify a number of like functions and tasks and group them into a handful of roles. While requirements may vary, three to five roles are typically sufficient for most sites. All functions must then be identified and assigned to one (or more) roles. While identifying roles and access, keep in mind that many HMI’s can differentiate between read-only and read/write access. If a person can better accomplish their job by seeing information and lacks training on making modifications, they should have read access to it.
Modern systems permit the assignment of roles to individual users. For example, both Albert and Bob can be assigned their own unique username, and unique password. If they are assigned to the same group, they will have access to the same HMI features and functions, though they are logged in with their unique credentials. Additional features that are associated with users include password strength requirements, password expiration, and auto-logout. Password strength requirements can be selected that will require a user to provide a strong password, typically identified as being a certain length and having multiple character types, such as numbers and symbols. Passwords that are configured to expire may add security, as it decreases the likelihood of inappropriate password sharing. Auto-log out is used to remove access from the system until valid credentials are offered. When logged out, some systems are configured to provide read-access without a required login.
Broadly speaking, there are two ways that access control is implemented in most HMIs. The most common way is by securing the navigation functionality. Such a configuration allows users to access screens that are allowed according to their role. It is very common that each level that has more access also has access to all the screens available to those at lower levels of access. For example, maintenance may have access to all the operator screens, and an admin will have access to all the screens. This is not ideal, however, as an administrator skilled at applying patches and adding users may not necessarily have ANY skill or training in actually operating the equipment, and therefore aught not be able to access the operator screens. It would be better practice to have a main menu screen that is accessible to all, and after logging in, navigation to either the maintenance, operator, or admin screens are permitted.
A second method for implementing role-based security is object-by object. For example, it may be that either a member of either the operator role or the maintenance role may select a valve faceplate. The operator may not see every object, the PID tuning parameters, for example. The maintenance person, however may have access to them all. In this way, access can be customized at the object level. This may be a far superior method of implementing access control in those instances where objects can be replicated repeatedly. On existing systems, implementing access control in this manner is typically far more time-consuming than to limit the navigation alone.
A key aspect of maintaining role-based user access is to support it with the correct SOPs and policies. Key aspects include removal of all former employees, and verification that users retain only the correct roles as job functions change. For example, if a maintenance person becomes the site supervisor, it may make sense to remove her from the system, as it is more likely her credentials will be stolen or misused than that she will be using the HMI alone to perform system maintenance. Alternatively, if a maintenance person becomes an operator, removing the maintenance role and adding the operator role may become warranted.
Role based user access is a key part of any effective cybersecurity program. We need to move beyond the days where a stick-it note with the words “user: admin password admin1” could be found stuck to the monitor. Identifying users, assigning them to roles, and removing or reassigning them as necessary is an early step in making sure you are reducing risks posed by untrained personnel inadvertently causing cybersecurity breaches and safety hazards. Please contact ACE if you need assistance in establishing roles, configuring security settings on your HMIs, or networking them together to implement or leverage IT resources such as Active Directory, single sign-on or multifactor authentication.
Learn about assessing your organization’s cyber posture by downloading our white paper, Cybersecurity Success Starts with Understanding Your Organization’s Cyber Posture.
Visit our PLC, DCS, HMI & SCADA page to learn more.