Clients and Serversgenerate audit records of successful and unsuccessful connection attempts, results of security option negotiations, configuration changes, system changes, user interactions and Session rejections.

OPC UA provides support for security audit trails through two mechanisms.

First, it provides for traceability between Clientand Serveraudit logs. The Clientgenerates an audit log entry for an operation that includes a request. When the Clientissues a service request, it generates an audit log entry and includes the local identifier of the log entry in the request sent to the Server. The Serverlogs requests that it receives and includes the Client’s entry id in its audit log entry. In this fashion, if a security-related problem is detected at the Server, the associated Clientaudit log entry can be located and examined. OPC UA does not require the audit entries to be written to disk, but it does require that they be available. OPC UA provides the capability for Serversto generate Event Notificationsthat report auditable Eventsto Clients capable of processing and logging them. See OPC 10000-4for more details on how services in OPC UA are audited.

Second, OPC UA defines audit parameters to be included in audit records. This promotes consistency across audit logs and in Audit Events. OPC 10000-5defines the data types for these parameters. Other information models may extend the audit definitions. OPC 10000-7defines Profiles which include the ability to generate Audit Eventsand use these parameters, including the Clientaudit record id.

Because the audit logs are used to prove that the system is operating securely, the audit logs themselves should also be secured from unauthorized tampering. If someone without authorization were able to alter or delete log records, this could hide an actual or attempted security breach. Because there are many different ways to generate and store audit logs (e.g. files or database), the mechanisms to secure audit logs are outside the scope of this specification.

In addition, the information in an audit record may contain sensitive or private information, thus the ability to subscribe for Audit Eventsis restricted to appropriate users and/or applications. As an alternative, the fields with sensitive or private information can instead contain an error code indicating access denied for users that do not have appropriate rights.

The clauses 4.14.2, 4.14.3, 4.14.4and 4.14.5illustrate the behaviour of OPC UA Serversand Clients that support Auditing.

Figure 5illustrates the simple case of a Clientcommunicating with a Server.

image008.png

Figure 5– Simple Servers

In this case, OPC Client “A” executes some auditable operation that includes the invocation of an OPC UA service in Server“D”. It writes its own audit log entry, and includes the identifier of that entry in the service request that it submits to the Server.

The Serverreceives the request and creates its own audit log entry for it. This entry is identified by its own audit id and contains its own Auditinginformation. It also includes the name of the Clientthat issued the service request and the Clientaudit entry id received in the request.

Using this information, an auditor can inspect the collection of log entries of the Serverand relate them back to their associated Cliententries.

Figure 6illustrates the case of a Clientaccessing services from an aggregating Server. An aggregating Serveris a Serverthat provides its services by accessing services of other OPC UA Servers, referred to as lower layer-Servers.

image009.png

Figure 6– Aggregating Servers

In this case, each of the Serversreceives requests and creates its own audit log entry for them. Each entry is identified by its own audit id and contains its own Auditinginformation. It also includes the name of the Clientthat issued the service request and the Clientaudit entry id received in the request. The Serverthen passes the audit id of the entry it just created to the next Serverin the chain.

Using this information, an auditor can inspect the Server’s log entries and relate them back to their associated Cliententries.

In most cases, the Serverswill only generate Audit Events, but these Audit Eventswill still contain the same information as the audit log records. In the case of aggregating Servers, a Serverwould also be required to subscribe for Audit Eventsfrom the Serversit is aggregating. In this manner, Server“B” would be able to provide all of the Audit Eventsto Client“A”, including the Eventsgenerated by Server“C” and Server“D”.

Figure 7illustrates the case of a Clientaccessing services from an aggregating Serverthat does not support Auditing.

image010.png

Figure 7– Aggregation with a non-auditing Server

In this case, each of the Serversreceives requests and creates their own audit log entry for them, with the exception of Server“B”, which does not support Auditing. In this case, Server“B” passes the audit id it receives from its Client“A” to the next Server. This creates the required audit chain. Server“B” is not listed as supporting Auditing. In a case where a Serverdoes not support writing audit entries, the entire system may be considered as not supporting Auditing.

In the case of an aggregating Serverthat does not support Auditing, the Serverwould still be required to subscribe for Audit Eventsfrom the Serversit is aggregating. In this manner, Server“B” would be able to provide all of the Audit Eventsto Client“A”, including the event generated by Server“C” and Server“D”, even though it did not generate an Auditevent.

Figure 8illustrates the case of a Clientthat submits a service request to an aggregating Server, and the aggregating service supports that service by submitting multiple service requests to its underlying Servers.

image011.png

Figure 8– Aggregate Server with service distribution

In the case of aggregating Servers, a Serverwould be required to subscribe for Audit Eventsfrom the Serversit is aggregating. In this manner, Server“B” would be able to provide all of the Audit Eventsto Client“A”, including the event generated by Server“C” and Server“D”.