Connection to customer system via OPC UA

[lurifax1]

Hi.
We have several automation systems on a plant which runs on different PLC’s. We also have a topside network system that shows all the necessary information in a control room and for remote operations.

There are some other automation systems on the plant, and they want us to open up a connection to their network via OPC UA.
Do you know what the preferred way of doing this is? We use codesys complient PLC’s which support OPC directly. So in theory the customer could have direct connection to the PLC’s ethernet port and read/write data via OPC.

For security reasons I’m sceptical to this, so I was wondering if theres a better way to give access to the PLC data.
The PLC’s are already connected to a server on the plant, maybe we could set up an OPC server there and add some security for the connection. I’ve seen some python /c++ libraries for OPC server/clients and already tested some of the functionalities, but I wanted to check here if there are some well proven and safe ways of doing this.

 

[JesperMP]

OPC UA support the use of certificates between the server and the clients.
That is the way things are going (like it or not). There is a new EU directive NIS2 that pretty much makes it mandatory to use certificates for all kinds of access to machines and plants.

You can also setup a dedicated ethernet port on the PLCs only for connection these to the higher level network. This is more safe, but also means you don't have practical issues with merging different networks on many machines, i.e. device names and IP addresses.

I think it is actually safer to have the OPC UA server on the machine than on the higher level side.

 

[JesperMP]

https://blog.softwaretoolbox.com/understanding-opc-ua-certificates-and-authorities

 

[lurifax1]

Thank you for the reply. So you think it is more practical to have the OPC communication via our higher level network and then to the other vendors, but it is more secure to have to OPC UA server on the machine (PLC) that directly communicate to an external system as well as our higher level network? (just so I'm sure i understand you correctly).

My worry about having a connection directly to the PLC was if some external factor crashed the PLC (DoS or something in that order) because of the direct connection to the PLC CPU. And maybe it was safer to have that connection via our higher level side with some form of added security.

 

[JesperMP]

The new NIS2 EU directive says there has to be end-to-end encryption.
Also, the security must not be a single layer.
To isolate the networks as you describe is not a bad idea, but you cannot let everything on the inner network be unprotected.
This is a huge topic and I am in no way an expert, but it is going to affect us all and we have to deal with it.

I am today leaning towards a dedicated network port on all devices that must be connected to a higher level network.
1. it provides the required end-to-end encryption and certificates.
2. it is flexible because the single dedicated network port can be adapted to the higher level network without affecting the machines own network.
3. it is simple. NAT routers and the like gets complicated real quick.

 

[lurifax1]

OK, I understand. I will take what you've said into consideration when we decide how we are going to go about the communication.

If we allow direct connection to our PLC's from other vendors. Do you think it serves a purpose to connect via something like this: (https://www.phoenixcontact.com/en-no/products/router-fl-mguard-2102-1357828 ?

 

[JesperMP]

These VPN routers are usually used when the plant cannot otherwise provide a VPN connection - because there is no IT or there is an IT but they are not competent.
For an OEM machine manufacturer it is an advantage that the same VPN solution is used for all customers. We as OEM have 1000s of customers, and if we had to deal with different VPNs for each customer, it would un-managable.

 

[lfe]

With the use of certificates you can grant or deny access to each PLC for specific clients, it is based on placing their certificate in the list of trusted certificates in each of the PLCs to which access is granted

... There is a new EU directive NIS2 that pretty much makes it mandatory to use certificates for all kinds of access to machines and plants....

this will leave OPC UA as the only protocol to use ...

 

[JesperMP]

[..]this will leave OPC UA as the only protocol to use ...

Siemens offers TLS certificates between their PLCs and HMIs for the HMI connection, i.e. not OPC UA based.
This is because of the new EU directive. Siemens is merely acting on it.
I am guessing that all the other HMI/PLC/SCADA vendors will have to follow suit pretty soon. Otherwise they can close shop.

I think this will hit pretty hard, and most people are oblivious.
There will be inspections and fines will be handed out to plants that are found not in compliance.
https://nis2directive.eu/nis2-fines/
I have been to a seminar regarding NIS2. NIS2 is only one of several security standards that are on the way.