Clients and Servers generate 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 Client and Server audit logs. The Client generates an audit log entry for an operation that includes a request. When the Client issues 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 Server logs 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 Client audit 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 Servers to generate Event Notifications that report auditable Events to Clients capable of processing and logging them. See OPC 10000-4 for 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-5 defines the data types for these parameters. Other information models may extend the audit definitions. OPC 10000-7 defines Profiles which include the ability to generate Audit Events and use these parameters, including the Client audit 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 Events is 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.4 and 4.14.5 illustrate the behaviour of OPC UA Servers and Clients that support Auditing.
Figure 5 illustrates the simple case of a Client communicating with a Server.
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 Server receives the request and creates its own audit log entry for it. This entry is identified by its own audit id and contains its own Auditing information. It also includes the name of the Client that issued the service request and the Client audit entry id received in the request.
Using this information, an auditor can inspect the collection of log entries of the Server and relate them back to their associated Client entries.
Figure 6 illustrates the case of a Client accessing services from an aggregating Server. An aggregating Server is a Server that provides its services by accessing services of other OPC UA Servers, referred to as lower layer-Servers.
Figure 6 – Aggregating Servers
In this case, each of the Servers receives requests and creates its own audit log entry for them. Each entry is identified by its own audit id and contains its own Auditing information. It also includes the name of the Client that issued the service request and the Client audit entry id received in the request. The Server then passes the audit id of the entry it just created to the next Server in the chain.
Using this information, an auditor can inspect the Server’s log entries and relate them back to their associated Client entries.
In most cases, the Servers will only generate Audit Events, but these Audit Events will still contain the same information as the audit log records. In the case of aggregating Servers, a Server would also be required to subscribe for Audit Events from the Servers it is aggregating. In this manner, Server “B” would be able to provide all of the Audit Events to Client “A”, including the Events generated by Server “C” and Server “D”.
Figure 7 illustrates the case of a Client accessing services from an aggregating Server that does not support Auditing.
Figure 7 – Aggregation with a non-auditing Server
In this case, each of the Servers receives 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 Server does not support writing audit entries, the entire system may be considered as not supporting Auditing.
In the case of an aggregating Server that does not support Auditing, the Server would still be required to subscribe for Audit Events from the Servers it is aggregating. In this manner, Server “B” would be able to provide all of the Audit Events to Client “A”, including the event generated by Server “C” and Server “D”, even though it did not generate an Audit event.
Figure 8 illustrates the case of a Client that submits a service request to an aggregating Server, and the aggregating service supports that service by submitting multiple service requests to its underlying Servers.
Figure 8 – Aggregate Server with service distribution
In the case of aggregating Servers, a Server would be required to subscribe for Audit Events from the Servers it is aggregating. In this manner, Server “B” would be able to provide all of the Audit Events to Client “A”, including the event generated by Server “C” and Server “D”.