Some thoughts on SCADA security

 

Introduction

This page has some thoughts on the security issues of SCADA or telemetry systems, particularily in relation to carrying SCADA or telemetry traffic on corporate networks.

 

SCADA, Telemetry, and firewalls

The increasing use of corporate WAN`s or LAN`s to carry SCADA and telemetry data has an impact on the security of both the corporate network and the SCADA or telemetry data.

Network firewalls are a small but significant part of network security, so I think it worth thinking about them, and how SCADA or telemetry data affects them.

The following points are my thoughts on this, based on both digging and previous experience.

First off - it seems that the various SCADA protocols that I have listed above all run above TCP/IP - so it would appear that they can be treated like other protocols that run over TCP/IP.

IANA has registered port 2404 on TCP and UDP for IEC 60870-5-104, and port 20000 on TCP and UDP for DNP3.

I have seen reference on the internet to Modbus/TCP being assigned port 502 - however this is not shown on the IANA website, so I am not sure what the situation is here - IANA have registered "asa-appl-proto" against port 502 - is this Modbus/TCP in disguise ?

However, for DNP3 and for IEC 60870-5-104, it appears that if we write access rules which permit ports 2404 and 20000 through the firewall, then we should get connectivity through the firewall.

But - there may be another problem - many firewalls use stateful packet filtering - in stateful packet filtering, when an application behind the firewall initiates a conversation with a remote host, the firewall takes a note of the destination address and the source port number, and when the remote host replies with the correct address and port number, the firewall permits the packet through the firewall, and sends it to the local host.

But any other packet arriving at the firewall with a different source address or destination port number will be blocked. All of which means that the only packets allowed in through the firewall are packets sent by remote hosts in response to a local host requesting contact.

So if a remote SCADA device is set up to initiate a data exchange ( perhaps for an alarm condition ) rather than getting polled, the firewall would block the incoming data exchange. To get round this would require an access rule that bypasses the stateful packet filtering. But that immediately opens up a door for attackers.

So it would be necessary to move to deep-packet inspection above layer 2, to check if the incoming packet is a legitimate SCADA data packet.

Alternatively, it would be possible to do what some messaging services do, - they continually transmit packets to no-one in particular through the firewall, so that the firewall keeps open a path through the stateful packet filtering. Again, it opens up a door for attackers.

Another problem could be that some firewalls only do stateful packet filtering, they ignore access rules ( newer versions of OpenBSD do this ).

However all this may be irrelevant - because you maybe don`t want the SCADA traffic to go through the firewall, if the firewall is being used to seperate the SCADA network from the rest of the corporate network. In that case, maybe only some of the data should be accessible from the corporate data network. Configuring a network layout and a firewall to work in this way is not trivial, not only from the technical aspect, but also from the aspect of the business need for data versus the safety and security of the SCADA network.

A single web page isn`t going to provide a ready made solution, but some possible avenues to look at include :-

Another possibility is that, instead of having two servers, have just the one server, but have it sitting in its own network zone - ie - it is not on either the corporate network, or on the SCADA network, it has its own network. There are two ways of achieving this :-
 

1 - use a firewall with three ports, instead of the usual two :-

2 - use two firewalls :-

Thinking some more about using two firewalls - I realised that there is another advantage in using two firewalls instead of a single 3-port firewall. We can use two stateful packet filtering firewalls working in opposition to increase our security.

Firewall-1 - between the corporate network and the server network - is orientated so that the corporate network is on the "safe" side, and the server network is on the "unsafe" side.

Firewall-2 - between the SCADA network and the server network - is orientated so that the SCADA network is on the "safe" side, and the server network is on the "unsafe" side.

So an attacker on the corporate network can get access as far as the data network or the data server, but then meets the "outside" of the stateful packet filtering firewall, blocking access to the SCADA network.

It also means that an attacker on the SCADA network can get access as far as the data network or the data server, but then meets the "outside" of the stateful packet filtering firewall, blocking access to the corporate network.

All this of course assumes that the data server is just that - an entirely passive data server - it doesn`t initiate any traffic, it sits and listens for requests for data. Alternatively, it passively accepts data from the SCADA network, it doesn`t go looking for it. However there is a risk in this, as an attacker could feed it false data. This wouldn`t neccessarily put the SCADA network at risk, might it might mean that the pc`s on the corporate network get incorrect data. At present, I`m not sure how you could prevent this. It is the same risk as any other server on the corporate network.

I think that to try and do this with a single 3-port firewall would be very difficult, and I don`t know if it would even be possible, because the firewall might have to maintain two different state tables - I don`t know for sure either way.

Just for clarification, a stateful packet filtering firewall will not stop any viruses or worms that can get themselves onto the protocol that is used to carry the normal legitimate traffic through the firewall. To stop that kind of attack requires a firewall that does application layer filtering - these are still fairly new, and not really in widespread use yet even in the wider IT industry. SCADA protocols haven`t really been considered. There has been some development work done on a Linux kernel that is aware of Modbus/TCP, but I don`t think much has been done on other SCADA protocols. There is quite a strong view amongst some of the Linux kernel developers that application layer filtering should be done at an application level, not at the kernel level.

There must be, potentially, quite a big market out there for SCADA aware application layer firewalls.

All the above are of course just ideas - whether they are useful or useable for any particular set-up I can`t say.

 

Some other security thoughts

Some of the other things related to SCADA or telemetry security that I found whilst digging around on the internet include :-

Again, these are just ideas or possibilities - they may have a place in some systems.

 

 

 

 

 

website design by ron-t

 

website hosting by freevirtualservers.com

 

© 2024   Ron Turner

 

+                                   +  

 

Link to the W3C website.   Link to the W3C website.