The short answer is that the CCOW transactions are not particularly ‘Security Relevant’. The thing that happened before or because of the transaction usually are. Those security relevant events that happen before or after should be recorded as ATNA events. For example it should be the User Authentication application that records that a user was authenticated. The actual CCOW transaction to set the context or to read the context is not that interesting.
Deeper Discussion:
For many other IHE Profiles (e.g XDS, PIX, EUA) we have identified the security audit message that would be appropriate to capture that the transaction happened. This is done now days as part of the Security Cookbook. Where we do a risk assessment to identify reasonable security and privacy controls, including if there is a need for a security audit event to be recorded.
IHE does have a profile that leverages CCOW, The “Patient Synchronized Applications” Profile was written around the same time that “Audit Trails and Node Authentication” Profile was written; but was written before the Security Cookbook. So one can see how it might be possible that IHE simply hasn’t thought about the relationship between PSA and ATNA; or hasn’t fully executed the Security Cookbook. I can’t say that this is not the case, but I don’t think that there would be a strong reason to define the ATNA events for PSA.
Not all transactions are going to be security auditable events, and more important there are far more security auditable events than there are network transactions. Far more security relevant events happen in the normal workflow of an application that have no external transaction. This is something that I have tried to cover multiple times, as many people get a false impression that the only ATNA events are those that are defined by IHE. The main security relevant events that IHE defines are ‘Import’ or ‘Export’ events. This is the reason why XDS was so highly covered with ATNA, as everything about XDS is either an Import or an Export event; and one that is most likely not just to the application but to the organization – hence Cross-Enterprise prefix.
Surveillance:
Another factor is that the IHE ATNA audit message is about Surveillance, not forensics or even debugging. The statement that the CCOW transactions are not security relevant does not mean that there should be no log, but that log is more of a debugging log, something that might be called upon if deeper analysis is needed (forensics).
Who did what when:
As stated above the CCOW transactions are not that interesting, but the events leading up to a context change and the events caused by a context change are very interesting.
- User Authentication: This event should be logged by the application that actually authenticated the user. It is important that this responsibility be here, as it is more important to log failed attempts to authenticate. The failed attempts would never hit the context, so the context changes would not be helpful to detect an attack at the user authentication.
- Patient Selected: The application that is used to select a new patient should be recording that a new patient was selected.
- Patient Changed: All applications that change their display because of the context change likely are showing the user something new, and thus there is a need to record that that new thing is being shown to the user.
- Object Changed: The CCOW specification allows for other objects within the patient record to also be changed and thus synchronized.
It is at this point that a potential gap in the current ATNA specification comes into discussion. There is clear ways to indicate that the user is being shown a patient study, document, order result, or other specific object. There is not a clear way to say to simply say the patient identity has changed and that no-specific information is being shown.
If nothing in particular was shown to the user, was there really any security relevant event? This might simply be the case, that one doesn't record an ATNA event until there is some data shown to the user.
Conclusion:
I don't think I have come up with a gap or a reason why CCOW events should be recorded using IHE ATNA. That is not to say that they can't be, just that I don't see a compelling reason to specify it.
References:
- IHE - Privacy and Security Profiles - Audit Trail and Node Authentication
- Accountability using ATNA Audit Controls
- ATNA and Accounting of Disclosures
- ATNA audit log recording of Query transactions
- How granular does an EHR Security Audit Log need to be?
- Document Submission: Audit requirements under error conditions
- ATNA + SYSLOG is good enough
John
ReplyDeleteIn my experience, the default view following a context switch is almost always enough to make it very clear to the user which patient that they've "switched to", and so can be expected to include information that is likely to need protection.
Also, a context switch in itself strongly indicates that the user is "looking at" the contextual patient data, regardless of whether it is clinical, demographic, or whatever the specific application shows by default on the screen.
So if a user is rapidly context switching between "Britney Spears", "Mitt Romney" and "Joe Namath" (say to collect address, phone number, or birth date information), then logging those context switches alone may be useful in exposing a data breach.
That might be taken into consideration when deciding if a context switch is "interesting" from a security perspective.
Fantastic analysis. I don't disagree that the context switch is important. What I am asking is if the context switch alone should be auditable. Given, as you point out, that the applications will do their own audit log of the data they show, thus a more descriptive audit is likely to happen at the application level.
DeleteI'd say that my point was that logging (for the purposes of auditing) context switches alone would be a reliable way to detect a pattern of "bad behavior" on the part of a user.
DeleteWhether or not that's a concern of any particular standard, I'll defer to you on.