Errata exists for this version of the document.

Auditing is a requirement in many systems. It provides a means of tracking activities that occur as part of normal operation of the system. It also provides a means of tracking abnormal behaviour. It is also a requirement from a security standpoint. For more information on the security aspects of auditing, see OPC 10000-2. This sub-clause describes what is expected of an OPC UA Server and Client with respect to auditing and it details the audit requirements for each service set. Auditing can be accomplished using one or both of the following methods:

1. The OPC UA Application that generates the audit event can log the audit entry in a log file or other storage location;
2. The OPC UA Server that generates the audit event can publish the audit event using the OPC UA event mechanism. This allows an external OPC UA Client to subscribe to and log the audit entries to a log file or other storage location.

Each OPC UA Service request contains a string parameter that is used to carry an audit record id. A Client or any Server operating as a Client, such as an aggregating Server, can create a local audit log entry for a request that it submits. This parameter allows this Client to pass the identifier for this entry with the request. If this Server also maintains an audit log, it should include this id in its audit log entry that it writes. When this log is examined and that entry is found, the examiner will be able to relate it directly to the audit log entry created by the Client. This capability allows for traceability across audit logs within a system.

A Server that maintains an audit log shall provide the audit log entries via Event Messages. The AuditEventType and its sub-types are defined in OPC 10000-3. An audit Event Message also includes the audit record Id. The details of the AuditEventType and its subtypes are defined in OPC 10000-5. A Server that is an aggregating Server that supports auditing shall also subscribe for audit events for all of the Servers that it is aggregating (assuming they provide auditing). The combined stream should be available from the aggregating Server.

This Service Set can be separated into two groups: Services that are called by OPC UA Clients and Services that are invoked by OPC UA Servers. The FindServers and GetEndpoints Services that are called by OPC UA Clients may generate audit entries for failed Service invocations. The RegisterServer Service that is invoked by OPC UA Servers shall generate audit entries for all new registrations and for failed Service invocations. These audit entries shall include the Server URI, Server names, Discovery URIs and isOnline status. Audit entries should not be generated for RegisterServer invocation that does not cause changes to the registered Servers.

All Services in this Service Set for Servers that support auditing may generate audit entries and shall generate audit Events for failed service invocations and for successful invocation of the OpenSecureChannel and CloseSecureChannel Services. The Client generated audit entries should be setup prior to the actual call, allowing the correct audit record Id to be provided. The OpenSecureChannel Service shall generate an audit Event of type AuditOpenSecureChannelEventType or a subtype of it for the requestType ISSUE_0. Audit Events for the requestType RENEW_1 are only created if the renew fails. The CloseSecureChannel service shall generate an audit Event of type AuditChannelEventType or a subtype of it. Both of these Event types are subtypes of the AuditChannelEventType. See OPC 10000-5 for the detailed assignment of the SourceNode, the SourceName and additional parameters. For the failure cases the Message for Events of this type should include a description of why the service failed. This description should be more detailed than what was returned to the client. From a security point of view a Client only needs to know that it failed, but from an Auditing point of view the exact details of the failure need to be known. In the case of Certificate validation errors the description should include the audit EventId of the specific AuditCertificateEventType that was generated to report the Certificate error. The AuditCertificateEventType shall also contain the detailed Certificate validation error. The additional parameters should include the details of the request. It is understood that these events may be generated by the underlying Communication Stacks in many cases, but they shall be made available to the Server and the Server shall report them.

All Services in this Service Set for Servers that support auditing may generate audit entries and shall generate audit Events for both successful and failed Service invocations. These Services shall generate an audit Event of type AuditSessionEventType or a subtype of it. In particular, they shall generate the base EventType or the appropriate subtype, depending on the service that was invoked. The CreateSession service shall generate AuditCreateSessionEventType events or sub-types of it. The ActivateSession service shall generate AuditActivateSessionEventType events or subtypes of it. When the ActivateSession Service is called to change the user identity then the Server shall generate AuditActivateSessionEventType events or subtypes of it. The CloseSession service shall generate AuditSessionEventType events or subtypes of it. It shall always be generated if a Session is terminated like Session timeout expiration or Server shutdown. The SourceName for Events of this type shall be “Session/Timeout” for a Session timeout, “Session/CloseSession” for a CloseSession Service call and “Session/Terminated” for all other cases. See OPC 10000-5 for the detailed assignment of the SourceNode, the SourceName and additional parameters. For the failure case the Message for Events of this type should include a description of why the Service failed. The additional parameters should include the details of the request.

This Service Set shall also generate additional audit events in the cases when Certificate validation errors occur. These audit Events are generated in addition to the AuditSessionEventType Events. See OPC 10000-3 for the definition of AuditCertificateEventType and its subtypes.

For Clients, that support auditing, accessing the services in the Session Service Set shall generate audit entries for both successful and failed invocations of the Service. These audit entries should be setup prior to the actual Service invocation, allowing the invocation to contain the correct audit record id.

All Services in this Service Set for Servers that support auditing may generate audit entries and shall generate audit Events for both successful and failed Service invocations. These Services shall generate an audit Event of type AuditNodeManagementEventType or subtypes of it. See OPC 10000-5 for the detailed assignment of the SourceNode, the SourceName and additional parameters. For the failure case, the Message for Events of this type should include a description of why the service failed. The additional parameters should include the details of the request.

For Clients that support auditing, accessing the Services in the NodeManagement Service Set shall generate audit entries for both successful and failed invocations of the Service. All audit entries should be setup prior to the actual Service invocation, allowing the invocation to contain the correct audit record id.

The Write or HistoryUpdate Services in this Service Set for Servers that support auditing may generate audit entries and shall generate audit Events for both successful and failed Service invocations. These Services shall generate an audit Event of type AuditUpdateEventType or subtypes of it. In particular, the Write Service shall generate an audit event of type AuditWriteUpdateEventType or a subtype of it. The HistoryUpdate Service shall generate an audit Event of type AuditHistoryUpdateEventType or a subtype of it. Three subtypes of AuditHistoryUpdateEventType are defined as AuditHistoryEventUpdateEventType, AuditHistoryValueUpdateEventType and AuditHistoryDeleteEventType. The subtype depends on the type of operation being performed, historical event update, historical data value update or a historical delete. See OPC 10000-5 for the detailed assignment of the SourceNode, the SourceName and additional parameters. For the failure case the Message for Events of this type should include a description of why the Service failed. The additional parameters should include the details of the request.

The Read and HistoryRead Services may generate audit entries and audit Events for failed Service invocations. These Services should generate an audit Event of type AuditEventType or a subtype of it. See OPC 10000-5 for the detailed assignment of the SourceNode, SourceName and additional parameters. The Message for Events of this type should include a description of why the Service failed.

For Clients that support auditing, accessing the Write or HistoryUpdate services in the Attribute Service Set shall generate audit entries for both successful and failed invocations of the Service. Invocations of the other Services in this Service Set may generate audit entries. All audit entries should be setup prior to the actual Service invocation, allowing the invocation to contain the correct audit record id.

All Services in this Service Set for Servers that support auditing may generate audit entries and shall generate audit Events for both successful and failed service invocations if the invocation modifies the AddressSpace, writes a value or modifies the state of the system (alarm acknowledge, batch sequencing or other system changes). These method calls shall generate an audit Event of type AuditUpdateMethodEventType or subtypes of it. Methods that do not modify the AddressSpace, write values or modify the state of the system may generate events. See OPC 10000-5 for the detailed assignment of the SourceNode, SourceName and additional parameters.

For Clients that support auditing, accessing the Method Service Set shall generate audit entries for both successful and failed invocations of the Service, if the invocation modifies the AddressSpace, writes a value or modifies the state of the system (alarm acknowledge, batch sequencing or other system changes). Invocations of the other Methods may generate audit entries. All audit entries should be setup prior to the actual Service invocation, allowing the invocation to contain the correct audit record id.

All of the Services in these four Service Sets only provide the Client with information, with the exception of the TransferSubscriptions Service in the Subscription Service Set. In general, these services will not generate audit entries or audit Event Messages. The TransferSubscriptions Service shall generate an audit Event of type AuditSessionEventType or subtypes of it for both successful and failed Service invocations. See OPC 10000-5 for the detailed assignment of the SourceNode, the SourceName and additional parameters. For the failure case, the Message for Events of this type should include a description of why the service failed.

For Clients that support auditing, accessing the TransferSubscriptions Service in the Subscription Service Set shall generate audit entries for both successful and failed invocations of the Service. Invocations of the other Services in this Service Set do not require audit entries. All audit entries should be setup prior to the actual Service invocation, allowing the invocation to contain the correct audit record id.