Data Objects and the Policies that Control them

In reading the President's Council of Advisors on Science and Technology (PCAST) report on "Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward"; among the many comments that I could make on it, I want to focus this blog article on one very specific point. The point I want to discuss is the directionality of the relationship between the Data Object and the Policies that Control them. This point is not specific to PCAST, and has been discussed many times over the years.

In the PCAST report Section "V. Privacy and Security Considerations", on page 49 in the following sub-section quoted below is the part I highlight in yellow:

A Health IT Architecture for 21st-Century Privacy and Security
We believe that a universal exchange language based on tagged data elements will allow the design of much better privacy and security protection than currently exists for either paper or electronic sys­tems, for two principal reasons.  First, the ability to tag an individual piece of data with privacy ­related information, as part of its metadata, enhances privacy safeguards.  Second, because tagged data ele­ment exchange protocols are designed to be efficient for the rapid exchange of small pieces of data, it is feasible to use security protocols that involve multiple exchanges of challenge and response.  We illustrate these points in this and the next subsection.

I will note that I am reading the PCAST report as a set of principles brought together by the small group invited by the Whitehouse. So, First I will note that this is a small group; Second this was a closed group; Third it was not a very transparent process, and Fourth this was a group with some suspicious membership. But this is not what I want to focus on.

I have no problem with 'tagged data elements', I speak highly of this in Data Classification - a key vector enabling rich Security and Privacy controls. The actual value of  these tags is part of the discussion.  In the future I would like to have a discussion about the practical realities of their implied definition of an 'element', where I would like to recommend that a 'Document' is a reasonable size to manage today. 

Data Objects pointing at the Policies that control them:


What I want to focus on is the directionality of the model being propagated by the PCAST report. They indicate that the individual piece of data has a tag (metadata) with the privacy related information. I read this that the Metadata points at the privacy policies that describe how to control the individual peice of data (the 'element').


Data Object  --> Privacy Policy

Policies point at the Data Objects that they control
This seems like a logical approach, and indeed was the approach that BPPC took in the first version. In the first version of BPPC the confidentialityCode of any document could hold the OID of the BPPC policy. This seemed logical to us at the time too. But what we found out was that this doesn't scale with the age of the data-set. What I mean is that as a patient changes their mind regarding sharing (opt-in, opt-out, etc), one needs to go and change all the metadata tags on all the data, rather than just change the policies.

So BPPC now has the confidentialityCode as a sensitivity/confidentiality classification, and the BPPC policy is self-contained. If the BPPC policy needs to have special rules about a specific Document, the the BPPC policy points at the document. For example when a patient wants a specific episode summary hidden, it is identified by the unique number in the privacy policy.

Privacy Policy --> Data Object

Indeed as the patient changes their privacy policy, or the organization changes their privacy or security policies; these changes should be reflected in the privacy/security policies, not in changes to the data. The data hasn't changed, the policy has changed.

Metadata describes the Data as facts, and Policies have the specifics about how to control the data 
In fact the Data object does have metadata that is used in the Access Control decision. Metadata that does include a confidentialityCode, classCode, formatCode, Patient Identifier, Facility Identifier, Author Identifier, etc. But I don't see these as 'pointers', but rather 'security context attributes'. See the IHE white paper Access Control - Published 2009-09-28

I am optimistic that the authors were not trying to impose an architecture, but rather identifying a principle. As a principle the directionality should not matter.

PS. software engineers might find this useful, or might be confused by it -- this is like the first-year school assignment in linked-lists, stacks, and fifo... the obvious direction of the pointers is not the right direction to implement. Ok, that might not help at all...

Most popular blog entries of 2010

The blog tools make this post easy, but it is still useful to record an annual perspective on what seemed important at the time. Clearly the popularity contest is won by 'ranting'.

1. Meaningful Use Security Capabilities for Engineers This is where I describe the Meaningful Use security capabilities and provide recommendations on what they mean and how to implement them
2. Meaningful Use clearly does not mean Secure Use I am amazed at how many hits this got and continues to get. It is a rant on the MU draft, yes they did fix some of the things I rant about. See item 1.   
3. Meaningful Use Certification issue with Encryption of data-at-rest This is where I rant about how the Meaningful Use rules messed up and defined tight requirements for encryption and integrity controls but failed to say anything about key management, content packaging, or portability. 
4. Meaningful Use Security Capabilities Lacking, Privacy Capabilities NON-existent  Another rant...Yup, privacy is still missing... 
5. Meaningful Use - Security Plan This is where I ranted less, but gave advice to how to read the Meaningful Use draft.
6. Accountability using ATNA Audit Controls This is where I explain how to achieve the requirements of Accountability with simply an Audit Control. (Watching what people do is very important. It is sometimes the only way to detect users misbehaving, like looking at VIP patients or downloading thousands of documents)
7. Data Classification - a key vector enabling rich Security and Privacy controls This is where I demystify the confidentialityCode as a part of segmentation, and explain how this is metadata to be used by access control engines as one of the factors used to determine if a specific use of data should be allowed or not. (For those reading PCAST, read this as if it is the PCAST concept of 'tagged data element approach'. It is part of the whole picture but not completely... )
8. Meaningful Use Encryption - passing the tests This is where I explain just how bad the data-at-rest requirements are and how screwed up the testing is.   
9. IT security problems continue (Designing a Secure HIE) This is where I explain that point-to-point security doesn't scale and that a walled-garden approach using TLS may be a better starting point. (Yes, this is an old article that still is true today. We see in NHIN Direct something closer to the unconstrained point-to-point, or end-to-end. The solution being discussed is to restrict NHIN Direct endpoints to 'organizations', thus ending up with a smaller map but still quite the spider web)
10. Meaningful Use takes Security Audit Logging back a decade It is unfortunate that we work hard to advance security and privacy only to have regulation take us back to the dark ages.

I have some articles that I think are more long-term explanations of a concept. They are not so much popular at any given time, but are references:

IHE Security/Privacy primer
Meaningful Use Security Capabilities for Engineers
User Identity

• Healthcare use of Identity Federation
• Federated ID is not a universal ID 

Access Controls - Including enforcing Privacy

• ConfidentialityCode can't carry Obligations
• Data Classification - a key vector enabling rich Access Controls 

Consent Management

• Stepping stones for Privacy Consent 
• Consumer Preferences and the Consumer  
• Availability of Consent Documents and their rules 

Audit Controls

• Accountability using ATNA Audit Controls 
• ATNA and Accounting of Disclosures 

Other Controls

• Signing CDA Documents
• Redaction and Clinical Documentation  
• How to Write Secure Interoperability Standards
• Designing a Secure HIE

S/MIME vs TLS -- Two great solutions for different architectures

John Halamka with help from Dixie Baker wrote about a topic that came up on HIT Standards discussion asking why the Direct Project secure transport couldn't just be TLS.

Arien Malec responded with a good discussion of some issues that were uncovered during some prototyping. I am not convinced that this was fully investigated, but it still is a good read and a well done description of SSL, TLS server authentication and TLS mutual authentication.

My answer is: Security is hard, Trust is hard…

All the posts I have read today are all not looking at the total picture. I recommend one look at the Security and Trust workgroup output (Yes, I am a very active member). I think that the Threat Models are most important here:

Threat Models (WG Consensus Achieved)
Direct Project Security Overview (WG Consensus Achieved)
Certificate Pilot Recommendations Discussion (WG Consensus Achieved)

With TLS, you MUST create a walled garden. Any hole in the wall causes the whole thing to fail. If TLS was used there would be a private e-mail network just for trusted organizations, all organizations would need to be trusted.

TLS is not as care-free – PKI free - as Dixie tries to say it is. The comments about not being able to know if you are connecting to the right place is exactly evidence that PKI is need here. What is not needed with TLS is an out-of-band mechanism to distribute certificates, since TLS includes certificate discovery/distribution inline. But one must have a trust relationship.

It is this distribution of certificates that is the hard part of S/MIME. I send signed email messages to people that I want to be enabled to send me encrypted content. This mechanism of certificate distribution, sending a prior signed message, is the one that is used in practice today. I have tried to argue that any use of NHIN Direct messaging very likely was preceded by conversations that were not patient specific but were related to building a relationship. Between organizations this conversation was about what services one might offer another. These conversations likely included discussions about legal restrictions. These conversations could have easily have transmitted the certificate and setup a trust relationship.

also see: Healthcare Provider Discoverability and building Trust

TLS is great for point-to-point communications, or for communications with trusted-intermediaries. But it fails for end-to-end asynchronous message communications, and is NOT the right approach for e-mail.

Wrapping:
There is a little bit of discussion about 'wrapping'. The wrapping that is being discussed is S/MIME wrapping… that is to take an email message and put it inside another email message… Think Russian dolls… The theory is that if you keep wrapping enough times it must be secure. This can hide the ‘subject:’ line, but doesn’t hide the ‘to:’ or ‘from:’.

Yes one can have a highly intelligent email router that puts false ‘from:’ on the outside email, and somehow uses a trusted-intermediary-endpoint-address (‘to:’). Clearly lots of discovery problems here, or configuration and databases. But if you are going to configure this kind of a system, then we should just use a more capable system.

Scope of NHIN Direct
People keep forgetting that NHIN Direct is a transport for VERY SMALL providers with VERY LITTLE technology. These people only need to communicate with a few ‘others’. We need the NHIN Direct solution to help low-tech people. We needed it to work with little beyond off-the-shelf software, or exactly commercial (or open-source) off-the-shelf.  The NHIN Direct transport should NOT be looked to as a solution for more intricate workflows.

As part of this NHIN Direct has also recommended that email addresses could be departmental or organizational. That is one address that represents a whole department or whole organization. Thus there isn’t a huge number of addresses, one for each organization. I don’t think this is a great solution, as it basically brings us back to organization-to-organization rather than end-to-end; but it does put the policy decision in the hands of those that should make the policy decision.

So, I suggest they keep the scope clear for NHIN Direct… Allow simple e-mail with slightly complicated security… and get working on robust health information exchanges. Use NHIN Direct as a stepping stone, and stop thinking it is a long term solution.

See:  Directed Exchange vs Publish/Discover Exchange and NHIN-Direct Privacy and Security Simplifying Assumptions

Healthcare needs to watch and learn from the cascade of security failures

Wikileaks is the big news today. This blog article has NOTHING to do with WikiLeaks, but has everything to do with using the event which are associated with WikiLeaks today as a useful use-case to analyze in the context of Healthcare Security and Privacy.

It scares me that someone might think that exposing PHI on WikiLeaks would be an appropriate way to ‘expose’ a healthcare abuse. As much as the current exposure of the diplomatic cables has resulted in mostly embarrassing gossip, exposing PHI would be far more dramatic. The methods that WikiLeaks seems to use don’t give me any comfort that exposure of PHI might not happen. I hope that it would not. But this is not what I want to cover here.

I want to look at the security failures upstream of what we are seeing on WikiLeaks. I think there are very useful lessons to learn.

Data Classification: I understand that originally the Diplomatic Cables were classified ‘confidential’ or ‘top secret’ at one point. Which was later considered too restrictive, so they were re-classified to ‘secret’. This re-classification clearly was a key to the exposure of these cables, as about 3 million people have ‘secret’ clearance. This re-classification was felt necessary to give more access, which might have been the right thing.

It is my understanding that when data gets re-classified there should be new assessment of the data that might result in some information being blinded. I don’t think that this would have removed the gossip, but do wonder why such a bulk of data was either (a) originally classified wrong, or (b) so easily reclassified without recourse. I want to point out clearly, that I am still strongly for Data Classification and totally agree that there needs to be functionality for re-classification (up or down). It simply seems like sloppy process was used in this case.

What we can learn, is something we are struggling with in healthcare. That Data Classification is a rather blunt instrument, it doesn’t work very well to support fine-grained access controls. But it is a start, and better than no Segmentation.            See: Data Classification - a key vector enabling rich Security and Privacy controls

Access Controls: The re-classification gave access to a broader range of individuals. It is not clear why this was necessary. I will not try to figure out if this specific user should have access to this specific set of data. What I do wonder though is why this user also had the permissions necessary to export the reports, and put them on a non-secured storage. People are very creative, and I suspect this individual was creative enough to have overcome many Access Controls. Military or Diplomatic secrets would seem to need many layers of protections. Either they existed or this individual is more creative than most.

Audit Controls: The main failure that bothers me the most is that either no Security Audit Logs were produced that indicated that someone was viewing/copying THOUSANDS of documents, or that no one was watching the log. Even an automated program could have triggered easily when a hundred documents were viewed from the same place.  See Accountability using ATNA Audit Controls And ATNA and Accounting of Disclosures

There has been a lot of press speculation that all of the documents, starting with the helicopter attack video, have come from the same source, a young U.S. Army intelligence analyst, who has been arrested. If that is the case it looks like access to vast databases of secret U.S. government documents was rather broadly available and access was not reasonably logged. None of the documents released to date have been marked top secret so, maybe, the database had some level of data segregation. But, if news reports are accurate, no log was kept of access to the database or, if such a log exists, it was not regularly reviewed, since suspicion was directed at the analyst by a person outside the U.S. military. More

Security and Privacy are not simple, they require checks and balances.

IHE Security/Privacy primer

Most of the IHE profiles in the security space are all simply pointers to common IT security protocols. The message is that healthcare is not special when it comes to security. That healthcare should just leverage the good work common to all IT. The following is NOT a complete explanation. I assume the reader can use a internet search engine to find resources including the specification themselves using key terms I provide. Clearly official profile text and standard text is the best resource.

ATNA - This is a comprehensive profile that indicates that Access Control, Audit Control, and Network Controls are important

• Access Control
  • There is no standards pointed to by ATNA here. There is simply a statement that a system needs to have access controls that can be shown to a local authority are sufficient to protect the systems resources according to the local policies
  • If this can't be demonstrated, then the system should not be authorized to be used. Specifically it should not be given a network identity (see network controls)
• Audit Controls
  • Specifically Security Audit logging
  • This is a very thin profiling of the commonly used SYSLOG protocols for communicating that an auditable event has occurred
  • There is statements that relax size limits
  • This is a FULL PROFILE of the content of that auditable event into an XML encoded message
  • There is a set of 'auditable events'. That is events that when they happen an audit log should capture what happens
  • The audit log message is fully describing: Who, What, Where, When, How, and Why.
  • This requires that the audit event time be kept consistent. Which is why the CT profile exists. The CT profile says use common NTP protocol to keep clocks synchronized to about 1 second, which is generally good enough for security audit logs
  • See Accountability using ATNA Audit Controls And ATNA and Accounting of Disclosures

• Network Controls
  • There are a set of standards specific to the type of network communications. They all address three aspects of network communications of protected information. Not all network communications are protected, for example DNS is not generally needing to be protected as it is not communicating protected information (mostly)
  • Authentication of both sides of all communications that include protected information
  • This is consistently done using machine/service-end-point identities using public/private keys (certificates)
  • Certificates can be directly trusted. One-by-one
  • Certificates can be trusted because they 'chain' to a known authority (certificate) that is trusted directly
  • Caution: the method used on the internet with SSL certificates is technically the same, but not administratively the same. In the internet browser world the 'known authorities that are trusted' are authorities that your internet browser decides should be trusted.
  • ATNA wants a deliberate decision of trust to be done, not a decision by a vendor.
  • Encryption of the communications that include protected information
  • AES is the protocol of choice. This choice does NOT mean that other protocols can't be used. It only means that at least AES needs to be present. This is to assure interoperability. This is NOT to constrain algorithms
  • Integrity control of the communications that include protected information
  • SHA1 is the protocol of choice. This choice does NOT mean that other protocols can't be used. It only means that at least SHA1 needs to be present. This is to assure interoperability. This is NOT to constrain algorithms
  • Note also that the communications is transitory, not long-term-storage, so the use of SHA1 is acceptable. SHA1 tends to not be acceptable for long term signature (See DSG below)
  • TLS is the general mechanism when no other mechanism is used. TLS is the 'standardized' protocol that is more commonly called SSL. (mostly)
  • IHE profiles that BOTH sides of the communication need to be authenticated
  • Whereas common SSL only authenticates the server. This is not sufficient as it allows any client to connect. In healthcare we want to know where the data is coming from and where it is going. Not just the server
  • S/MIME is used for e-Mail
  • WS-Security mechanisms are allowed for Web-Services that want to use end-to-end security. Note that none of the IHE profiles leverage this as they are all profiles defining endpoints that need access. But this is specified because there may be deployments where someone puts in the middle of an IHE transaction some form of intermediary that needs partial access
  See Designing a Secure HIE

PWP - This is a very thin profile that simply says that for user directory, use LDAP

• LDAP is a protocol for doing queries of a directory. That directory might be a database or may be specifically a directory
• The schema for describing a user is based 99% on the common user
• The little addition to the schema is really not that important
• This profile also describes how to find the directory. Using a special DNS record that points at the LDAP directory
• There are pointers to how LDAP can be secured using TLS.
• There are pointers to how LDAP can be used to authenticate a user, through the LDAP security mechanisms
• LDAP is the standard that Windows ActiveDirectory uses for accessing directory entries
• Healthcare Provider Directories (HPD) is a profile leveraging LDAP as well for external use
  • See Healthcare Provider Directories. And Healthcare Provider Directories -- Lets be Careful

EUA - Very thin profile that simply says to use Kerberos protocol for safely authenticating users

• Kerberos is a pluggable protocol, but really is only used for username/password
• Kerberos is the standard that Windows ActiveDirectory uses for authenticating users.
• Kerberos is the standard that Windows uses at windows login (with minor Microsoft extensions)
• Kerberos is very common in Unix as it was invented at Berkely
• Kerberos is really good for within an organization, but has real problems that prevent it from being useful on the internet
• There are also Kerberos ways to pass authentication 'tickets' between an application and server
• See: Kerberos required in 2011 then forbidden in 2013

XUA - Very thin profile that simply says to use SAML Identity Assertions for authenticating users on Cross-Enterprise transactions

• This is the solution for the space where Kerberos doesn't work well
• SAML is both a standard for an XML way to describe a user and provide trust mechanisms of that data; and also a protocol
• The protocol is not part of the XUA profile. It is ok, but not as important as the assertion
• There are other protocols that are more common, WS-Trust is one.
• There is also good reason for a product that does its own user authentication to simply create SAML assertions w/o protocol
• See - Federated ID is not a universal IDand IHE ITI XUA++ - Trial Implementation

DSG - A profile of XML-Digital Signatures to provide long-term signature across a 'document'

• Can sign any document type. Not limited to XML type documents such as CDA
• Signature document is created that is an XML-Digital Signature blob
  • Original document to be signed is signed by 'reference'.
  • Encapsulation is not a bad thing, but it does make the original document harder to get at. Especially if that original document is not XML based
  • Signature by reference allows the original document to continue to be accessed normally by applications that don't need to validate he signature. While having the signature present for those applications that do need it.
  • The digital signature includes the Date/Time of the signature. Assuming trustable date/time
  • The digital signature includes the certificate of the signer
  • Note that signatures need to be valid for decades. Which brings up interesting certificate management issues not addressed.
  • The digital signature includes the reason for the signature. Why was it signed? What does the signature mean?

• XDS Metadata shows that the signature document is in a 'signs' relationship to the original document
  • This allows for finding the signature from a document, and finding the document from the signature
• Works for XDS, XDM, XDR, XCA
  • Might work for other environments as well. The main thing that must happen is for there to be a way to dereference the document ID number found in the digital signature document to get to the document that is being signed.
• Might be future work to have an encapsulated flavor
• See: Signing CDA Documents

BPPC - A profile of a document that represents a patient agreeing to a privacy policy (e.g. Consent)

• Uses CDA to capture that the patient has agreed to a policy by reference
  • The policy is not actually ever defined. This is because there is not sufficient maturity to any standard for encoding of privacy policies. Therefore BPPC assumes that someone can write the policy in human readable language and give that a unique identifier (OID). This OID is used as a reference.
• Supports the consent being digitally signed with DSG
• Supports encapsulation of a scanned image of something (e.g. an ink on paper signature) using the XDS-SD profile
• Supports time limited consents
• Supports both positive policies (OPT-IN) and negative (e.g. OPT-OUT)
• Recognizes that the absence of an instance of a policy means that some other policy is in place. Commonly called 'implied consent'.
• Defined for XDS, XDM, XDR, XCA - and may work for other environments
• See Stepping stones for Privacy Consent

ENC - new profile being worked on this year - Encryption of documents and/or XDM

• Because this is under development the details are yet to be written
• Document encryption has favor as it would be transport agnostic, but is unclear the usefulness of this for long-term-storage usecases like XDS and XCA.
• XDM encryption would likely leverage the e-Mail option that exists today
  • The e-Mail option uses S/MIME to secure the ZIP of the XDM file-system
  • The modification from existing profile would be to explain how to save the S/MIME message as a file rather than delivering it over SMTP
  • This file would simply be a S/MIME message, thus protected with whatever the S/MIME protections used.

confidentialityCode - this is NOT a profile, but is a security/privacy concept built into almost all of the healthcare standards.

• Statement of the data security/privacy classification
• Would be used by access control decisions
• See: Data Classification - a key vector enabling rich Security and Privacy controls.

De-Identification handbook - this is NOT a profile, but is a document being written this year.

• Will be a procedure document that explains how one would evaluate the requirements for a De-Identification scheme specific to a desired use-case
• Would leverage De-Identification and Pseudonymization
• See De-Identification is highly contextual and Redaction and Clinical Documentation

Other

• Cookbook: Preparing the IHE Profile Security Section - Revised 2008-11-10
• HIE Security and Privacy through IHE- Revised 2008-08-22
• Access Control - Published 2009-09-28

Secure Design

• All this assumes that your system is secure by design. This includes limiting opportunities for bad guys.
• Risk based approach should be used to assure that all risks are managed appropriately
• Unnecessary services are disabled, security patches applied,
• Multiple layers of defense are in place both within and in the network
• Etc.

The Direct Project and IHE/HIMSS

"The Direct Project", formerly known as NHIN Direct, has officially changed their name, the specifications are maturing, the reference implementations are maturing, and the discussion is turning to the topic of where will the output of the Direct Project land and be maintained. I think that IHE is a very logical place and a place that I find many synergies between what the NHIN Direct project did and what an IHE US Realm would do.

The Direct Project (NHIN Direct) specifications are almost completely aligned with the IHE XDM – E-Mail option. They have simply added that sending a single document without the XDM wrapping is allowed. This is the kind of thing that I would expect a realm specific workgroup to acknowledge.

The Direct Project (NHIN Direct) have done some analysis of the IHE specifications and have provided feedback to the IHE ITI committee their recommendations on both XDM and XDR profiles. This analysis is done in the context of the the direct environment and intended audience. Most importantly this analysis was done in the context of a set of Privacy, Security, and Operational policies. Again, this is the kind of thing that a US Realm committee would be expected to do. For example: They have observed that the XDR and XDM metadata rules are too onerous for the direct PUSH use-cases, especially when applied to some specific use-cases that the IHE ITI committee did not looked at yet. The Direct Project also looked at the interaction between XDM and XDR at a gateway service and applied privacy policy in such a way as to question why XDR has integrated sender and recipient address inside the more sensitive metadata.

The Direct Project group is now struggling with Testing. They don’t have experts in writing test plans, test procedures, or test tools. The closest thing they do have is experts on unit-testing that comes along with the source code of their “reference implementation”. I think this is also a good place for a US Realm to focus a local Connectathon toward the local realm use-cases, and tie this to the local demonstration project (e.g. HIMSS Interoperability Demonstration). For this the IHE expertiese in test tools and testing events like Connectathon would be very valuable.

The Direct Project does have a component that IHE does not have today, this is the open-source reference implementation.  IHE does come close with the open-source Registry from NIST; but this was more of an individual effort (one that needs to be recognized often), rather than a formal part of specification approval. I think there is an opportunity for IHE to extend a welcoming hand to this style of specification validation.

The Direct Project also has the Implementation Geographies. It is not clear how well this will workout inside the IHE context. I think it is something unique to the NHIN Direct project at this time due to the style of solution vs the ‘pure interoperability specification’ that IHE tends to focus on. I know that there might be concerns with getting too close to implementations, thus presenting a conflict-of-interest.

The Direct Project is an excellent example of what a region can and should do with the IHE specifications. They deviated only slightly, and when they did they provided the feedback to IHE for discussion and iteration. There are some useful lessons to be learned by IHE on how to excite a region and to accelerate implementation through reference implementations and implementation geographies.

Engage with Grace

If you are reading this on Thanksgiving day in the US, print this out and read with your loved ones.



Really, read it. That is the message.  To learn more, see http://www.engagewithgrace.org/

John

P.S.  I am thankful that there are so many people who care so much for others that they are willing to work in healthcare. Top to bottom, thanks to everyone.