The Global Discovery Server (GDS) is a special OPC UA Server that provides Discovery Services for a plant or entire system. In addition, This Server can include CertificateManager, KeyCredentialService and AuthorizationService (defined in OPC 10000-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 CertificateManager
4. Servers can pull certificates from the CertificateManager
5. The CertificateManager 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:

• It is important that Servers register with the Discovery Server they are configured to register with and that Servers do not blindly register with a GDS that the Server has not been configured to register with. Servers have to be aware that a Discovery Server could be a rogue Server.
• A Server registers all endpoints that it provides, ensuring that the list provided by the Discovery Server and the Server match. This ensures that Clients can determine if the Discovery Server provided valid information.
• Clients should be aware of rogue Discovery Servers that could direct them to rogue Servers. Clients can use the TLS server certificate (if available) to verify that the Discovery Server is a Server that they trust and/or ensure that they trust any Server provided by the Discovery Server.
• As described in Part 4, Clients always verify that they trust the Server certificate and that the EndpointUrl matches the HostNames specified in the certificate before it creates a Session with a Server. After it creates a Session, it looks at the EndpointDescriptions returned by the Server and verifies that it used the best security possible and that the Server’s Certificate matches the one that the Client used to connect. The EndpointDescription provided by the Server includes a relative SecurityLevel that is used to determine if the most secure endpoint was used.

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 accepts 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 users with SecurityAdmin Role or comparable access rights. Furthermore, the list of Clients that are allowed to access management functionality can 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 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 SecureChannel 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 (see SecurityLevel in OPC 10000-4).