OT security tools can identify valuable signals, but an alert rarely explains the production process behind it. Effective investigation depends on bringing network evidence, plant knowledge and security expertise into the same operational view.
OT security alerts need operational context. Learn why OT teams, SOCs and security tools must share information to investigate industrial incidents effectively.
OT teams understand the production process. SOC teams understand the threat. An effective investigation needs both views at the same time.
Many industrial organizations have made substantial progress in OT security.
They have introduced asset discovery, industrial intrusion detection, improved firewalls and more controlled remote access. Security operations centres increasingly receive information from production environments, while specialized OT security platforms provide insight into industrial protocols, vulnerable assets and unusual network behaviour.
The result is more information than most organizations had a few years ago.
Yet when an incident needs to be investigated, the familiar questions still begin to circulate. Is the communication expected? Which production process depends on the affected system? Was maintenance taking place? Who owns the asset? Can it be isolated safely?
The problem is not necessarily that another detection capability is missing. More often, the relevant information already exists but is distributed across tools and teams that see different parts of the situation.
An alert may be technically accurate and still be operationally difficult to interpret.
Two Valid Views Of The Same Event
Consider a pharmaceutical manufacturing site where an engineering workstation begins communicating with a programmable logic controller (PLC) outside its usual production area.
From a security perspective, the connection deserves attention. It crosses an expected boundary, involves an engineering system and differs from the workstation’s established communication pattern.
The plant engineer may see something else. A packaging line is being recommissioned after maintenance, and the workstation has temporarily been moved to support testing. The communication could therefore be legitimate.
Or it could be legitimate work carried out through an unapproved connection. The workstation may be reaching more systems than the commissioning task requires. A temporary firewall rule may be broader than intended. The vendor account used for the work may still be active after the maintenance window.
Knowing that maintenance is taking place does not automatically make the activity safe. Equally, knowing that the network behaviour is unusual does not make it malicious.
A reliable assessment requires both perspectives:
- The SOC needs to understand the purpose and operational role of the systems.
- The OT team needs to understand why the observed behaviour is relevant from a security perspective.
- Both need a timeline that shows what changed, when it changed and which other systems were involved.
Without that shared context, the investigation tends to move between two unhelpful extremes. The alert is escalated without enough operational understanding, or it is dismissed as maintenance without examining whether the activity remained within its intended scope.
Strong Tools, Fragmented Investigations
Industrial security environments rarely rely on a single source of information.
An OT security platform may provide asset and protocol context. A firewall records traffic across zones. A remote access solution shows which supplier connected and when. Switch telemetry helps establish communication paths. The SOC may also have endpoint, identity and threat intelligence data from the wider IT environment.
Each source answers a different question.
The practical difficulty begins when an analyst has to assemble those answers during an investigation. The initial alert may show unusual communication, but determining its significance requires a series of manual steps:
- Identify the systems involved and their production roles.
- Check whether maintenance or engineering work was scheduled.
- Review remote access sessions and recent network changes.
- Determine whether the communication is new or has occurred before.
- Ask the plant team what operational impact containment would have.
- Record enough evidence to support escalation and later reporting.
In a well-resourced internal SOC, some of this context may be available through established integrations and local knowledge. In an external SOC or managed security service, the analyst may have little familiarity with the plant, its production process or the equipment vendor.
The alert still arrives. The ability to interpret it does not necessarily arrive with it.
The Translation Between OT And Security
OT and SOC teams often appear to speak different languages because they are responsible for different risks.
The SOC thinks in terms of threat behaviour, affected systems, lateral movement, containment and evidence. Plant teams think in terms of process state, equipment dependencies, safety, product quality and availability.
Neither view is more correct.
If the SOC recommends isolating an engineering workstation, the OT team needs to know whether doing so will stop a production line or interfere with a safety-relevant process. If the plant wants to keep a connection open for an OEM, the SOC needs to understand which systems can be reached, how access is authenticated and whether activity can be reconstructed afterwards.
The challenge is therefore not simply to send more OT alerts into security operations. It is to translate technical activity into enough operational context for the right people to make a decision.
For an investigation, that context may include:
- The production function of the affected assets
- Their network zone and normal communication partners
- Recent maintenance, commissioning or configuration changes
- The owner responsible for the equipment or process
- Historical communication before and after the alert
- Known remote access sessions
- The operational consequences of isolation
Not every field needs to appear automatically in every alert. Some knowledge will continue to reside with the people operating the plant. What matters is that teams can reach a consistent view without rebuilding the entire situation from several disconnected systems.
SOC asks:
Is it malicious, how far did it spread and how do we contain it?
OT asks:
Which process is affected, is it safe to intervene and what happens to production?
Why Sending Everything To The SIEM Is Not Always The Answer
The traditional response to fragmented security information is centralization. Send the available logs and alerts to the security information and event management (SIEM) platform, build correlation rules and allow the SOC to investigate from there.
For some organizations, this is the right approach. A mature SIEM environment with established OT integrations, appropriate retention and analysts who understand industrial operations can provide considerable value.
But the decision is not as simple as forwarding every available OT data source.
Industrial estates can include many sites, network devices and specialized security systems. Collecting all available events may increase ingestion and storage costs without improving investigations proportionally. The SOC may receive more alerts but still lack the production context needed to determine what they mean. Some OT teams may also be reluctant to depend on a complex, IT-centric platform for everyday operational analysis.
The more useful question is not “Can we send this data to the SIEM?” It is “Which information helps someone make a better decision?”
Sometimes that means forwarding a prioritized alert with sufficient asset, network and historical context. In other cases, the OT team needs a separate but connected view that allows it to examine communication without working directly inside the SOC platform. External providers may require access to the same evidence, but not necessarily to every underlying system.
Centralization can help. indiscriminate collection usually does not solve the underlying collaboration problem.
Which information helps someone make a better decision?
Context Before Correlation
Security teams often talk about correlating events. In OT, useful correlation begins with understanding the systems and processes behind those events.
Suppose an OEM connects remotely during a scheduled shutdown. Shortly afterwards, an engineering workstation communicates with several controllers, a new connection appears between production zones and a firewall policy is changed.
Each event could be legitimate within the maintenance activity. Together, they provide a sequence that should be validated:
- Did the connection begin within the approved window?
- Was the expected vendor account used?
- Did the workstation reach only the systems included in the work order?
- Was the firewall change authorized and appropriately limited?
- Did the communication stop when maintenance ended?
- Was temporary access removed afterwards?
The value comes from connecting the technical events to the operational purpose of the work. A simple “maintenance was planned” label is not enough. The investigation needs to establish whether the observed activity remained consistent with that plan.
This is where historical network evidence becomes particularly useful. It allows teams to see when connections appeared, how behaviour changed during the work and whether anything persisted after the maintenance window closed.
Instead of deciding whether an isolated alert is normal or suspicious, the team can assess whether the full sequence makes operational sense.
A Shared View Without Replacing Every Tool
Improving OT investigations does not require every organization to replace its existing security platforms or consolidate all capabilities into one system.
Specialized OT security tools remain important for industrial asset discovery, protocol analysis and OT-specific detection. Firewalls and remote access platforms provide their own essential records. SIEM and SOC processes bring wider threat context and established escalation workflows.
The objective is to make the information generated by these systems usable across team boundaries.
A shared operational view should allow an OT engineer, SOC analyst or external provider to examine the same basic facts while applying their own expertise. They may interpret the evidence differently at first, which is precisely why collaboration matters. At least they are discussing the same assets, communication paths and timeline.
At Exeon, this is where we see a practical role for consolidating network metadata, infrastructure telemetry and security information without trying to replace the specialist systems already deployed. The purpose is not to create another isolated alert source. It is to make existing signals easier to investigate and operationalize.
The technology matters, but the more important outcome is shared understanding.
From More Detection To Better Decisions
OT security maturity is sometimes measured by the number of sites monitored, assets discovered or alerts sent to the SOC. These indicators are useful, but they do not show whether the organization can act when something relevant occurs.
A stronger test is to take a recent or representative alert and follow it through the investigation:
- Could the analyst identify the operational role of the systems?
- Was historical communication readily available?
- Did the OT team understand why the activity was security-relevant?
- Could the teams distinguish planned work from activity beyond the approved scope?
- Was the evidence sufficient to support a containment or escalation decision?
If answering those questions requires prolonged manual reconstruction, the organization may have detection coverage without an effective operating model.
The next stage of OT security is not simply to generate more information. It is to connect security evidence with the people who understand what the systems do and what is at stake when they change.
An OT alert becomes useful when it supports a decision. Reaching that point requires more than detection. It requires context that both sides can trust.
Key Takeaways
- OT security tools, firewalls, remote access systems and SOC platforms each provide part of the information required for an investigation.
- An unusual connection cannot be assessed reliably without understanding the affected production process, recent maintenance and operational dependencies.
- Planned engineering work should provide context for an investigation, not a reason to dismiss unusual activity automatically.
- Sending more OT data to a SIEM does not necessarily solve the problem if analysts still lack operational context.
- A shared view of assets, communication history and relevant security events helps OT teams, SOCs and external providers make decisions from the same evidence.
Continue Reading
OT Security Without the Overhead
How can organizations connect OT security information, network evidence and operational expertise without introducing unnecessary SIEM complexity?
Download the white paper OT Security Without the Overhead to explore a practical approach to building a shared operational picture across OT teams, security operations and external providers.
OT Security Evaluation Guide
The OT Security Evaluation Guide includes practical questions for assessing whether your current tools and processes provide enough context for investigation, collaboration and incident response.
