Balancing needs and constraints in ICS organizations
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.
[inject id=’code-47fd23f73a9caecab1e206306adae7f9′]
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.
Using SCADA protocols
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:
Real-life examples
Following are two examples of large infrastructure organizations that have implemented the process of sending security alerts to a central SCADA system:
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.
Harmonizing risk and consequence strategies across IT and OT environments for greater cyber resilience
Strengthening OT Resilience: Protecting Critical Systems in a Rapidly Evolving Threat Environment
Quarterly ICS Security Report 2024 Q3