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.