Pages

Saturday, August 29, 2015

Don't disassemble ATNA, what you are looking for is there.

I have been pulled into many discussions that are not taking 'all' of ATNA. They are either just taking the audit logging, or just taking the Secure Communications. Then there are the discussions that are taking the Secure Communications but don't want to take the Client authentication. All of these discussions are missing the point of ATNA, and/or are missing the configurability that is built into ATNA.

Let me explain:

1. ATNA is a grouping of three functions: Security Audit, Secure Communications, and local Access Controls. It is only when you are assured that ALL of these functions exist that you should administratively accept the node/application, and provision a certificate. When I see groups picking and choosing parts, I worry that they might not be understanding the overall. I don’t mind treating them independent as long as this overall design is understood.

2. ATNA Secure Communications (actually Authenticate Node). is not just mutual-authenticated-TLS, although this is the predominant form (The only form for point-to-point protocols like HL7 v2, and DICOM). It also includes SMTP end-to-end security used by Direct. It includes end-to-end security for SOAP using XML-Signature and XML-Encryption….

3. ATNA Secure Communications expects that you will do certificate management (PKI) properly, that is that authenticating a node is more than just proving that the claimed identity is the one authenticated. If you don’t manage your truststore, then you are just authenticating that the identity is the one claimed in the certificate. This is the kind of https used on the internet, one that only looks to prove that the server you connected to is 'most likely' the one you intended. When you don't manage your trust-store, all you can know is that the identity seems 'most likely' to be the one you intended to connect to. This is indeed not very helpful. This is why ATNA has a long discussion around certificate management. Managing the trust-store, usually through removing the hundreds of internet Certificate Authorities (CA), and leaving only CAs that you really trust.

4. Further there is an expectation that you don’t stop at authentication, but also check that the remote node is authorized. The ATNA Secure Communications is just the “Interoperability” way to get authentication done, you still must use that authenticated identity in an authorization decision. If you fail to do this then you will certainly fail to be secure. This fact is true about ALL authentication mechanisms.

5. ATNA Secure Communications can be grouped with a user authentication profile like EUA, XUA, or IUA. This is less clear in the ATNA profile and transaction, as the transaction doesn’t mention these (beyond EUA). So you can authenticate the user at the client, in addition to authenticating the client they are on.

6. ATNA Secure Communications does specify TLS 1.0 or better, and the use of TLS_RSA_WITH_AES_128_CBC_SHA; this is an “Interoperability” statement, not a security statement. Meaning it is there to set a low bar that assures interoperability can happen. Policy is expected to take over from there, where policy can push the security criteria up as high as the actors can handle. If you are in the space of Policy, you can certainly set the Policy higher. I emphasize that IHE is focused on assuring that products come with capability that will interoperate, it is NOT constraining on the top-end and can’t constrain on the top-end; that is policy space. The profile does recommend that all crypto algorithms, and key sizes be configurable. It only specifies one set, so that interoperabililty will work, as without this it is likely two systems choose non-overlapping crypto algorithms and key sizes.

7. IHE has further explained that for HTTP traffic, it is likely that policy will allow HTTPS with no client-authentication, where the client is authenticated using IUA (OAuth). This is the same recommendation you will find in FHIR, and SMART. OAuth is an acceptable standard, it “can” represent the application as being authorized by the User. In this way it meets the expectation of ATNA Secure Communications. So if you are focused on HTTP like things, FHIR, then stop worrying about the client certificate in ATNA Secure Communications, and start demanding OAuth for client; as this does meet the ATNA requirement and is far more easy to manage in HTTP like architectures (Mutual-Auth-TLS is very hard to deal with in web centric architectures).

8. That said, although OAuth can be used to authorize background tasks for authorized applications (e.g. Facebook app does this); OAuth doesn’t work as well for cases where the identity that needs to be claimed is NOT HUMAN. Meaning it works fine for Facebook, but doesn’t work all that well for “The XCA Gateway of Kaiser”. In these cases certificates work better as they are inherently more manageable as automaton identity, vs human identity.
 
Conclusion
So, keep ATNA together, it is an important set of capabilities that if not used together don't provide security. Recognize that ATNA is just one security profile, user authentication is done with IUA, XUA, and EUA. Lastly recognize that IHE is enabling default interoperability, it is not restricting the security to that level. 

Thursday, August 20, 2015

Where do I record the Reason that an auditable event happened?

I received a question about where to put the 'reason' that an ATNA auditable event has happened. The short answer is that Security is not interested in the reason; but Provenance is.
Hello John,

I have a question around ATNA logging. We are currently implementing the Metadata Update profile; ITI-57 "Update Document Set". [Specifically for deprecating a document without replacement.]
However, we cannot find a place to store a reason (free text), which the user can enter when deprecating the document. It does not really make sense to allow the user to enter a reason, but not log it as part of the audit trail.

The ATNA log is for Security purposes. It therefore is not interested in why. it is just interested in the fact that it happened. Security is interested in making sure that those that are not authorized to do things, are prevented from doing them. So the Security audit log is there to prove that only authorized acts are happening. If non-authorized acts are happening, then security is broken somewhere. If acts are happening that shouldn't be authorized, then the access control rules need to be changed.

This is not to say that it is not important to Medical-Records that there is a reason why the act happened. As with most information in medical records, they don’t really get removed but rather deprecated. In these transitions it is important to note why this happened. This kind of a record-keeping is Provenance, and is parallel to security/privacy audit.

The most important distinction between Audit and Provenance is the target audience (Security/Privacy vs Medical-Records); this is also recognized in the fact that the Audit is often only kept around for a few years. The Audit is only kept long enough to prove that the whole system is operating properly, that only authorized acts are happening.

There is some support for recording the reason the event happened. But they are both coded values to limit the potential unintended spilling of PII into the Audit log.
  1. ParticipantObject.ParticipantObjectDataLifeCycle -- indicates the lifecycle that the object is now in.
  2. Event.PurposeOfUse, (also being added through DICOM) -- indicate the purpose of use when the event happened.

Note that this use-case, deprecate without replacement, is explicitly troubling. The original design for XDS allowed only Replacement. In a Replacement transaction one can record in the new XDS entry why this entry is better than the old one. This transaction was intentionally  the only method, so that we always had a permanent  record of the deprecation. We even explained how to do a Replace with an empty document. The Metadata-Update supplement breaks this nice model, and thus leaves us with no way to record why the deprecation is happening. The XDS registry is the place where Provenance is recorded, the ATNA log is not permanent.

So it is important with ATNA to keep the log entry to as minimal information as possible, using coded values and identifiers (pointers) rather than textual descriptions. This keeps the risk that the audit log itself presents as minimal as possible, while still making the content useful for the Security and Privacy use-cases. As in those use-cases the codes and identifiers can be dereferenced, with authority and audit log entries.


Blog articles on Audit Control