{"data":{"slug":"ot-network-monitoring","title":"OT Network Monitoring and Anomaly Detection","summary":"You cannot respond to what you cannot see. OT networks are typically monitored far less than IT networks — many plants discover an intrusion months after it…","category":{"slug":"industrial-cybersecurity","name":"Industrial Cybersecurity"},"url":"https://wiki.aspotomasyon.com/article/ot-network-monitoring","markdown_url":"https://wiki.aspotomasyon.com/article/ot-network-monitoring.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/ot-network-monitoring","published":"2026-08-11T13:05:24+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":4,"word_count":821,"image":"https://wiki.aspotomasyon.com/assets/social/ot-network-monitoring-53cd5876949f.png","html":"<p>You cannot respond to what you cannot see. OT networks are typically monitored far less than IT networks — many plants discover an intrusion months after it happened, or never. <strong>OT network monitoring</strong> is the practice of watching the control network for security and operational anomalies: new devices, unexpected connections, protocol misuse, and communication failures. Modern OT monitoring is built on passive observation — no agents on the controllers — which makes it safe for the systems it protects.</p><figure class=\"article-figure\"><img src=\"https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-context.svg\" width=\"1100\" height=\"460\" loading=\"lazy\" decoding=\"async\" alt=\"Conceptual access controls around an OT service. Actual zones, conduits, protections, and response actions require a site-specific assessment.\"><figcaption>Conceptual access controls around an OT service. Actual zones, conduits, protections, and response actions require a site-specific assessment. <a href=\"https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-context.svg\" target=\"_blank\" rel=\"noopener\">View full size</a></figcaption></figure>\n\n<h2 id=\"what-ot-monitoring-must-detect\">What OT Monitoring Must Detect</h2>\n\n<ul>\n  <li><strong>New or unexpected devices</strong> — an unknown MAC/IP appearing on the OT network is the classic first sign of an intrusion or an unmanaged addition.</li>\n  <li><strong>Unexpected connections</strong> — a workstation suddenly talking to a controller it has never addressed; a device reaching out to the internet; lateral movement between zones.</li>\n  <li><strong>Protocol anomalies</strong> — malformed packets, out-of-sequence commands, writes to addresses that are normally read-only, engineering-tool activity outside maintenance windows.</li>\n  <li><strong>Baseline violations</strong> — behavior that deviates from the learned normal: new command types, changed polling patterns, new users or privileges.</li>\n  <li><strong>Operational anomalies</strong> — communication losses, controller restarts, and alarming — the same data serves reliability and security.</li>\n</ul>\n\n<h2 id=\"passive-monitoring-architecture\">Passive Monitoring Architecture</h2>\n\n<p>The safe architecture is <strong>passive</strong>: network taps or SPAN ports feed traffic to a monitoring appliance that inspects without touching the production path:</p>\n\n<ul>\n  <li><strong>Sensor placement</strong> — at the zone boundaries (between OT and IT, at the DMZ), at the core switch, and at the critical subnets; the monitoring sees traffic without inline risk.</li>\n  <li><strong>No agents</strong> — industrial protocols (Modbus, OPC, PROFINET, EtherNet/IP) are inspected at the packet level; the controllers and HMIs are untouched — the key advantage over IT-style endpoint agents.</li>\n  <li><strong>Protocol-aware parsing</strong> — OT IDS/NDR products decode the industrial protocols themselves, so \"write to coil register 40001\" means something to the analyzer, unlike a generic IT IDS.</li>\n  <li><strong>Asset identification</strong> — passive fingerprinting builds the asset inventory (what is out there, running what) — often the first accurate inventory the plant has ever had.</li>\n</ul>\n\n<h2 id=\"baseline-then-detect\">Baseline, Then Detect</h2>\n\n<p>OT monitoring works in two phases. First, <strong>learn the baseline</strong>: weeks of observation establish who talks to whom, which protocols, which ports, at what times. Then <strong>detect deviation</strong>: the system alerts on changes against the baseline. This design suits OT perfectly — normal behavior in a plant is far more regular than in IT, so deviation detection has a low false-alarm rate when configured with the plant's shift patterns and maintenance windows. The tuning work is real: every planned change (new machine, new HMI) becomes a baseline update, and the alert review process must be staffed — an unmonitored monitoring system is decoration.</p>\n\n<h2 id=\"integrating-with-the-security-operations\">Integrating with the Security Operations</h2>\n\n<p>OT monitoring feeds the incident response process (see the incident response article): alerts are triaged with the plant's OT team, correlated with IT monitoring where the DMZ connects, and escalated per the OT incident procedure. Practical integration points: a joint SIEM that receives both OT and IT alerts; a weekly review of the OT alert log by the automation team; and the alarm philosophy applied to security alerts — too many alerts produce ignored alerts, so severity levels and throttling must be designed, not defaulted.</p>\n\n<h2 id=\"operational-considerations\">Operational Considerations</h2>\n\n<ul>\n  <li><strong>Network design first</strong> — monitoring needs the network segmented enough to be observable (VLANs, zones); a flat network is hard to monitor meaningfully and is a finding in itself.</li>\n  <li><strong>Encryption blind spots</strong> — encrypted traffic (increasing on modern protocols) hides content from passive sensors; the response is to monitor the endpoints' behavior (connections, timing) and the plaintext control protocols that remain.</li>\n  <li><strong>Performance impact</strong> — SPAN ports and taps must handle peak traffic; an oversubscribed monitor drops packets exactly when it matters most.</li>\n  <li><strong>Data retention</strong> — retain the flow and alert records per the security program (typically 6–12 months) — post-incident forensics depend on them.</li>\n</ul>\n\n<h2 id=\"summary\">Summary</h2>\n\n<p>OT network monitoring gives the plant eyes on its control traffic: passive sensors, protocol-aware analysis, baseline-based anomaly detection, and integration with the incident process. Deploy at zone boundaries, learn the baseline, staff the alert review, and feed the findings into the risk and change processes. The first intrusion that is caught because the monitoring showed \"a laptop joined the control network at 02:13\" pays for the entire program.</p><section class=\"engineering-check\"><h2 id=\"apply-this-to-your-project\">Apply this to your project</h2><ul><li>Identify asset owners, permitted communications, operational dependencies, and consequences of losing the function.</li><li>Test access restrictions and visibility without disrupting plant operations; agree the activity with the OT owner.</li><li>Validate an offline recovery path and document who can authorize isolation, restoration, and return to service.</li></ul><p><a href=\"https://wiki.aspotomasyon.com/guides\">Follow an ASP project guide</a> to connect the fundamentals with implementation and acceptance.</p></section><figure class=\"article-figure\"><img src=\"https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-review.svg\" width=\"1100\" height=\"460\" loading=\"lazy\" decoding=\"async\" alt=\"Engineering review sequence: Inventory → Restrict → Observe → Recover. Keep the recorded evidence with the accepted configuration.\"><figcaption>Engineering review sequence: Inventory → Restrict → Observe → Recover. Keep the recorded evidence with the accepted configuration. <a href=\"https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-review.svg\" target=\"_blank\" rel=\"noopener\">View full size</a></figcaption></figure><h2 id=\"primary-references-and-further-reading\">Primary references and further reading</h2><p>Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.</p><ul><li><a href=\"https://csrc.nist.gov/pubs/sp/800/82/r3/final\" rel=\"noopener noreferrer\" target=\"_blank\">NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security</a></li><li><a href=\"https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards\" rel=\"noopener noreferrer\" target=\"_blank\">ISA — ISA/IEC 62443 series</a></li></ul><!-- asp-editorial-202609 -->","markdown":"# OT Network Monitoring and Anomaly Detection\n\n> You cannot respond to what you cannot see. OT networks are typically monitored far less than IT networks — many plants discover an intrusion months after it…\n\n- Canonical URL: https://wiki.aspotomasyon.com/article/ot-network-monitoring\n- Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki)\n- Category: Industrial Cybersecurity\n- Published: 2026-08-11 · Updated: 2026-09-13\n- Reading time: 4 min · Language: English\n\nYou cannot respond to what you cannot see. OT networks are typically monitored far less than IT networks — many plants discover an intrusion months after it happened, or never. **OT network monitoring** is the practice of watching the control network for security and operational anomalies: new devices, unexpected connections, protocol misuse, and communication failures. Modern OT monitoring is built on passive observation — no agents on the controllers — which makes it safe for the systems it protects.\n\n![Conceptual access controls around an OT service. Actual zones, conduits, protections, and response actions require a site-specific assessment.](https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-context.svg)\n\n*Conceptual access controls around an OT service. Actual zones, conduits, protections, and response actions require a site-specific assessment.*\n\n## What OT Monitoring Must Detect\n\n- **New or unexpected devices** — an unknown MAC/IP appearing on the OT network is the classic first sign of an intrusion or an unmanaged addition.\n- **Unexpected connections** — a workstation suddenly talking to a controller it has never addressed; a device reaching out to the internet; lateral movement between zones.\n- **Protocol anomalies** — malformed packets, out-of-sequence commands, writes to addresses that are normally read-only, engineering-tool activity outside maintenance windows.\n- **Baseline violations** — behavior that deviates from the learned normal: new command types, changed polling patterns, new users or privileges.\n- **Operational anomalies** — communication losses, controller restarts, and alarming — the same data serves reliability and security.\n\n## Passive Monitoring Architecture\n\nThe safe architecture is **passive**: network taps or SPAN ports feed traffic to a monitoring appliance that inspects without touching the production path:\n\n- **Sensor placement** — at the zone boundaries (between OT and IT, at the DMZ), at the core switch, and at the critical subnets; the monitoring sees traffic without inline risk.\n- **No agents** — industrial protocols (Modbus, OPC, PROFINET, EtherNet/IP) are inspected at the packet level; the controllers and HMIs are untouched — the key advantage over IT-style endpoint agents.\n- **Protocol-aware parsing** — OT IDS/NDR products decode the industrial protocols themselves, so \"write to coil register 40001\" means something to the analyzer, unlike a generic IT IDS.\n- **Asset identification** — passive fingerprinting builds the asset inventory (what is out there, running what) — often the first accurate inventory the plant has ever had.\n\n## Baseline, Then Detect\n\nOT monitoring works in two phases. First, **learn the baseline**: weeks of observation establish who talks to whom, which protocols, which ports, at what times. Then **detect deviation**: the system alerts on changes against the baseline. This design suits OT perfectly — normal behavior in a plant is far more regular than in IT, so deviation detection has a low false-alarm rate when configured with the plant's shift patterns and maintenance windows. The tuning work is real: every planned change (new machine, new HMI) becomes a baseline update, and the alert review process must be staffed — an unmonitored monitoring system is decoration.\n\n## Integrating with the Security Operations\n\nOT monitoring feeds the incident response process (see the incident response article): alerts are triaged with the plant's OT team, correlated with IT monitoring where the DMZ connects, and escalated per the OT incident procedure. Practical integration points: a joint SIEM that receives both OT and IT alerts; a weekly review of the OT alert log by the automation team; and the alarm philosophy applied to security alerts — too many alerts produce ignored alerts, so severity levels and throttling must be designed, not defaulted.\n\n## Operational Considerations\n\n- **Network design first** — monitoring needs the network segmented enough to be observable (VLANs, zones); a flat network is hard to monitor meaningfully and is a finding in itself.\n- **Encryption blind spots** — encrypted traffic (increasing on modern protocols) hides content from passive sensors; the response is to monitor the endpoints' behavior (connections, timing) and the plaintext control protocols that remain.\n- **Performance impact** — SPAN ports and taps must handle peak traffic; an oversubscribed monitor drops packets exactly when it matters most.\n- **Data retention** — retain the flow and alert records per the security program (typically 6–12 months) — post-incident forensics depend on them.\n\n## Summary\n\nOT network monitoring gives the plant eyes on its control traffic: passive sensors, protocol-aware analysis, baseline-based anomaly detection, and integration with the incident process. Deploy at zone boundaries, learn the baseline, staff the alert review, and feed the findings into the risk and change processes. The first intrusion that is caught because the monitoring showed \"a laptop joined the control network at 02:13\" pays for the entire program.\n\n## Apply this to your project\n\n- Identify asset owners, permitted communications, operational dependencies, and consequences of losing the function.\n- Test access restrictions and visibility without disrupting plant operations; agree the activity with the OT owner.\n- Validate an offline recovery path and document who can authorize isolation, restoration, and return to service.\n\n[Follow an ASP project guide](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance.\n\n![Engineering review sequence: Inventory → Restrict → Observe → Recover. Keep the recorded evidence with the accepted configuration.](https://wiki.aspotomasyon.com/assets/diagrams/industrial-cybersecurity-review.svg)\n\n*Engineering review sequence: Inventory → Restrict → Observe → Recover. Keep the recorded evidence with the accepted configuration.*\n\n## Primary references and further reading\n\nUse the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.\n\n- [NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security](https://csrc.nist.gov/pubs/sp/800/82/r3/final)\n- [ISA — ISA/IEC 62443 series](https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards)\n\n---\n\nCite the canonical article: https://wiki.aspotomasyon.com/article/ot-network-monitoring (OT Network Monitoring and Anomaly Detection, ASP OTOMASYON, updated 2026-09-13).\n","headings":[{"id":"what-ot-monitoring-must-detect","title":"What OT Monitoring Must Detect"},{"id":"passive-monitoring-architecture","title":"Passive Monitoring Architecture"},{"id":"baseline-then-detect","title":"Baseline, Then Detect"},{"id":"integrating-with-the-security-operations","title":"Integrating with the Security Operations"},{"id":"operational-considerations","title":"Operational Considerations"},{"id":"summary","title":"Summary"},{"id":"apply-this-to-your-project","title":"Apply this to your project"},{"id":"primary-references-and-further-reading","title":"Primary references and further reading"}],"faq":[],"references":[{"name":"NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security","url":"https://csrc.nist.gov/pubs/sp/800/82/r3/final"},{"name":"ISA — ISA/IEC 62443 series","url":"https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards"}],"related":[{"slug":"mitre-attack-for-ics-threat-informed-defense","title":"MITRE ATT&CK for ICS: Using the Matrix for Threat-Informed OT Defense","summary":"ATT&CK for ICS gives OT teams a shared catalog of adversary behavior, so detection and control gaps can be tested against plausible scenarios instead of…","category":{"slug":"industrial-cybersecurity","name":"Industrial Cybersecurity"},"url":"https://wiki.aspotomasyon.com/article/mitre-attack-for-ics-threat-informed-defense","markdown_url":"https://wiki.aspotomasyon.com/article/mitre-attack-for-ics-threat-informed-defense.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/mitre-attack-for-ics-threat-informed-defense","published":"2026-10-11T11:46:21+00:00","modified":"2026-10-11T11:46:21+00:00","reading_minutes":8,"word_count":1676,"image":"https://wiki.aspotomasyon.com/assets/social/mitre-attack-for-ics-threat-informed-defense-dd88cfe7cb9b.png"},{"slug":"industrial-firewalls-ids","title":"Industrial Firewalls and Intrusion Detection Deployment","summary":"Firewalls and intrusion detection are the mechanical core of OT network security: firewalls enforce the zones-and-conduits policy, and IDS/NDR systems watch…","category":{"slug":"industrial-cybersecurity","name":"Industrial Cybersecurity"},"url":"https://wiki.aspotomasyon.com/article/industrial-firewalls-ids","markdown_url":"https://wiki.aspotomasyon.com/article/industrial-firewalls-ids.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/industrial-firewalls-ids","published":"2026-08-11T13:05:24+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":4,"word_count":858,"image":"https://wiki.aspotomasyon.com/assets/social/industrial-firewalls-ids-1621f25dc330.png"},{"slug":"ai-ml-industrial-applications","title":"AI and Machine Learning in Manufacturing: Practical Applications","summary":"Artificial intelligence in manufacturing has moved past the hype cycle into a pragmatic toolset: machine learning models that predict, classify, and optimize…","category":{"slug":"digital-transformation","name":"Digital Transformation"},"url":"https://wiki.aspotomasyon.com/article/ai-ml-industrial-applications","markdown_url":"https://wiki.aspotomasyon.com/article/ai-ml-industrial-applications.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/ai-ml-industrial-applications","published":"2026-08-11T13:05:19+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":4,"word_count":853,"image":"https://wiki.aspotomasyon.com/assets/social/ai-ml-industrial-applications-49eee701cd5e.png"},{"slug":"energy-performance-indicators","title":"Energy Performance Indicators and Baselines (ISO 50006)","summary":"An ISO 50001 energy management system is built on measurement: without a way to quantify energy performance, improvement is an opinion.","category":{"slug":"energy-management-systems","name":"Energy Management Systems"},"url":"https://wiki.aspotomasyon.com/article/energy-performance-indicators","markdown_url":"https://wiki.aspotomasyon.com/article/energy-performance-indicators.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/energy-performance-indicators","published":"2026-08-11T13:05:24+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":4,"word_count":793,"image":"https://wiki.aspotomasyon.com/assets/social/energy-performance-indicators-cb57d09936cf.png"}],"citation":"ASP OTOMASYON. OT Network Monitoring and Anomaly Detection. Updated 2026-09-13. https://wiki.aspotomasyon.com/article/ot-network-monitoring"}}