Cyber security monitoring in operational technology environments is not the same problem as cyber security monitoring in IT environments. The tools are different. The protocols are different. The consequences of missing something are different. And most of the monitoring solutions on the market were built for IT environments and adapted for OT, which means they miss things that matter.
The £39.83 cost-per-click on “cyber security monitoring” is the highest in the cybersecurity keyword dataset. That number reflects what organisations are willing to pay to find a solution. It also reflects how serious the problem is for the people searching for it.
This guide explains what cyber security monitoring actually involves, why standard monitoring approaches fail in OT environments, what good looks like, and how protocol-level visibility changes what is possible.
In This Guide
- What Is Cyber Security Monitoring?
- Cyber Security Monitoring in IT vs OT Environments
- Why Cyber Security Monitoring Matters in OT
- Cyber Security Monitoring Techniques
- Monitoring for Protocols and Embedded Systems
- Where Monitoring Fits in a Security Programme
- What Good Monitoring Output Looks Like
- How CyTAL Approaches Cyber Security Monitoring
- Common Questions About Cyber Security Monitoring
What Is Cyber Security Monitoring?
Cyber security monitoring is the continuous observation of systems, networks, and activity to detect threats, anomalies, and security-relevant events. It combines the collection of data from across an environment, the analysis of that data against known threat patterns and baseline behaviour, and the alerting or response that follows when something significant is detected.
The definition sounds straightforward. The practice is not. Effective monitoring requires knowing what normal looks like for a specific environment before anomalous behaviour can be identified. It requires tooling that understands the protocols and communication patterns present in that environment. It requires people who can distinguish genuine threats from operational noise. And it requires a response capability that can act on findings in a way that is proportionate to the risk and appropriate to the operational context.
Most monitoring programmes address some of these requirements well and others inadequately. The gap is usually not in the collection of data. Modern monitoring infrastructure generates large volumes of security-relevant events. The gap is in the analysis: turning that volume of data into a prioritised picture of what actually requires attention, and doing that in a way that reflects the specific characteristics of the environment being monitored rather than applying generic detection rules to every environment regardless of context.
Cyber Security Monitoring in IT vs OT Environments
The difference between cyber security monitoring in IT environments and OT environments is not just a matter of degree. The two environments have fundamentally different characteristics that require fundamentally different monitoring approaches.
IT environments are built around standard protocols, well-understood communication patterns, and systems that were designed with connectivity as a primary feature. Security monitoring tools for IT environments are mature, widely deployed, and built on deep knowledge of the protocols and behaviours they observe. When something anomalous happens in an IT environment, the monitoring infrastructure has a large body of knowledge to draw on in deciding whether it represents a genuine threat.
OT environments use protocols that most IT security monitoring tools do not understand. Modbus, DNP3, IEC 61850, IEC 60870-5-104, DLMS COSEM and similar protocols carry the communications that control physical processes, and the behaviour that is normal for these protocols in an operational context is not captured in IT security monitoring rule sets. A monitoring tool that does not understand the protocol cannot distinguish a legitimate command from a malicious one, a normal device response from an anomalous one, or expected communication patterns from ones that indicate compromise.
The consequence of a missed detection is different too. In an IT environment, a threat that passes undetected through monitoring may result in data theft, ransomware deployment, or operational disruption. In an OT environment, it may result in manipulation of physical processes, damage to equipment, harm to people, or failures in systems that underpin critical services. The bar for monitoring effectiveness in OT environments is higher because the consequences of failure are higher.
Why Cyber Security Monitoring Matters in OT
The security case for monitoring in OT environments is specific and direct. OT environments are increasingly targeted by threat actors who understand that compromising industrial systems produces consequences that IT compromises do not. Nation-state actors targeting critical infrastructure, criminal groups deploying ransomware against industrial operators, and supply chain attacks targeting the software and devices that underpin operational systems are all active threats that monitoring is the primary mechanism for detecting.
The dwell time problem makes monitoring particularly important in these environments. The average time between an attacker gaining access to an environment and that access being detected is measured in weeks or months in many industrial environments. During that time, the attacker is learning the environment, establishing persistence, and positioning for the action they intend to take. Monitoring that detects the early stages of an intrusion, before the attacker has achieved their objective, is the difference between an incident that is contained and one that causes significant harm.
Legacy systems create specific monitoring challenges that make the problem harder. OT environments regularly include devices and systems that cannot run endpoint monitoring agents, that use protocols not supported by standard monitoring tools, and that have communication patterns that were never documented and are not well understood. Monitoring these systems requires passive network observation rather than host-based agents, protocol-aware analysis rather than generic traffic inspection, and baseline development that is specific to the operational environment rather than drawn from generic threat intelligence.
The regulatory dimension reinforces the operational case. The NCSC Cyber Assessment Framework requires operators of essential services to maintain the ability to detect cybersecurity events affecting their operational systems. IEC 62443 requires security monitoring capabilities as part of the system requirements for industrial automation and control systems. Monitoring is not optional for organisations subject to these frameworks. It is a documented compliance requirement.
Cyber Security Monitoring Techniques
Cyber security monitoring in OT environments draws on a range of techniques, and the right combination depends on the specific environment, the protocols in use, and the threats being monitored for.
Network traffic analysis is the foundation of OT monitoring. Because many OT devices cannot run endpoint agents, the network is often the only place where monitoring can observe their behaviour. Passive network monitoring captures traffic without injecting packets or generating load on operational systems, making it appropriate for environments where active scanning or probing would be disruptive. Protocol-aware analysis of that traffic identifies communication patterns, command sequences, and device behaviour that baseline normal operation and flag deviations.
Anomaly detection identifies behaviour that deviates from established baselines without requiring prior knowledge of specific attack signatures. In OT environments where the communication patterns are stable and well-defined, anomaly detection can identify unusual command sequences, unexpected connections between devices, and changes in communication timing or volume that may indicate compromise or manipulation. The effectiveness of anomaly detection depends on the quality of the baseline, which requires a period of observation before meaningful detection is possible.
Signature-based detection applies known threat indicators to observed traffic and activity. In OT environments, threat intelligence specific to industrial protocols and systems is available from sources including ICS-CERT advisories, vendor security bulletins, and sector-specific threat intelligence sharing groups. Monitoring that incorporates OT-specific threat intelligence alongside generic IT threat signatures is more effective than monitoring built entirely on IT-focused rule sets.
Log analysis and correlation connects events across multiple systems to identify attack patterns that are not visible in any single source. An authentication failure on a network device, followed by an unusual command sequence on a control system, followed by a change in process parameters, may each appear unremarkable in isolation. In combination they may indicate a coordinated attack. Security information and event management systems that correlate events across OT and IT environments provide visibility into attack patterns that environment-specific monitoring cannot detect.
Monitoring for Protocols and Embedded Systems
Monitoring at the protocol level is where the most significant gaps in OT security monitoring exist, and where the most significant improvements in detection capability are achievable. Understanding what protocol-level monitoring involves and why it matters helps organisations identify whether their current monitoring programme is addressing this part of the attack surface.
Protocol-level monitoring observes the content of industrial protocol communications, not just their presence. Standard network monitoring can identify that a Modbus connection exists between two devices. Protocol-level monitoring can identify what commands are being sent over that connection, whether those commands are within the expected operational range, whether the sequence of commands follows normal operational patterns, and whether the responses from the target device are consistent with normal behaviour. That level of visibility is necessary to detect manipulation of physical processes through legitimate protocol commands, which is one of the most significant and hardest-to-detect attack techniques in OT environments.
Embedded systems present specific monitoring challenges because they often lack the logging and observability capabilities that IT systems provide as a matter of course. A control system component that does not generate logs cannot be monitored through log analysis. A device that communicates only through a proprietary binary protocol cannot be monitored by tools that do not understand that protocol. Monitoring programmes for environments with significant embedded system populations need to account for these constraints and design monitoring approaches that work within them.
The relationship between monitoring and testing is important for organisations trying to understand what their monitoring programme can and cannot detect. Monitoring that has never been tested against realistic attack scenarios may have significant blind spots that only become apparent when an actual attack occurs. Protocol-level testing using tools like ProtoCrawler can identify the attack scenarios that monitoring needs to detect, providing a basis for validating monitoring coverage and improving detection capability before those scenarios are used by real attackers.
Where Monitoring Fits in a Security Programme
Cyber security monitoring is most effective when it is treated as one component of a broader security programme rather than as a standalone solution. The relationship between monitoring and the other elements of the security programme determines whether monitoring investment produces genuine improvement in security posture or generates activity without reducing risk.
Risk assessment provides the context that makes monitoring output actionable. A monitoring programme that detects anomalous activity needs to understand whether that activity represents a genuine threat to critical assets or a low-priority event in a peripheral system. That judgement depends on knowing where the significant risks sit, which requires a risk assessment that informs the monitoring programme rather than following it.
Vulnerability management connects monitoring to the remediation of the weaknesses that monitoring exists to detect exploitation of. Vulnerabilities identified through monitoring activity need to feed into a remediation process. Vulnerabilities identified through security testing need to be reflected in monitoring rules that would detect their exploitation. Monitoring and vulnerability management that operate independently of each other produce a programme where threats are detected but not addressed, or addressed but not monitored.
Incident response capability determines what happens when monitoring detects something significant. A monitoring programme without a defined and tested response capability produces alerts that are not acted on, or are acted on slowly enough that the attacker achieves their objective before containment occurs. In OT environments where the consequences of a successful attack extend to physical harm and operational disruption, the response capability needs to be specifically designed for the operational context, not adapted from an IT incident response playbook.
What Good Monitoring Output Looks Like
The output of a cyber security monitoring programme is the mechanism by which it demonstrates value and provides the organisation with the information needed to make security decisions. Poor monitoring output is one of the most common sources of dissatisfaction with security programmes, and it is something that can be evaluated and improved without changing the underlying monitoring infrastructure.
Alert quality matters more than alert volume. A monitoring programme that generates hundreds of alerts per day, most of which represent false positives or low-priority events, does not improve security posture. It creates alert fatigue that reduces the probability of genuine threats being identified and acted on. Good monitoring output is prioritised, contextualised, and filtered to present the events that actually require attention rather than everything the monitoring infrastructure can detect.
Detection coverage reporting tells the organisation what the monitoring programme can and cannot see. A monitoring programme with significant blind spots that are not documented creates a false sense of security. Good monitoring output includes regular assessment of detection coverage against the threat scenarios relevant to the environment, identifying where coverage is adequate and where it has gaps that need to be addressed.
Trend analysis over time distinguishes a monitoring programme that is improving security posture from one that is maintaining a steady state. Are the same event types recurring? Are specific systems generating disproportionate alert volumes that suggest unaddressed vulnerabilities? Is the threat landscape changing in ways that the current monitoring rule set does not address? These questions require longitudinal analysis that looks across reporting periods rather than within them.
For compliance purposes, monitoring output needs to be structured and specific. The NCSC Cyber Assessment Framework requires evidence that cybersecurity events affecting operational systems can be detected. IEC 62443 requires documented monitoring capabilities with a defined scope. Monitoring reports that document activity without mapping it to specific framework requirements do not satisfy compliance obligations.
How CyTAL Approaches Cyber Security Monitoring
Our approach to monitoring starts from the protocols and communication patterns present in the specific environment being monitored, not from a standard monitoring rule set applied to every customer. Where the environment uses industrial or embedded protocols, the monitoring approach is built around protocol-level visibility that standard IT monitoring tools do not provide.
ProtoCrawler supports monitoring programme development by identifying the attack scenarios that monitoring needs to detect. By systematically testing protocol implementations for the vulnerabilities and unexpected behaviours that an attacker could exploit, it provides the basis for monitoring rules that detect those specific scenarios rather than relying on generic anomaly detection that may miss protocol-level attacks entirely. The output maps directly to IEC 62443 (link to: https://cytal.co.uk/iec-62443/) compliance requirements for monitoring and detection capability.
If you need to assess or improve the monitoring capability for an OT or ICS environment, get in touch to discuss your specific requirements or book a ProtoCrawler demo to see how protocol-level testing supports monitoring programme development.
Common Questions About Cyber Security Monitoring
What is the difference between cyber security monitoring and a security operations centre?
A security operations centre is the team and infrastructure that delivers cyber security monitoring at scale. It combines the monitoring tools, the analysts who review alerts and investigate events, the processes that govern how events are escalated and responded to, and the management oversight that ensures the programme is working effectively. Cyber security monitoring describes the activity. A security operations centre is one way of delivering it, typically used by larger organisations or through managed security operations (link to: https://cytal.co.uk/services/evaluate-a-product-or-system/) providers who operate a shared SOC on behalf of multiple customers.
Can standard IT monitoring tools be used in OT environments?
Some can, with significant limitations. Standard IT monitoring tools can observe network traffic and identify connections between systems, but they cannot analyse the content of industrial protocol communications in a way that distinguishes normal operational behaviour from anomalous or malicious activity. They also cannot monitor devices that do not support standard logging or agent-based monitoring. Using IT monitoring tools in OT environments without OT-specific additions produces monitoring coverage with significant blind spots in exactly the areas where industrial attackers focus their activity.
How long does it take to establish a useful baseline for anomaly detection?
It depends on the environment and the stability of its operational patterns. OT environments with consistent operational cycles can establish meaningful baselines relatively quickly, typically within weeks of deploying monitoring infrastructure. Environments with more variable operational patterns require longer observation periods before the baseline is stable enough to support reliable anomaly detection. The quality of the baseline directly determines the quality of anomaly detection, which is why rushing the baselining phase produces high false positive rates that undermine the monitoring programme.
What should be monitored in an OT environment?
Network traffic between OT devices and systems, including the content of industrial protocol communications where protocol-aware monitoring is available. Connections between the OT network and IT networks or external systems, which represent the paths through which most external attackers reach OT environments. Authentication events on systems that control access to operational infrastructure. Changes to device configuration and firmware, which may indicate compromise or unauthorised modification. And process data where deviations from expected operational parameters may indicate manipulation of physical processes through legitimate protocol commands.
How does cyber security monitoring relate to IEC 62443 compliance?
IEC 62443 requires security monitoring capabilities as part of the system requirements for industrial automation and control systems. Specifically, it requires the ability to detect and log security-relevant events, maintain audit logs that support incident investigation, and provide the evidence that compliance assessments require. A monitoring programme that generates activity without producing structured, auditable output mapped to specific IEC 62443 requirements does not satisfy the standard’s compliance obligations, regardless of how much it detects.