In the process of devising a cybersecurity protection project for an OT network, operators typically need to reconcile between numerous constraints and influencers , to facilitate and simplify the project and reduce expenses, all while deriving the most benefits out of the cybersecurity system.

The most popular initial cyber security measure deployed in OT networks is a passive intrusion detection system (IDS) that monitors the SCADA system for anomalies. The IDS typically communicates with a SIEM which generates an additional monitoring post on top of the SCADA system, already in-place in such OT networks.

In effect, the operational plane and the security management plane are completely separate and incompatible. In addition, the operators who monitor and manage them typically have vastly different skillsets and knowledge. It’s a sub-optimal situation when a SCADA operator is asked to monitor incoming alerts from both systems. He has to have one eye on the security console, and the other eye on the operational console. Operators prefer to have one unified console where they can perform their monitoring and get all their alerts in one place, and ideally this should be the SCADA system where they do their core business.

Trying to unify them will face a technical challenge as the security systems convey their information using IT protocols such as Syslog and REST API while on the other hand, the control plane that controls the operational devices – the PLCs, IEDs, RTUs and so on – communicates with the SCADA control center using protocols like CIP (Common Industrial Protocol), Modbus, DNP3, etc.

There’s another issue having to do with receiving security alerts from IDS servers deployed in remote locations. Security systems typically communicate over TCP/IP networks. However, many industrial field locations lack IP connectivity, either because it’s not feasible, or is inconvenient, or because extending an IP connection to every industrial control location would cause a security risk. This leaves no way to convey security information over IP from remote sites to a central site.

One way to address both issues – i.e., the need for a unified central console, as well as the need to collect security alerts from remote sites without IP connectivity – is to use SCADA protocols to communicate the security alerts unified with the SCADA control plane. In this case, the IDS communicates as if it were any other industrial control device and can be integrated into the operational view of the SCADA system. For remote sites such as sub-stations the IDS can report to the sub-station RTU like all local IEDs and the RTU will integrate the cyber health status into the overall sub-station status report.

For example, the Radiflow iSID Industrial Intrusion Detection System for SCADA networks has this capability sending its alerts and security information over Modbus and DNP3.

There are multiple benefits to this approach:

  • No need for the SCADA operator to split his or her attention between two disparate consoles: all alarms are displayed in a single location in the HMI.
  • No need for special skills to read the security alerts, which are communicated in a manner the SCADA operator already understands.
  • The operator can keep using the familiar HMI to control the IDS (e.g. to change a behavior or to activate analytics.) Usage of the HMI is very simple and straightforward.
  • All remote or field locations can be monitored for malicious cyber activity, which is a critical objective in any effective cybersecurity program. The lack of an IP connection at a field location won’t exclude that site from security monitoring.

Following are two examples of large infrastructure organizations that have implemented the process of sending security alerts to a central SCADA system:

  • The first case involves a large-scale power distribution utility. Each of the utility’s substations is equipped with an RTU that monitors all the local IEDs with minimal external communication. At each such site, a Radiflow iSID IDS is installed to monitor local traffic. The iSID’s DNP3 northbound interface is connected to the local RTU just like any other IED. It reports cyber events using analog values denoting the event type, severity and other information. This implementation has enabled the utility to embed a distributed IDS within its existing SCADA architecture.
  • The second case SCADA involves a vendor for transportation systems: the vendor implemented an iSID Modbus northbound interface to integrate its cyber health information into the SCADA view of the OT network. The Modbus interface is used to present the SCADA system with the cyber-alarms detected by iSID without the need to develop a new interface.

In both cases, the customer organizations were able to add cybersecurity protections in their SCADA networks using existing OT infrastructures and protocols. This ease of deployment, coupled with the benefits outlined above, will make this approach an essential choice for industrial owners and operators who want to be proactive about monitoring for and protecting against cyber-attacks.

For additional information and a demonstration of the iSID-SCADA integration please visit:

Follow Radiflow at