Securing UMAS

The Unified Messaging Application Services is a protocol developed by Schneider for the configuration of their PLC.

MODBUS protocol reserves some function codes for particular or future use, and UMAS uses one of these codes (90) to identify it's messages. 

The excellent idea behind it is that if a PLC supports UMAS, it will manage the code 90, and it will interpret UMAS commands correctly. If not, it will simply ignore the packet.

Like Modbus, UMAS is in-clear, and it provides only a reservation mechanism to prevent concurrent connections to a server.

When a client wants to modify the PLC configuration, it will ask for a reservation ID. The server will generate the ID for the client, and the communication will start. All the connections with a different ID will be dropped. The client with the correct ID can modify the PLC even on multiple TCP connections because the ID survives to the end of the TCP session (but it will expire after a global timeout).

This mechanism can be used to introduce a certain level of protection against replay attacks, but as you can guess, we are far from real protection.

It's quite challenging to imagine a specific attack scenario on a protocol in-clear because the list of attacks at your disposition is enormous. We can do a MITM (Man In The Middle) and silently change the configuration in real-time, we can sniff the traffic and try to take ownership of the PLC guessing the reservation ID, or we can wait that the reservation ID expires, asking for a new one.

For this reason, it's imperative to monitor what is happening in the UMAS network to highlight as fast as we can any malicious traffic.

What are the possible solutions?

OT network needs are different in each installation, but segmentation is always the good primary practice. I know that it's quite tricky to do a correct segmentation in a network where you are often not allowed to change the preexistent IP address plan, so it's fundamental to use a technology that can adapt itself to the existing network instead to try to modify the OT infrastructure. Keep in mind that the OT engineer's mantra is "if it works, don't touch it!".

The idea is to isolate the PLC on a dedicated port to do a traffic analysis of all the connections passing "from" and "to" this port. 

Doing this, we don't have to forget that we are in an industrial network, and a pass-on-fail functionality is mandatory. In case of a device failure, we should maintain control of the PLC.

The next step is to implement an IPS coverage of the traffic reaching the PLC. UMAS is used to modify the configuration, so we should monitor the following entry point:

1) Is the source IP address authorized?

2) Is the user sending commands to the PLC an authorized user?

3) Are the commands sent to the PLC in the allowed set of usual commands?

Most industrial protocols don't support authentication, but currently, we have many transparent technologies that can provide this functionality. I don't want to say that we always can or are allowed to use them in the OT network, but if the OT needs are not impacted..., why not?

If you have experience protecting UMAS, don't hesitate to call me, I would like to hear your perspective.