The Cultural Divide Between Security Teams and Control Engineers
Henry Kogan
Every OT security program eventually collides with the same problem. The security team and the control engineers do not trust each other. They do not share a vocabulary. They optimize for different outcomes. They report to different leaders, often on opposite sides of the organization. And most training programs for either group treat the other as a problem to be managed rather than as a partner whose expertise is essential.
This is not a personality issue. It is structural, and the structure has real consequences for how well the plant can be defended.
Different clocks, different values
Security teams, by training and by incentive, optimize for confidentiality, integrity, and availability in roughly that order. They are measured by vulnerabilities closed, patches applied, incidents contained. Their time horizon for decisions is short. A critical patch is urgent because an unpatched vulnerability is an open door, and every day the door is open increases the probability of an incident.
Control engineers optimize for availability, safety, and predictability. They are measured by uptime, yield, product quality, and the absence of safety events. Their time horizon is long. A controller that has run for fifteen years without incident is more valuable than a newer controller with a shorter track record, because its failure modes are known. A patch is not urgent. A patch is a disturbance to a known-good system, and disturbances to known-good systems are exactly what they have spent their careers learning to avoid.
Both sets of priorities are correct. The problem is that the two groups rarely have the conversation that would let them see each other’s priorities as correct. The security team sees the control engineers as obstructionists who refuse to patch. The control engineers see the security team as outsiders who do not understand the process and are willing to risk a production incident for a theoretical reduction in cyber risk. Neither view is accurate. Both views are common.
What TRITON revealed about the divide
The 2017 TRITON intrusion at a Saudi petrochemical plant offers an uncomfortable case study. The attackers, attributed by FireEye to a Russian state research institute, had been inside the corporate network for about a year before reaching the safety instrumented system. During that time, multiple antivirus alerts were triggered by their activity, and those alerts were, according to post-incident analysis, dismissed or not escalated. The Triconex SIS controllers were running with their physical key switch in the PROGRAM position, which is the setting that allowed the attackers’ payload to be uploaded in the first place.
Each of those failures is usually described as a gap in process or awareness. That framing is incomplete. Antivirus alerts get dismissed when the people receiving them have been trained to see alerts as noise, or when the people generating the alerts are not trusted by the people receiving them. Key switches get left in PROGRAM mode when the engineers using the system have a workflow that requires it and no one has ever had a conversation with them about why the position matters for cyber risk. These are not technical failures. They are failures of communication between two groups who were each doing their job as they understood it.
The TRITON attackers did not need sophisticated exploits to reach the SIS. They needed a year of uninterrupted dwell time in an environment where the signals that should have alerted defenders were being generated and ignored. That kind of environment does not come from a lack of tools. It comes from a culture in which the security team and the operations team are not really working together, regardless of what the org chart says.
Training that puts both groups in the same room
Most OT security training is built for one audience or the other. Programs for security professionals teach ICS protocols and reference architectures but rarely put learners in front of operators. Programs for control engineers teach compliance requirements and hygiene practices but rarely give them the vocabulary to push back constructively on security proposals that would hurt the process.
CyberEd.io runs its OT programs differently. Joint tabletop simulations bring security, engineering, and operations staff into the same exercise, working through TRITON-style dwell-time scenarios in which the signals are present but the organization has to recognize and act on them across disciplines. Site-walk and case-study modules give each group the vocabulary of the other, so that when an antivirus alert fires or a key switch needs to move, the conversation has already happened. A security program that has the right tools but has never built that trust will not defend the plant when it matters. The next post looks at one specific category of misunderstanding that survives in OT security curricula long after it should have been retired, which is the idea that air gaps and controlled vendor access provide the protection they used to promise.
To strengthen collaboration between security teams and control engineers before small disconnects become operational risk, connect with our security experts to build an OT training program for your environment.
References: Mandiant/FireEye, Attackers Deploy New ICS Attack Framework ‘TRITON’ (2017); MIT Technology Review, Triton is the world’s most murderous malware, and it’s spreading (2019); Dragos, TRISIS Malware Analysis (2017); U.S. Treasury Department sanctions announcement regarding CNIIHM (October 2020).