With the recent spate of cybersecurity events and associated calls to action among politicians, security of the operations technology (OT) realm is certainly in the spotlight. Though preliminary reports on recent events indicate the fault lay primarily in human error and housekeeping, increased requirements in OT cybersecurity are a certainty for us all.
Multi-factor authentication (MFA) is relatively seldom used in an OT context, but will likely see greater use. It provides an added degree of security that we’ve all become familiar with in our personal lives. The four types of factors used to establish identity are: what the user knows, what the user has, who the user is, and where (or when) the user is. These MFA identification options can take the form of two-factor identification (2FA), which uses two factors; multi-factor identification (MFA), which uses two or more factors; and four-factor identification (4FA), which uses all four factors.
Increasingly, users are not just individuals in the OT and IIoT environment, but devices and services, for which some of the factor identifications options are not feasible. MFA contrasts with the expected ease-of-use, but fortunately supports “single sign-on” once identity is authenticated. Let’s look at examples for each of the four types of authentications and how they might be used in an OT environment.
Three common types of identifiers in the “what user knows” category are personal identification numbers (PINs), passwords and answers to personal security questions. PINs/passwords are the most used form of this factor type and can be used in the field or on the edge, whether by a device or someone logging in remotely. Guidelines on minimum password strength, aging, etc., can increase confidence in this form of authentication.
Examples of an identifier that a user has or can possess include a code sent via SMS text message; soft tokens, like one-time password tokens (OTPs) sent via email; hard tokens, like Bluetooth tokens, smart cards and USB tokens; and dedicated apps like Google Authenticator.
One implementation of hard tokens that's becoming more common is a Trusted Platform Module (TPM) as an implementation on the platform itself.
“Who the user is” factors include fingerprints, facial recognition, retinal scanning, plus voice and signature recognition. These options aren't so useful for devices, but they can be used in the field by technicians.
Lastly, adaptive authentication options are all useful in the OT environment. These include:
- Location: Is the access originating from a known location? Is a user switching from a private to a public network?
- Time: Is the time and data pattern for the access during expected hours of work?
- Device: Is the access from a known device?
Next, let’s look at how adaptive authentication might be used and integrated into an OT environment:
- Location: A handheld device’s Bluetooth capability and its associated authentication can confirm location of an individual relative to equipment. (Bluetooth has a limited radius and therefore the two devices need to be within that radius).
- Time: Workers are expected to be connected during their normal working hours, while devices with regular update cycles tend to have consistent patterns of communications. Changes from these are a flag.
- Device: Is the device connecting/routing via a different address? A network discovery tool and inventory can confirm the MAC address matches the device.
IIoT and the increased processing capability of edge devices using IT communications protocols is increasing the potential attack surface for security events. Though not all MFA techniques are suitable for the OT space and machine-to-machine identification, they're certainly a good step, especially to help secure those back doors used by our weakest link—humans.
About the author: Ian Verhappen
