AI-Based Threat Detection in Industrial OT Networks

The central problem is to detect suspicious or abnormal communication and events in industrial OT networks without creating excessive false alarms or interfering with essential control operations. The solution must account for industrial protocols, device roles, baseline process behaviour, limited labelled attack data, and strict availability requirements. 1.2 Objectives The objectives are to: (i) design a modular AI-based monitoring pipeline for authorised OT network data; (ii) extract useful protocol, timing, and device-behaviour features; (iii) compare supervised classification with anomaly detection; (iv) prioritise alerts using explainable risk scoring; (v) evaluate detection quality, false-positive rate, and latency; and (vi) preserve safety, privacy, and human oversight. 1.3 Scope The proposed system is intended for defensive monitoring in a laboratory or industrial environment where explicit permission has been granted. It is designed to observe traffic and logs passively wherever feasible. It does not replace network segmentation, secure configuration, endpoint protection, incident-response plans, safety systems, or expert OT security assessment.

Research in intrusion detection includes signature-based methods, statistical baselines, supervised machine learning, unsupervised anomaly detection, and hybrid approaches. Surveys of machine-learning techniques for cybersecurity describe how classification and data-mining methods can support the analysis of large volumes of security events, while also highlighting the importance of dataset quality and deployment conditions. Sommer and Paxson discuss the difficulty of transferring machine-learning results from controlled experiments to operational network intrusion detection. Industrial cybersecurity guidance places additional emphasis on system availability, safety, segmentation, asset inventory, and controlled change management. NIST guidance for operational technology security explains that OT environments have distinct reliability and safety requirements compared with typical IT systems. Industrial traffic also tends to be shaped by device roles and recurring process cycles; a model that treats all deviations as attacks may therefore generate unacceptable alert volumes. Public intrusion-detection datasets can support initial experiments, but generic enterprise traffic may not accurately represent industrial protocols or process states. Datasets such as the TON_IoT telemetry and network dataset and industrial control-system datasets may be considered after reviewing their documentation, coverage, licences, and limitations. Dataset results should not be presented as proof of production readiness.

A practical gap remains between benchmark detection scores and reliable use in a live industrial setting. OT-aware systems need to distinguish normal engineering activity, scheduled maintenance, and process transitions from potentially malicious behaviour. Evaluation should report false positives, detection latency, attack-category performance, and robustness across time periods or device groups. Safety constraints also require that detection be separated from automatic control actions.

The proposed framework passively receives authorised network metadata, industrial protocol summaries, and selected device or security logs. A preprocessing layer validates records and maps them to a common representation. A supervised classifier identifies patterns represented in labelled training data, while an anomaly detector identifies deviations from learned normal behaviour. A risk-scoring module combines these outputs with transparent rules based on asset criticality and event context. Alerts are displayed to an OT security analyst for review and escalation according to approved procedures.

Figure 1. Proposed processing flow (conceptual): Authorised OT traffic/logs → Validation and preprocessing → OT-aware feature extraction → ML classifier + anomaly detector → Contextual risk scoring → Alert dashboard → Human analyst review

Module Purpose Data ingestion Receive approved passive network metadata, protocol summaries, asset inventory, and selected logs. Preprocessing Validate fields, handle missing values, remove duplicates, and align timestamps. OT feature extraction Represent source/destination roles, protocol function, communication frequency, timing, and unusual command patterns where safely observable. Detection engine Run a supervised classifier and an anomaly detector on prepared features. Risk scoring Combine model outputs with asset criticality and transparent rules; avoid treating scores as certainty. Alert management Store time, asset context, alert reason, model version, and analyst review status. Monitoring Track drift, false positives, inference latency, and changes in traffic volume.

A student prototype can use Python, Pandas, NumPy, and scikit-learn for data processing and model development. FastAPI can expose authenticated inference and alert endpoints, while SQLite can store prototype alert metadata; PostgreSQL may be used for a larger implementation. A lightweight dashboard can support searching, filtering, and reviewing alerts. Initial testing should use offline packet metadata or approved dataset files. Any live traffic collection must be authorised and configured to avoid sending disruptive probes or commands to industrial devices. 4. Methodology

The initial prototype may use documented public industrial cybersecurity datasets, such as TON_IoT or other suitable ICS/OT datasets, subject to their licence and intended use. Dataset selection should consider protocol coverage, labels, normal-operation periods, attack categories, and whether the data reflects the target environment. If local data is used, collection requires written authorisation and should minimise personal or sensitive operational information. This paper does not claim that experiments have already been conducted. 4.2 Preprocessing The preprocessing procedure includes checking data types and timestamp consistency; handling missing and duplicate records; separating labels from input features; reviewing class distribution; and removing identifiers that could cause leakage or memorisation. Data should be split by time, capture session, or device group when feasible. Encoders and scalers must be fitted on training data only. Any class rebalancing should be applied only to the training set, not to the test set.

A Random Forest or gradient-boosted tree model can serve as the supervised baseline for structured traffic features. An Isolation Forest or another suitable unsupervised method can provide an anomaly score when labelled attack examples are limited. Model selection should consider inference cost, interpretability, data requirements, and performance on rare attack classes. A combined approach may reduce dependence on a single detection method, but its benefit must be established experimentally.

Each alert should include a timestamp, affected asset or pseudonymous asset identifier, observed communication context, predicted category, confidence or anomaly score, severity band, and concise explanation. Alert thresholds should be selected using validation data and the organisation's tolerance for false positives. High-impact responses must remain under authorised human control. The prototype should not automatically stop a production process, modify PLC logic, or block industrial traffic.

1. Load approved OT records and validate the schema. 2. Apply the saved preprocessing pipeline. 3. Extract protocol, timing, and device-behaviour features. 4. Generate classifier probabilities and anomaly scores. 5. Combine outputs with transparent contextual rules. 6. Create alerts above a validation-selected threshold. 7. Store supporting evidence and model version. 8. Allow analyst review and periodically assess drift before any approved retraining.

The prototype should authenticate API users, enforce role-based access, encrypt network connections, restrict access to logs, keep secrets outside source code, validate input schemas, limit upload sizes, and record administrative actions. Data retention should be limited to a defined purpose and period. Any deployment touching an OT network should be reviewed by qualified OT personnel and follow approved change-management and safety procedures.

7.1 Advantages

The proposed design combines supervised detection with anomaly detection, accounts for industrial asset context, supports traceable alert review, and can begin with offline datasets before being extended in a controlled manner. Its modular architecture allows different models and data sources to be evaluated without making detection directly responsible for control actions. 7.2 Limitations Detection quality depends on the representativeness and quality of training data. Labelled OT attack examples may be scarce, while legitimate changes in production, maintenance, or device configuration can cause false alarms. Models can drift as network behaviour changes. Public datasets may not represent a particular facility, and encrypted traffic or limited protocol visibility may restrict available features. Real-world use therefore requires site-specific validation and ongoing oversight.

The system must only monitor networks and logs for which permission has been granted. Data collection should follow applicable law and organisational policy. Access restrictions, data minimisation, retention limits, and secure storage are essential. AI-generated alerts should support rather than replace expert judgement. Detection should be integrated with an approved incident-response process, and any action that may affect physical operations must be reviewed by authorised OT and safety personnel.

Future work may include streaming ingestion from passive network sensors, industrial-protocol-aware feature extraction, threat-intelligence enrichment, explainability methods such as SHAP for compatible models, drift detection, and integration with a security information and event management (SIEM) platform. Additional work could evaluate privacy-preserving collaboration across sites and develop OT-specific test scenarios in a digital twin or isolated laboratory. Validation on temporally separated and site-specific data is necessary before production use. 10. Conclusion This paper proposed an AI-based framework for detecting threats in industrial OT networks by combining authorised passive data collection, OT-aware feature extraction, supervised classification, anomaly detection, contextual risk scoring, and human-reviewed alerts. The design recognises that industrial systems have availability and safety requirements that differ from ordinary IT environments. It therefore emphasises conservative alerting, reproducible evaluation, secure data governance, and separation between detection and automatic control. The framework can support a defensive academic prototype, but its effectiveness and suitability for a specific facility must be established through controlled experiments and expert review.