#insights

Industrial cybersecurity must understand what an attack could cause, how to contain it without compromising operations, and which external dependencies could amplify its impact. The objective is not to protect systems in isolation, but to preserve the ability to operate.

An attacker does not need to bring an entire plant to a halt. Compromising the right system may be enough. A hasty response can do the rest.

An account used outside normal hours or an unexpected change to a controller raises a critical question. What happens if we act, and what happens if we do not? In industrial and mobility environments, disconnecting a device may contain a threat, but it may also disrupt a critical function.

The OT SOC and security beyond the core in industry and mobility

An out-of-hours remote connection, an unexpected change to a controller or a maintenance account accessed from an unknown source are all signals that require investigation. For those responsible for an industrial plant or transport infrastructure, the immediate question is what could happen if that activity reaches operational systems.

This question marks the difference between detecting an incident and being prepared to manage it. In an industrial environment, teams need to understand what the affected equipment controls, which systems depend on it and what the consequences of isolating it would be. Protecting people, maintaining availability and accounting for physical processes require security and response measures to be adapted accordingly.

The evolution of the OT SOC involves moving from perimeter-focused security to consequence-oriented security. It also requires a broader view that includes suppliers, remote access, updates and components. This approach to security beyond the OT core connects digital protection with operational reality.

The SOC’s next step is to understand operations

Incorporating industrial logs into the corporate SOC improves visibility, but it is not enough. An alert only becomes operationally valuable when it provides the context needed to decide.

Detecting a change to a controller does not resolve the incident. The team must compare it against authorised work, identify the affected function and determine whether the process is deviating from its expected state. MITRE ATT&CK for ICS includes behaviours such as program modification, the use of valid accounts and access through remote services. None of these signals should be interpreted in isolation.

The key is to connect what is happening on the network with what it means for the process and with the options available to operations. To achieve this, the asset inventory must become more than a list of devices. It must also represent functions, criticality, dependencies and accountable owners. CISA’s guidance on OT asset inventories identifies this contextualisation as a basis for prioritising assets and improving incident response.

The OT SOC is therefore a collaborative model involving cybersecurity, engineering, operations and maintenance. Its effectiveness depends on these teams sharing information, priorities and the authority to act.

From critical alert to operational impact

The technical severity of an alert does not, on its own, explain its importance to service continuity. A seemingly secondary system may support a critical function, while an asset with a severe vulnerability may be isolated or out of service.

Every incident should be analysed through a sequence that connects digital evidence with operational decision-making.

Signal → Asset → Function → Consequence → Decision → Recovery

Consider an unexpected remote connection to an engineering workstation, followed by a change to a controller’s configuration. Before blocking access or isolating the equipment, the OT SOC checks whether authorised work is taking place, identifies the process controlled by the device and assesses the consequences of disrupting communications. With this information, cybersecurity and operations teams can select a containment measure that is compatible with process safety and continuity.

Each detection use case should specify what must be verified, which function may be affected, who needs to be involved, which measures are authorised and how recovery will be validated. The OT SOC does not replace those responsible for operational decision-making. It enables them to decide sooner, with better evidence and prepared alternatives.

Operations do not end at the network boundary

The supply chain forms part of the attack surface. MITRE ATT&CK for ICS identifies compromised products and delivery mechanisms, remote services, transient devices and removable media as potential access routes into industrial systems.

Applying this perspective to the OT SOC does not mean monitoring every supplier indiscriminately. It means understanding the relationships that may affect operations.

• Who can access each environment and with which permissions.
• What type of work justifies a remote connection.
• Which components and versions support critical functions.
• How an update is validated before deployment.
• Which responsibilities each party assumes in the event of an incident.

This visibility must answer specific questions. If an integrator’s account is compromised, the team must be able to identify where it was used and what actions were performed. If a vulnerability is discovered in a component, the team must know where that component is installed and which function depends on it. If a supplier becomes unavailable, an alternative procedure must be in place.

Protecting beyond the core does not mean expanding the monitoring perimeter without limit. It means identifying the dependencies that could transmit a threat or hinder recovery.

AI as an analytical aid

Artificial intelligence can expand the OT SOC’s analytical capabilities, provided it is applied to clearly defined problems and human oversight is maintained for critical decisions. Joint guidance from CISA, the NSA and other organisations recommends starting with specific benefits, establishing testing procedures, monitoring performance and implementing fail-safe mechanisms.

One initial application is contextualised detection. Anomaly-detection techniques can help identify deviations from normal behaviour, but an anomaly does not necessarily indicate an attack. A shutdown, a change in production or legitimate maintenance work may also alter the expected pattern.

AI can also support investigations by organising evidence, preparing timelines, retrieving procedures and suggesting hypotheses. In industrial threat hunting, it can help relate indicators to behaviours described in MITRE ATT&CK for ICS, such as program changes, alarm suppression or the misuse of accounts.

Results must be checked against the available information and knowledge of the process. Success should not be measured by the number of tasks handled by the model, but by whether it helps the team investigate more effectively and reduce uncertainty.

Automating without compromising operations

Automation must be scaled according to the potential consequences of each action. Collecting information, enriching an alert or notifying an accountable person does not present the same level of risk as interrupting communications or acting directly on a control system.

It is useful to distinguish between supporting actions, limited and pre-authorised measures, and critical interventions that require an operational decision. Having the technical ability to perform an action is not sufficient justification for automating it.

Before automating a response, teams must assess what would happen if the detection were incorrect. When an action could result in a loss of control, unavailability or risks to people, validation is not a formality. It is part of the protection itself.

Connecting engineering, data and cybersecurity

This model requires an understanding of both the digital threat and the physical system it could affect. Sener Dcode combines knowledge of industrial processes with capabilities in engineering, data, artificial intelligence, and OT and IT cybersecurity. This combination makes it possible to relate technical signals to operational functions and design responses that are compatible with service continuity.

The evolution towards an OT SOC can be approached as a connected journey.

• Understanding operations and their potential impact scenarios.
• Designing visibility that is compatible with industrial constraints.
• Linking detections to procedures and accountable roles.
• Assessing AI and automation according to their usefulness and potential consequences.
• Testing response and recovery through exercises and continuous improvement.

The objective is not to see more, but to interpret events more effectively and turn that information into decisions that preserve operations.

This approach reflects the combination of engineering and cybersecurity that Sener applies in complex industrial environments.

Measuring success by the ability to operate

Detection and response indicators should be complemented by measures of operational preparedness. These include critical assets with validated dependencies, traceable third-party access, use cases linked to procedures, tested impact scenarios, decision-making times and recovery test results.

The maturity of an OT SOC does not depend solely on the number of alerts it detects or closes. It depends on its ability to identify which function is at risk, anticipate the consequences of each decision and coordinate a response that is compatible with operations.

Industrial cybersecurity does not end when an intrusion is detected. Its purpose is to prevent that intrusion from resulting in a loss of control, service or trust.