OPC UA provides a number of services that do not require security to access. These services require special consideration from a security point of view. These services provide capabilities that allow clients to discover servers and connect to them. The Discovery services are available as local services or global services and can be multicast.

OPC UA can be configured to support discovery in multiple manners. One of the options is a multi-cast discovery. In this type of Discovery, Servers announce themselves on a subnet when they start. Application machines or an actual application can listen and build a list of the available servers.

Multicast DNS operations are insecure because of their very nature; they allow rogue servers to broadcast their presence or impersonate another host or server. Risks from Rogue Servers can be minimized if OPC UA security is enabled and all applications use certificate TrustLists to control access. Also, Clients should cache connection information, minimizing the lookup of Server information. However, even if you use UA security, multicast DNS should be disabled in environments where an attacker can easily access the network.

Applications (or discovery servers) are built to ensure that they cannot be overloaded or brought down by high broadcast rates on the multi-cast discovery channel or by too large a list of server applications.

The Global Discovery Server (GDS) is a special OPC UA Server that provides Discovery services for a plant or entire system. In addition, it can provide certificate management functionality (see Part 12)

There are multiple methods of accessing a GDS:

  1. Servers can register with the Discovery Server
  2. Clients can query the GDS for available Servers
  3. Clients can pull certificates from the GDS
  4. Servers can pull certificates from the GDS
  5. The GDS can push certificates to a Server
  6. The GDS can access other discovery Servers to build a list of available Servers.

Several types of threats need to be discussed with regard to the available access methods:

Threats where a rogue GDS is in a system.

Threats against the GDS, including the presence of rogue Clients or Servers

Threats against the certificate management functionality provided by a GDS.

The following guidelines are important to remember when dealing with a GDS:

As described in Part 4, the FindServersOnNetwork Service can be used without security and is therefore vulnerable to denial of service (DOS) attacks. A Discovery Server should minimize the amount of processing required to send the response for this Service. This can be achieved by preparing the result in advance.

The GDS only accept Server registrations from Servers that are trusted or have appropriate administrative access rights. This will help ensure that a rogue Server does not become registered with a GDS.

A GDS, that also provides certificate management, supports User Access security as described in Part 12. This includes restricting all certificate management functionality to administrators. Furthermore, the list of Clients that are allowed to access management functionality may be limited.

Certificate management includes a provisioning phase and run time phase. The provisioning phase is when the GDS is providing initial certificate(s) to Clients or Servers that are just entering the system. The runtime phase is the day to day operation of system and includes providing updated CRLs, certificate renewals and updated TrustLists.

The provisioning of systems is inherently not secure, but can be very useful in providing a greatly simplified deployment of a complex system. Provisioning in a GDS is not enabled by default, but requires an administrative action to enable. It is also recommended that the provisioning feature, when enabled, will only stay enabled for a limited time.

The runtime phase of GDS certificate operations can be performed in a very secure manner, since all Servers and Clients already have certificates to ensure a secure connection. For the push model of certificate management, the GDS establishes a secure channel using the highest security level available in the target Server. It does not provide updated CRLs, Certificates or TrustLists via an endpoint that has a lower security level than the security level of the updates. For example, if a 4096 certificate is to be updated it cannot be updated using a 2048 channel, but a 2048 certificate can be updated using a 4096 channel. If a new higher-level certificate needs to be deployed, it is handled in the same manner as the provisioning of a new server.