Glen Marshall is well known in Healthcare Security circles, and he continues to contribute in Retirement. He produced this use-case and I found it so well written, and it explains Security Audit Logging (FHIR AuditEvent) as distinct from Provenance (FHIR Provenance) so well, that I asked him if I could publish it as a guest post. I got his approval almost a month ago, so here it is.
Tuesday, October 13, 2015
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.
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.
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.
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
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.
- ParticipantObject.ParticipantObjectDataLifeCycle -- indicates the lifecycle that the object is now in.
- 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
Wednesday, July 15, 2015
How to set the ConfidentialityCode
I have been discussing the confidentialityCode, especially within the context of IHE-XD* (Document Sharing). I was asked, by Keith, to give guidance on how the confidentialityCode should be set as without guidance he just tells everyone to use "N" (Normal confidentiality).
Some background articles:
Some background articles:
- Healthcare Privacy and Security Classification System (HCS)
- Data Classification - a key vector enabling rich Security and Privacy controls
- and other articles on my topics page
Recommendation for setting confidentiatlityCode
So. I would continue to recommend that anyone or any-system publishing a CDA document should use "N", unless they have evidence to say that is the wrong value. Meaning it should be a specific effort to choose the other values:
This is right out of the definition of the vocabulary values 2.16.840.1.113883.5.25 for "_confidentiality". Available from the FHIR specification for easy reading. https://www.hl7.org/fhir/v3/Confidentiality/index.html
The VHA has shown some success in demonstration projects with passing the data through a CDS (Clinical Decision Support) to tag sensitive clinical concepts. See FHIR Demonstration of DS4P. If none are found then the data is "N", if some are found then the data is "R", if specific types are found the data is "V"… This automated method has me somewhat worried as the social norms of what is sensitive, change often. So using this automated form on publication time might produce wrong evaluation overtime. In the case of the VHA demonstration, they applied it upon 'use' of the data, so it was using the social norms rules at the time of reading. Likely better social norm rules, but not sure this is better behavior. Note that the intermediate step is tagged sensitivity category, which might be given to the access control system as information to be used in the access control decision or enforcement
- "R", because there is specifically sensitive content – HIV, alcohol/drug abuse, etc.
- "V", because the content should be seen only when reader is individually authorized -- psychology-notes, usually also used on all VIP patients (Not a best practice, but reality).
- "M", because the content is less sensitive than normal, but still medical. authorized for wide distribution – like an emergency-data-set, or for dietary use-cases
- "L", because the content is not medical, or has been de-identified
- "U", because the content is not specific to an individual and is public
This is right out of the definition of the vocabulary values 2.16.840.1.113883.5.25 for "_confidentiality". Available from the FHIR specification for easy reading. https://www.hl7.org/fhir/v3/Confidentiality/index.html
How to determine what the value should be?
I don't disagree that this is a hard thing to determine.- It might be determined by workflow, psychology notes clearly are coming from a psychology workflow.
- Clearly de-identification is a specific workflow.
- It might be an explicit act, where the user is specifically trying to make a less-sensitive document for broad use such as a emergency-dataset, or
- for export to the dietician.
- It might be a specific request, where the clinician decides that the data is very sensitive, or
- where the patient decides that the data is very sensitive.
The VHA has shown some success in demonstration projects with passing the data through a CDS (Clinical Decision Support) to tag sensitive clinical concepts. See FHIR Demonstration of DS4P. If none are found then the data is "N", if some are found then the data is "R", if specific types are found the data is "V"… This automated method has me somewhat worried as the social norms of what is sensitive, change often. So using this automated form on publication time might produce wrong evaluation overtime. In the case of the VHA demonstration, they applied it upon 'use' of the data, so it was using the social norms rules at the time of reading. Likely better social norm rules, but not sure this is better behavior. Note that the intermediate step is tagged sensitivity category, which might be given to the access control system as information to be used in the access control decision or enforcement
Is there more?
All the other security-tags are not likely to be set upon publication. IHE has brought in the whole of the "Healthcare Privacy/Security Classification System"- IHE specifically recommends against using the sensitivity category, as the value itself is sensitive. They are useful for internal use, like the VHA demonstration.
- Compartment is mostly undefined, but would likely be a local value-set. Unlikely to be understood at publication time. Interesting place to play, as it might be used to define compartments like Radiology, Cardiology, Psychology, etc... but it is untested grounds.
- Integrity could be equally set by the publisher, although it is not well enough defined. But this would be a way to tag data that was generated by the patient, vs data generated by a licensed clinician.
- Handling caveats might be set on publication. The only cases I can think of are similar to the "V" cases, in that the author explicitly knows something about the data and thus needs to add a caveat.
- One specific example is 42CFR Part 2 – SAMSA covered treatment- that must be explicitly marked with a 'do not disclose without explicit authorization by the patient'. NOAUTH
- Second specific example is an obligation to delete after use, which specifically forbids persistence (including printing) DELAU
Conclusion
So, simple guidance. You need all of the _confidentiality vocabulary, and two more from the handling caveats. -- [U, L, M, N, V, R] + NOAUTH + DELAU
Blog articles by Topic
Blog articles by Topic
- Patient Privacy Controls
- Access Control (including Consent Enforcement)
- Document Sharing Management (Health Information Exchange - HIE)
Friday, June 12, 2015
FHIR does not need a deidentify=true parameter
There has been a very short discussion of this topic on the FHIR Implementers skype. The question was asked if there was a need for FHIR to explicitly support de-identification. Fortunately Grahame is smart enough to say NO. I then added this detail.
What everyone keeps forgetting to recognize is just how hard it is to de-identify, and how easy it is to mess it up.
There is nothing preventing someone from creating an intermediary that looks like FHIR, and talks FHIR to the backend, while de-identifying the data according to some algorithm. However the algorithm is very use-case and risk specific. This is the model IHE proposes, with a handbook to help with the algorithm selection, backed by ISO standard. De-Identification: process reduce risk of identification of entries in a data-set.
There is no need for a parameter deidentify=true.... as you are already indicating WHO (OAuth) is making the query and why. This is information used by the Access Control Service, in keeping with enforcing RBAC, ABAC, Consents, and laws/regulations. This access control decision can determine that 'less' information shall be returned. Where 'less' is specific to the request, authentication, etc. Where 'less' might be a de-identification algorithm, or might be to return '200 zero results found'.
Unless one comes up with a NULL-set, you are leaving RISK in the de-identified data-set.
Other articles:
What everyone keeps forgetting to recognize is just how hard it is to de-identify, and how easy it is to mess it up.
There is nothing preventing someone from creating an intermediary that looks like FHIR, and talks FHIR to the backend, while de-identifying the data according to some algorithm. However the algorithm is very use-case and risk specific. This is the model IHE proposes, with a handbook to help with the algorithm selection, backed by ISO standard. De-Identification: process reduce risk of identification of entries in a data-set.
There is no need for a parameter deidentify=true.... as you are already indicating WHO (OAuth) is making the query and why. This is information used by the Access Control Service, in keeping with enforcing RBAC, ABAC, Consents, and laws/regulations. This access control decision can determine that 'less' information shall be returned. Where 'less' is specific to the request, authentication, etc. Where 'less' might be a de-identification algorithm, or might be to return '200 zero results found'.
Unless one comes up with a NULL-set, you are leaving RISK in the de-identified data-set.
Other articles:
Wednesday, May 27, 2015
In Wisconsin we have Interoperability
There is much talk on the blogs about the USA government trepidation around Health Information Exchange interoperability. Some samples:
- Geek Doctor -- Interoperability and the Trough of Disillusionment
- Motorcycle Guy -- Who should be in charge of developing HealthIT Standards for the US
This is a Standards based HIE, based on IHE-XDS and XCA. Fully federated.
I also find it interesting that opt-out has only happened 33 times, total, out of 2.6 million patients. Yes, this is an 'implied consent' state. There are many ways offered for patients to opt-out. Note, one patient has chosen to opt back in...
John
From: Wisconsin Statewide Health Information Network [mailto:wishin@wishin.org]
From: Wisconsin Statewide Health Information Network [mailto:wishin@wishin.org]
Subject: WISHIN Connections - May 2015
|
<![endif]>
<![endif]>Sunday, May 3, 2015
Strawman on Consent Directive
The Healthcare community continue to struggle with Patient Consent Directives. I assert it is because we have two very different forces:
We can't change Healthcare by writing very complex standards like the current FHIR ConsentDirective, which is fundamentally a "Contract" resource. And the CDA ConsentDirective is even less realistic. First I recommend that FHIR make ConsentDirective a resource rather than just profiles of Contract. I have defended this model so far, but the negatives are more powerful. People simply want a ConsentDirective resource.
Might I suggest that the ConsentDirective project include a "Basic-ConsentDirective" that supports blanket consents without exceptions. Essentially the common HIE policies from BPPC. These would be scoped to sharing beyond the original organization and purpose for which the health information was created. This form of a Consent Directive would need only (identifier, issued, applies, subject, authority, domain, type=consent, subtype=<some vocabulary>, and possibly friendly and legal). This Basic Consent Directive would support the following HIE subtypes:
More advanced consents can be made once we have this basic vocabulary in place. For example we an then add exceptions, which can be computable rules. For example an "Opt-In" but not to Doctor Bob. All of the Opt-In logic is understood from the reference to Opt-In, the only thing that needs to be added is the exception for Doctor Bob. No need to duplicate the logic of Opt-In in each patient chart.
- Healthcare Business -- that are under many regulatory, ethical, and business forces. This makes it very hard to change, especially hard to make radical changes. So this community needs very small realistic changes suggested that eventually produce the result desired.
- Patient Advocates -- that want a very different User Experience. This community wants all of the Privacy Principles implemented. They accept nothing less, likely because of the limited movement so far.
We can't change Healthcare by writing very complex standards like the current FHIR ConsentDirective, which is fundamentally a "Contract" resource. And the CDA ConsentDirective is even less realistic. First I recommend that FHIR make ConsentDirective a resource rather than just profiles of Contract. I have defended this model so far, but the negatives are more powerful. People simply want a ConsentDirective resource.
Might I suggest that the ConsentDirective project include a "Basic-ConsentDirective" that supports blanket consents without exceptions. Essentially the common HIE policies from BPPC. These would be scoped to sharing beyond the original organization and purpose for which the health information was created. This form of a Consent Directive would need only (identifier, issued, applies, subject, authority, domain, type=consent, subtype=<some vocabulary>, and possibly friendly and legal). This Basic Consent Directive would support the following HIE subtypes:
- Opt-In -- Agree to publish "All" healthcare information. Agree to Use and Disclosure to "any" authorized individual of a "Treatment" or "Payment" organization "For the Purpose" of "Treatment" or "Payment". No Redisclosure allowed without further authorization. This agreement does not authorize other accesses.
- Opt-Out allowing break-glass -- Agree to publish "All" healthcare information. Agree to Use and Disclosure to "any" authorized individual of a Treatment organization for specifically "Emergency Treatment" PurpoeOfUse, and Payment of those treatment. This agreement does not authorize other accesses.
- Opt-In summary access only -- Agree to publish "All" healthcare information. Agree to Use and Disclosure to "any" authorized individual of a "Treatment" or "Payment" organization "For the Purpose" of "Treatment" or "Payment"; to only the medications and allergies summary. No Redisclosure allowed without further authorization. This agreement does not authorize other accesses.
- Opt-In break-glass summary access only -- Agree to publish "All" healthcare information. Agree to Use and Disclosure to "any" authorized individual of a "Treatment" organization "For the Purpose" of "Emergency Treatment" and Payment of those treatment; to only the medications and allergies summary. No Redisclosure allowed without further authorization. This agreement does not authorize other accesses.
- Opt-Out no break-glass -- Agree to publish "All" healthcare information. This agreement does not authorize any accesses.
- Opt-Out completely -- Agree to publish "No" healthcare information beyond originating organization intended use.
I will also note that I think we should look to ‘Creative Commons’, which I explain on my blog.
References:
Patient Privacy controls (aka Consent, Authorization, Data Segmentation)
- Healthcare Patient Consent -- Lessons learned from Creative Commons
- Enabling Patients to Delegate Healthcare Information Access Authority
- Define Atom -- Too many definitions in use today
- Defining Privacy
- Safety vs Privacy
- Privacy Consent State of Mind
- Universal Health ID -- Enable Privacy
- Texas HIE Consent Management System Design
- Simple and Effective HIE Consent
- IHE - Privacy and Security Profiles - Basic Patient Privacy Consents
- Data Segmentation - now I know where the term comes from
Access Control (Consent enforcement)
- What does the SAML assertion mean in a XDS/XCA query/retrieve?
- Healthcare Privacy and Security Classification System (HCS)
- Define Atom -- Too many definitions in use today
- Healthcare access control scope constraints on OAuth tokens
- Advanced Access Controls to support sensitive health topics
- Policy Enforcing XDS Registry
- Healthcare Metadata
- Texas HIE Consent Management System Design
- IHE - Privacy and Security Profiles - Access Control
- Data Classification - a key vector enabling rich Security and Privacy controls
- Healthcare Access Controls standards landscape
- Handling the obligation to prohibit Re-disclosure
- Access Controls: Policies --> Attributes --> Implementation
Subscribe to:
Posts (Atom)