Stream: Da Vinci PAS
Topic: Audit Logging
Benjamin Langley (Sep 30 2020 at 20:38):
Can anyone here help me out with a question about Audit logging for a PAS implementation. Following the HRex guide mutually authenticated TLS is an option for PAS. Does this certify the client IP Address or just the client certificate. In the AuditEvent.agent.network I don't see a type for any data included in the certificate. I can populate the IP Address but this can easily be spoofed. Has anyone else ran into this or know how to provide accurate audit logging for MA TLS?
John Moehrke (Sep 30 2020 at 21:07):
the AuditEvent.agent.network.address would be best to hold the hostname, the IP numeric value is less useful (especially in a NAT environment). Tied to this one should use BCP195 guidance which would force server-name-indication validation. Thus there is a strong relationship between the hostname you tried to connect to with the hostname declared in the certificate that was presented and authenticated. Thus it is really a set of steps that gives you the assurance, not just one string.
John Moehrke (Sep 30 2020 at 21:07):
see BCP195 - https://tools.ietf.org/html/bcp195
Benjamin Langley (Oct 02 2020 at 12:44):
Thanks @John Moehrke - is the client hostname more reliable than the IP? If they access via a web client won't the hostname be null?
John Moehrke (Oct 02 2020 at 13:41):
Correct observation. The guidance given was more on "Server Name Indication", which is intended to make sure that the server you got connected to was the intended server. The client is much less reliant on hostnames, but still has the problem of NAT. Are you using OAuth, or mutual-auth-TLS? In the case of OAuth, you would be better to record the client_id; as that is what is authenticated. The machine IP address is much less important.
John Moehrke (Oct 02 2020 at 13:45):
hmm, well, the codes allowed don't really have a good code for client_id.. might need to think about a CR to either expand and/or relax that binding.
John Moehrke (Oct 02 2020 at 13:47):
Note that the authentication step would be recorded as one auditEvent, where the transaction details would be recorded as a second event. Might be too focused on including in one AuditEvent the transaction details and the details of the authentication... Good discussion
Benjamin Langley (Oct 02 2020 at 14:37):
Yes the network types are very restrictive. I'm using mutually authenticated TLS not OAuth. So I will have the client certificate but not a client_id from the authentication. One thought was to use the IP in the network and then put the id in the altId field and the certificate CN in the name
John Moehrke (Oct 02 2020 at 16:21):
so the successful TLS authentication should generate a standalone AuditEvent. This is most true of TLS authentication failures. Sometimes the successful authentications are repressed as they would be very noisy. The TLS driven AuditEvent can be more expressive. IHE has not defined an AuditEvent pattern for this TLS authentication as often this event is handled fully within general purpose IT layers and thus difficult to catch and duplicate in a healthcare specific audit log. Thus expected when this level of detail is needed, the system logs will be inspected.
The AuditEvents from things that happen next (e.g. like a REST operation) would be a different AuditEvent. What is important is using the .network consistently between these two AuditEvents (or between how the AuditEvent looks and how the system logs for TLS look).
Last updated: Apr 12 2022 at 19:14 UTC
