Unauthorized network access
A new device talking to a PLC, an IT workstation reaching an OT controller, an unexpected protocol, port or device pair, or traffic at the wrong rate or time.
Trood · Industrial security
Intrusion detection for industrial IoT and OT
We find activity that is technically valid and still wrong – early enough to investigate before it becomes an operational, safety or business incident.
The principle
Understand what exists, what is allowed to communicate, what each device is expected to do, and what counts as abnormal.
Conventional intrusion detection looks for traffic that is known to be bad. In a plant, the damaging command is often a perfectly valid one – sent from the wrong place, at the wrong time, to the wrong controller, with a physical consequence nobody connected to it. So we model the environment first, and judge every event against what that environment is supposed to be doing.
What it detects
Unauthorized commands
A write to a controller that never receives writes, a valid command from an unexpected source, or a sequence of individually valid commands that should not occur together.
Cyber-physical anomalies
Parameters pushed outside the operating envelope, sensor values that disagree with the rest of the process, or a cyber event followed by an abnormal physical response.
Sensor and device tampering
Impossible or inconsistent readings, a changed sensor identity or configuration, or a device drifting from its own historical baseline.
Rogue hardware
Unknown network devices, unexpected controllers, or a model, firmware or configuration that does not match the expected device profile.
Lateral movement
Previously isolated devices starting to talk, new communication paths appearing, or one endpoint scanning or reaching across several controllers.
Cyber events, read against the physical process
This is where we differ. We correlate the cyber event with what the device did, the state of the process, and the physical consequence. An attack that looks normal in network traffic alone stops looking normal once the process is in the picture.
- 01Unexpected access
A source that has never reached this zone connects to it.
- 02Controller command
It issues a command the controller does accept.
- 03Parameter changed
A setpoint moves – still within what the protocol allows.
- 04Temperature rises
The process responds, as it was told to.
- 05Cooling response abnormal
The physical system stops behaving the way its history says it should.
- 06Potential cyber-physical attack
Read together, five unremarkable events become one incident.
Risk is contextual. A new device, plus access to a controller, plus an unusual command, plus an abnormal temperature change is one high-risk incident – not four alerts for an operator to stitch together.
How it works
Three sources of intelligence feed one detection engine, which reports to your operators. Normal behaviour is learned at four levels – network, device, identity and process – so a deviation is always a deviation from something specific.
Network intelligence
TAP / SPAN, flows, firewall and infrastructure logs, and protocol metadata for Modbus TCP, OPC UA, MQTT, EtherNet/IP and PROFINET. Protocol-agnostic, so new parsers can be added.
Asset intelligence
What each device is, where it sits, what it runs, what it talks to, what it is expected to do, and which physical process it affects – kept as a living asset and relationship graph.
Process and physical data
Pressure, temperature, current, flow, vibration, RPM, valve and motor state – whatever the process exposes, through the historian or SCADA you already have.
Detection engine
Deterministic rules for known violations, behavioural baselines for drift, and contextual risk scoring that combines weak signals instead of alerting on each one.
Every alert explains itself
Each detection carries the assets involved, source and destination, the observed behaviour next to the expected behaviour, the policy it touches, the related process signals, a risk and a confidence level, and suggested next steps. Related events are grouped into incidents.
Operators investigate through an environment map of assets, zones and communication paths, an incident timeline from first access to physical response, and a full history for every asset. For every alert the system answers two questions: why was this considered abnormal, and what changed compared with the baseline.
AI sits on top of this rather than in place of it – natural-language investigation, incident summaries, correlation of weak signals and help writing detection rules, all inside strict access and audit boundaries.
Built for OT
Passive first
Monitoring from a TAP or SPAN port. The system never sits in the control path.
Monitoring is not control
Watching and acting are separate functions with separate permissions.
On-premise by default
Local collectors and a private platform. Cloud is optional and yours to decide.
Auditable
Least privilege, role-based access, strong identity, encryption and immutable security logs.
AI inside boundaries
AI assists investigation. It has no uncontrolled access to critical OT systems.
Active response is a later phase
Blocking or automated control changes only after rigorous safety validation and explicit approval.
It augments your security environment rather than replacing it: connectors for SIEM and SOC, IAM, firewalls, asset management, SCADA / HMI, historians, existing OT security platforms, ticketing and IoT platforms.
How we start
Not with every possible attack. A first deployment covers a small number of high-value scenarios, validated against concrete attack scenarios you give us.
- 01Discover
Passive network discovery and an automatic asset inventory.
- 02Map
The asset relationship graph and a baseline of normal communication.
- 03Detect
Unauthorized communication, unexpected devices, command anomalies, and configuration or firmware changes.
- 04Correlate
Selected process and sensor data, joined to cyber events into risk-ranked incidents.
- 05Investigate
A dashboard for operators and an integration into your SIEM or SOC.
Success is not the number of attacks detected. It is whether meaningful deviations surface early enough for you to investigate and respond.
What we will ask you
We choose technology and architecture after we understand your environment, not before. The first conversation covers:
- Your industry and the physical process
- Number and types of assets, and how many sites
- Network topology and OT / IT segmentation
- Industrial protocols in use
- SCADA, PLC and DCS infrastructure
- Security products already in place
- Network telemetry and process data available
- Deployment model and retention period
- SOC integration and expected alert volume
- Regulatory requirements that apply to you
- The attack scenarios you most need to catch