In our previous posts we discussed the various types of attacks on operational (OT) networks. We’ve also discussed the means of mitigating different types of attacks, with the exception of “In-Field” attacks. In this post we will discuss mitigating In-Field attacks using an Industrial IDS.
We define an In-Field attack as a cyber-attack or a human error that occurred within the local network of a remote site. The attack can assume different forms, or vectors: either one field device attacking another field device, or an on-site technician performing changes to the network beyond the scope of his original task. The importance of this attack vector has recently been on the rise as part of the assessment of the risk in the supply-chain of the utility.
To mitigate an In-Field attack, the operator should use an industrial IDS. The IDS monitors the local network traffic and detects suspicious situations in the behavior of SCADA applications, including:
- Changes in the network topology and traffic sessions
- Validation of policies for maintenance tasks and for M2M sessions
- Signatures for known malware and sensitive SCADA commands
- Model-based anomaly detection in SCADA processes and in traffic flow characteristics.
In order to detect an In-Field Attack, the IDS needs to have copies of all traffic ports that are directly connected to controllers or servers (i.e. ports that do not connect to network-related devices).
IDSs have two main deployments models:
- Distributed Deployment – In this architecture, an IDS instance is deployed in each remote site. A single management application for all the IDSs is installed at the control center, which aggregates the events from all distributed IDSs. The benefit of this model is its simplicity: each IDS can be easily connected to a port-mirror of the local switches, and there is no need to re-engineer the inter-site network to route the mirrored traffic from each site to the central server. The downside of this model is the extra cost for deploying multiple IDS systems.
- Central Deployment – In this architecture, a single instance of the IDS is deployed at a central location. The customer will have to mirror/copy the traffic from the local networks at each remote site to the central IDS. This would probably be done using a Smart Tap, which enables mirroring the traffic from each site and delivering it using tunnels to the central IDS. Such Smart Tap will also act as an agent for the IDS and perform some of the pre-processing of the traffic, to optimize the amount of traffic sent to the central IDS over the inter-site network. In addition, since the tap is a one-way hardware link, traffic can only be delivered from the monitored network to the IDS. This prevents creating a new vulnerability by connecting multiple segregated remote networks to the central site.
To monitor serial devices, the customer can also use the Radiflow Secure Gateway to mirror a serial stream and encapsulate the mirrored flow in IP packets that are sent to the IDS server.
In reality we have noticed that operators with few large sites such as renewable power plants prefer installing IDSs at remote sites, while operators with many small remote sites prefer the installation of the a central IDS with smart taps at each site.
Yehonatan Kfir, CTO, Radiflow