The automation engineer knows every detail of the plant. It knows the behavior of each PLC, the history of each alarm, the shortcuts that keep production running when time is short.

Over the years, he has been accumulating access, not out of carelessness, but out of necessity. Today, it programs the logic of the controllers, operates the system on critical shifts and, when an emergency calls for it, disables security alarms to keep the line running.

Each of these actions, in isolation, is legitimate. Together, they form exactly the type of conflict that IEC 62443, the international safety standard for industrial automation and control systems, requires to be segregated. And it is the first point that an audit will look for.

This scenario is no exception.

The fact is that the problem of a significant proportion of industrial plants is not in the competence of the professional, but in the absence of a structure that separates incompatible functions before someone explores this concentration of access.

That's what we're showing now!

What is IEC 62443 and why it requires documented SoD

TO IEC 62443is a series of international standards developed by ISA (International Society of Automation) and adopted by IEC (International Electrotechnical Commission) for IACS security, Industrial Automation and Control Systems, the automation and industrial control systems that govern physical processes in oil and gas, electricity, petrochemical, manufacturing, sanitation and mining plants.

What differentiates IEC 62443 from more well-known security frameworks, such as ISO 27001, is the order of priority. While ISO 27001 places confidentiality at the heart, IEC 62443 prioritizes availability, integrity and confidentiality, in this sequence.

In industrial environments, an unplanned stop can be as catastrophic as a data breach.In some cases, more.

The standard is structured in four groups of documents, covering everything from fundamentals and management to technical requirements of systems and components. At the core of all levels are seven Fundamental Requirements (Foundational Requirements). Two of them are directly relevant to the Segregation of Functions:

• FR1 — Identification and Authentication Control:every user — human, software process or device — must be identified and authenticated before accessing any control system.

• FR2 — Usage Control:each authenticated user should receive only the privileges strictly necessary to perform their functions - no more, no less.

FR2 is where SoD materializes in the norm. It states that the granting of privileges should be granular, function based and periodically reviewed.

When a single user accumulates privileges to program, operate, and disable alarms, FR2 is being breached — regardless of any intent.

The standard organizes industrial environments into zones and communication duds, following the Purdue Reference Model, and defines four levels of safety - SL 1 to SL 4 - that determine the robustness of the controls required based on the risk profile of each zone.

The higher the level, the greater the requirement for segregation, traceability and access control.

The day-to-day problem: why SoD conflicts in OT are invisible

Industrial systems were designed for availability, not for access traceability. For decades, they operated in isolated networks - the so-called environments air-gapped— where the premise was that physical isolation replaced access controls.

In this context, the culture of “who knows, operates” has been consolidated. The most experienced engineer had access to everything because he was the one who solved the problems.

This logic worked as long as the systems remained isolated. With the convergence between IT (Informationsteknologi— information technology) and OT (Tecnologia operacional— operational technology), this isolation no longer exists.

Industrial networks connect to corporate ERPs, maintenance systems, supplier networks. And with that connectivity, the access risks of the corporate worldmigrated to the industrial environment - without the controls accompanying.

The most critical conflicts in industrial environments follow consistent patterns:

• Whoever programs the PLC should not be the same person who operates the system in production.

• Whoever configures SCADA should not be the same as validating changes in the environment.

• Who has access to the SIS engineering workstation (Safety Instrumented System— instrumented security system, the last automated defense line of a plant) should not have simultaneous access to the DCS (Distributed Control System— distributed control system that governs the production process).

• Whoever can disable security alarms should not be the same person who responds to the event that generated the alarm.

The problem is that these conflicts rarely appear explicitly. They accumulate over time, embedded in permits granted out of urgency, legacies of previous functions or simply never revised.

In a plant with dozens of systems — SCADA, PLCs, DCS, SIS, MES (Manufacturing Execution System— manufacturing execution system), SAP PM — the volume of possible combinations makes any manual analysis unfeasible.

What the real cases taught: Stuxnet and Triton

The theory of SoD conflicts in OT gained concrete contours in two incidents that permanently redefined the way the industrial sector treats access security.

Stuxnet — Natanz, 2010

Stuxnet is considered the first publicly known cyberattack to cause physical damage to an industrial infrastructure. The target was uranium enrichment centrifuges at the Natanz facility in Iran, controlled by Siemens S7 PLCs.

The input vector was an engineering workstation — the station used to program the controller logic. An infected USB introduced the malware onto the network, and from the workstation the code spread directly to the PLCs.

The conflict exploited was necessary: the same station used to program the controllers had unrestricted access to the operational control network. There was no segregation between those who develop automation logic and those who have access to the systems in production.

READ ALSO: Third-party management: the invisible risk that your audit is not seeing

With that access, Stuxnet modified the ladder logic of the PLCs — forcing the centrifuges to operate at irregular speeds — while sending falsified data to SCADA. The operators saw everything “within normal” while the equipment was destroyed.

The structural lesson: unrestricted access of engineering workstations to production control systems is the most exploited attack vector in industrial environments. And it is an SoD conflict that IEC 62443 explicitly addresses.

Triton/Trisis — Petrochemical refinery in the Middle East, 2017

Seven years after Stuxnet, Triton - also known as Trisis or HatMan - represented a qualitative escalation: it was the first public attack specifically aimed at a SIS, the instrumented security system designed to trigger the emergency shutdown of a plant when critical parameters are exceeded.

SIS is, by definition, the last automated barrier between a normal operation and an accident with physical, environmental and life-threatening damage. To attack it directly meant attacking exactly that barrier.

The analysis of Mandiant - security intelligence company that investigated the incident - identified the central mechanism of the vulnerability: engineering workstations with simultaneous access to DCS and SIS.

The report's explicit recommendation is straightforward: stations that program SIS controllers should not be dual-connected to other process control systems.

That is, in essence, an SoD conflict. The same station that configured the security system could access the process system — and vice versa. With this access, the attackers gained complete remote control of SIS, with the technical ability to put the plant in an insecure state.

READ ALSO: Why Artificial Intelligence in risk management is no longer optional

The incident was discovered because the security system triggered an emergency shutdown when it detected a code validation error -- not because access controls alerted anyone.

The structural lesson: the increasing integration between OT and IT networks, without adequate segregation between systems of different criticalities and functions, transforms environments designed for isolation into open attack surfaces. And attackers know exactly where to look for those points.

What the IEC 62443 audit will verify

An IEC 62443 compliance audit is not limited to checking whether firewalls are configured or whether patches are applied. It goes straight to access controls and segregation of functions — because that's where most nonconformities are concentrated.

The points that auditors primarily verify in relation to the SoD:

• Separation of functions between programming and operation of PLCs— is there a formal differentiation between who develops automation logic and who operates the systems in production?

• SIS Engineering Workstation Isolation— do stations that configure security systems have segregated access from other control systems?

• IEC 62443 zone access control— do user privileges respect the zone boundaries defined in the security architecture?

• Alarm Disabling Capability— Who can disable security alarms is formally separated from who responds to events?

• Audit trail and traceability— is there a record of who accessed what, when and with what authorization in each critical system?

• Periodic access review— are user profiles in OT systems reviewed with documented regularity?

Most plants do not have these answers ready - not because controls do not exist, but because they have never been formalized, documented and connected to the zone structure and requirements of IEC 62443. The result is findings that could have been anticipated and remedied before the audit arrived.

How to map SoD conflicts in OT systems before they become a problem

Mapping SoD Conflictsin industrial environments has an additional complexity in relation to the corporate world: OT systems are heterogeneous in nature. SCADA, PLCs, DCS, SIS and MES from different manufacturers, with proprietary access structures, specific industry protocols and interfaces that were not designed for integration with centralized identity management.

What needs to be covered in an effective mapping:

• Inventory of users and profilesin each critical system — who has access to what, in which system and with what level of privilege.

• Crossing incompatible functionsby IEC 62443 zone — which access combinations violate the FR1 and FR2 requirements of the standard.

• Identification of compensatory controlsfor conflicts that cannot be eliminated by technical restriction - and formalization of these controls as auditable evidence.

• Structured documentation by security zone— the SoD Matrix needs to reflect the architecture of zones and wells of IEC 62443, not just a generic list of conflicts.

• Remediation plan with responsible persons and deadline— findings without an action plan do not conclude audit findings.

In plants with dozens of systems and hundreds of users, this mapping by spreadsheet or manual process does not scale, because the volume of possible combinations between profiles, systems and functions exceeds any systematic human analysis.

For IEC 62443, Segregation of Functions is a fundamental requirement because the concentration of incompatible functions in industrial environments is not just a regulatory risk, but a vector that attacks such as Stuxnet and Triton have surgically exploited.

What Natanz and the Middle Eastern petrochemical refinery have in common is not the sophistication of the invaders, but the absence of segregation between functions that should have been separate -- and that, if they were, would have required an additional level of commitment that could have halted the attack before the damage.

In your plant, who programs the PLC can also operate the system and intervene in the security alarms?

If the answer is yes, this is the red flag to investigate the reliability of your SoD Matrix

Vennx's SoD Discovery maps access conflicts across OT and corporate systems, generating the structured SoD Matrix that IEC 62443 audits require with complete traceability and SLA records due to the AI resources used by the company in tracking the entire organization.

Meet SoD Discoveryand talk to a Vennx expert!

‍