User Behavior Analytics Could Find a Home in the OT World of the IIoT

Second of a two-part series. 

In my last piece for Dark Reading, I explored the security uncertainty created by the convergence of information technology (IT) and operational technology (OT) in organizations undergoing Industrial Internet of Things (IIoT) digitalization. Among the manifestations of this uncertainty — and occasional friction between internal IT and OT teams — is a lack of clarity regarding ownership of IIoT security solutions.

As someone who has worked in OT and IT, I suggested that industrial companies adopting IIoT use the hard-won lessons of IT to leapfrog to an advanced state of IIoT security, and proposed separation of endpoint networks and microsegmentation as pure IT approaches that could be ported as-is and work well in the OT world.

There is also a fertile middle ground. User behavior analytics (UBA) focuses on user behavior to detect anomalies that indicate potential threats. It arose first in IT but failed to catch fire primarily because of IT's complexity. I think it could be profitably employed in OT. 

UBA has been around in data-centric IT for at least four years, but it has never become industry-standard primarily because in the real world, user behavior in IT is so varied and complex that UBA often creates more false alarms than useful ones. In IT, UBA has often failed to find the dangerous needle in the immense haystack of user behavior. But user behavior in process-centric OT is much simpler: OT systems run the plant, and scripted user activity is nowhere near as varied as in IT, with its multiple endpoints and inputs, email browsing, multipart software stacks, etc.

UBA can be applied more precisely in OT than in IT thanks to OT's relative simplicity. A potential attacker can stump UBA in IT because of IT's complexity, rendering UBA less than optimal. But it is extremely difficult to fool UBA in OT because of OT's well-defined process orientation. OT's nature would allow security teams to apply UBA more successfully at specific points. One would be the "border crossing" between IT and OT. Any user or machine entering the OT network from IT — a necessary function in IIoT — would be strictly vetted at the border crossing: Where are they going? What have they been doing?

Another potential point for effective UBA application would be the human-machine interface (HMI). Many OT systems are accessed within factories by people sitting down at these HMIs. The moment they start doing anything, UBA begins creating a profile of their actions for future use.

It would not be difficult to build profiles of machines, systems, and their users to determine what is normal and what is abnormal, whether users/operators enter the OT network from IT or by entering the OT environment via HMIs. Once we've defined normal, anything abnormal could be identified as a potential anomaly and investigated as a vulnerability for attack.

Easier Definitions
The beauty of UBA in OT is that "normal" and "abnormal" are relatively easier to define. In IT, users with ostensibly the same roles do a variety of different things — all of them "normal." Thus, true normal is harder to discern. By contrast, in OT users operate by strictly defined processes — and each user with the same role should be doing the same thing — so "normal" exists within narrow boundaries. Even when new users in particular roles begin to use the system, their functions would be the same as the old operators in the same role. Therefore, there is no need to begin creating new profiles — making the UBA function easier — and "abnormal" would be much easier to detect and investigate.

A real-life example of UBA's potential value is the August 2017 Triton/Trisis malware intrusion in an oil and gas plant believed to be in Saudi Arabia, which caused the plant to shut down. Malware shutting down an OT system is the second-worst thing that can happen in OT. The worst is for the malware to target the industrial control system and send the plant spinning wildly out of control, costing not only money but lives. Many experts believe Triton/Trisis is meant to do just that.

Interestingly, it has been reported that the Triton/Trisis intrusion in Saudi Arabia began when two malware files were copied onto an OT system in the Saudi plant that were later executed to begin the attack. Because OT user behavior is so heavily scripted, the haystack is much smaller and the "needle" of two files being copied abnormally onto the system is theoretically easier to find.

It's certainly worth exploring whether in similar situations an OT UBA system could detect the anomaly and trigger a warning when a threat arises. 

Related Content:

Black Hat Europe returns to London Dec. 3-6, 2018, with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions, and service providers in the Business Hall. Click for information on the conference and to register.