Certificate validation - use of CN

I got a question of what should be done with the Certificate CN (common name) value. Specifically should a system make sure that the TCP/IP Connection aligns with the CN hostname value?

The short answer is: ignore the Certificate CN; as the TLS authentication mechanism has already done cryptographically secure authentication. Adding any use of DNS to this will only result in false-negatives, meaning it will never add value but will occasionally cause you to reset a perfectly good connection.

Here is the question:

I have been trying to understand the certificate requirements in ITI-TF 2,  3.19.6.13 (Other Certificate Requirements) especially:

"The Secure Node shall not require any specific certificate attribute contents, nor shall it reject certificates that contain unknown attributes or other parameters.  Note that for node certificates the CN often is a host name, attempting to use this host name provides no additional security and will introduce a new failure mode (e.g., DNS failure). "

This requirement appears vague to me in that though it talks about CN not providing any additional security, it does not state whether we are supposed to consider it during validation or not.
I understand that may be it is up to the implementer, what I would really like to know is whether rejecting a certificate due to host name mismatch ( for e.g My repository is NOT using a certificate with Common Name = machine name/host name) should reject requests from a Client who is using my repository's endpoint (where Common Name is NOT = machine name/host name).

I would like to know how others are dealing with certificate validation and specifically Common Name mismatch errors.
1. What does "shall not require any specific certificate attribute contents, nor shall it reject certificates that contain unknown attributes or other parameters" mean?
   - If as a Secure Node, I want to only allow certificates know to me and reject the rest, is that counted as not meeting  IHE spec?
2. Are we supposed to ignore Common name mismatch errors entirely? And are they supposed to be ignored on the Client side (If I am a Document Source sending a document to a repository) or on the Server side (I am a registry accepting a query from a Document Consumer)?

I will really appreciate any more information on this.

We are trying to encourage everyone to ignore the CN, at least for authentication purposes. The reason is that the cryptographic validation that TLS has already completed is the secure authentication. The TLS authentication has already proven that the remote node has possession of the private key, and that the certificate used is a good certificate, and that the certificate is trusted directly or through a CA, and that the certificate used has not been revoked. 

The question points out that their Certificates are not putting hostname into CN. Thus if anyone tries to use the CN as a hostname they will fail a perfectly good and authenticated communications channel. This is clearly not intended or useful. So, this is a specific configuration we want to enable through encouraging not validating the CN.

Further if the CN is a hostname, looking at the CN will not fill any positive authentication function, but might cause a reset of a perfectly good connection due to a failure in the DNS lookup. DNS is not a security protocol!

Even Further; the Internet is getting bigger. The use of IPv4 often must use NAT in some regions. Use of smart clients on mobile devices can utilize multiple IP addresses over a short span of time. The use of IPv6 introduces a much more dynamic environment. 

So, ignore the CN found in the Certificate. There is enough you must do to properly implement Secure Communications, and avoid poodles.

Does this mean the CN is useless? Not really, it might be used to differentiate various remote endpoints. It will likely be used in Authorization decision. It should be used in the Audit Log. It should simply not be used in a reverse-DNS lookup for the purpose of failing a communication channel.

So the reason the technical framework is not more clear; is that we don't want to be overly restrictive and force the CN to be totally ignored. Thus all we can do is encourage with the most common and robust solution.  

Secure Communications

• Don't disassemble ATNA, what you are looking for is there.
• Why Mutual-Authorized-TLS?
• Testing ATNA Secure Communications
• Direct addresses- Trusted vs Trustable
• Identity - - Proofing
• Securing RESTful services
• IHE Encryption choices
• Healthcare use of X.509 and PKI is trust worthy when managed
• SSL is not broken, Browser based PKI is
• Meaningful Use Stage 2 :: SHA-1 vs SHA-2
• Trusting e-Mail
• S/MIME vs TLS -- Two great solutions for different architectures
• Healthcare Provider Discoverability and building Trust
• Using both Document Encryption and Document Signature
• Document Encryption
• IHE - Privacy and Security Profiles - Document Encryption

HHS Fact sheet on Ransomware and HIPAA

HHS has produced an 8 page fact-sheet on Ransomeware and HIPAA that is fantastic. It is so good that I have very little to say as any emphasis I would add is already in the 8 pages. Just 8 pages, packed with very readable, reasonable, reasoned, and backed by long standing Security and Privacy

HIPAA Regulation. There is no need for new regulation, as it is indeed all covered.

Call to action

I recommend hospital leadership sit-down with the "Security" Office and "Privacy" Office; walk through this simple 8 pages. If ANYTHING in the 8 pages is surprising; then you have a big problem on our hands. There is NOTHING in this 8 pages that should be surprising.   This fact-sheet should be viewed by hospital leadership just like a contracted penetration report, except this is more well written. For example This quote from an HHS article:"Your Money or Your PHI: New Guidane on Ransomeware"

The new guidance reinforces activities required by HIPAA that can help organizations prevent, detect, contain, and respond to threats, including:

• Conducting a risk analysis to identify threats and vulnerabilities to electronic protected health information (ePHI) and establishing a plan to mitigate or remediate those identified risks;
• Implementing procedures to safeguard against malicious software;
• Training authorized users on detecting malicious software and report such detections;
• Limiting access to ePHI to only those persons or software programs requiring access; and
• Maintaining an overall contingency plan that includes disaster recovery, emergency operations, frequent data backups, and test restorations.

Ransomeware is a Privacy Breach

The one point that did surprise me was the approach that an incident of Ransomeware is considered a Privacy Breach, unless proven otherwise. 

Some of the other topics covered in the guidance include: understanding ransomware and how it works; spotting the signs of ransomware; implementing security incident responses; mitigating the consequences of ransomware; and the importance of contingency planning and data backup. The guidance makes clear that a ransomware attack usually results in a “breach” of healthcare information under the HIPAA Breach Notification Rule. Under the Rule, and as noted in the guidance, entities experiencing a breach of unsecure PHI must notify individuals whose information is involved in the breach, HHS, and, in some cases, the media, unless the entity can demonstrate (and document) that there is a “low probability” that the information was compromised.

The point is that you must start with the conclusion that the data was breached, and prove that it was not. If the Ransomeware had access enough to encrypt, then it had access enough to have exfiltrated. 

The fact-sheet continues to explain this point, and explain it from may angles. It goes into express detail around a situation where the data that has been encrypted was already actively encrypted under the healthcare organizations encryption-of-data-at-rest. They nailed this one very nicely, and in few words.

Risk Assessment and Management Plan is not static

The one point of emphasis I would add is that the "Risk Assessment and Management Plan" that is indeed required by the HIPAA Security rule, also is required to be revised periodically 45 CFR § 164.306(e), states:

“Security measures implemented to comply with standards and implementation specifications adopted under § 164.105 [(the Organizational Requirements)] and this subpart [(the Security Rule)] must be reviewed and modified as needed to continue provision of reasonable and appropriate protection of [EPHI] as described at § 164.316.” 

Conclusion

I am very impressed and happy with all of the fact-sheets out of HHS. They have a very hard job of explaining difficult subjects to a huge and  heterogeneous. Made up of mature organizations and unprepared organizations. These fact-sheets should be viewed as an opportunity to exercise and investigate your working Security and Privacy plan.

Other articles I have on Security/Privacy Risk Assessment/Management

• Privacy Principles
• Why Mutual-Authorized-TLS?
• Failure of Privacy due to Performance vs Privacy
• Healthcare: Fail Open vs Fail Closed
• Safety vs Privacy
• IEC 80001 - Risk Assessment to be used when putting a Medical Device onto a Network
• More Webinars on Basics of IEC 80001
• IEC 80001 - Security Technical Report presentation
• How to Write Secure Interoperability Standards
• How to apply Risk Assessment to get your Security and Privacy and Security requirements

Basic Consent - a necessary first step

There are many standards efforts to develop support for Patient directed Authorization to their health data. I will be writing a few articles about these efforts.  These efforts sometimes use the term Privacy Consent, or Privacy Consent Directive, or Privacy Authorization, or Consumer Preferences, etc...

This post is about the one standards solution that is already available. IHE Basic Patient Privacy Consent. I have written about this extensively. I have spent much effort explaining why this is both: a powerful solution, and an under-powered solution. It is indeed both, and IHE knew this when it created this under-powered solution. It knew this so much that it included in the title "Basic" so that it would not be seen as the ultimate solution, but rather a simple beginnings.


I expected a replacement to BPPC to come along much sooner than now, but it has taken 10 years. That is right, BPPC was created in 2006.  It has not been upgraded until now because it filled a need, and was very clear what it couldn't solve. This does not mean that there was not solutions that solved the parts that BPPC can't solve, I know that there are many solutions that solved beyond BPPC. In fact these solutions are critical experimentation (Agile) for the new APPC profile. I am not going to explain APPC yet, simply going to note that Basic has been replaced by Advanced in APPC.

BPPC is 'clunky'; I am very clear about this. It requires pre-coordinated policies that must be statically defined, and configured into Access Control engines. Thus it is very limited as to what it can support. However this limitation supports a wide variety of use-cases. They are just pre-coordinated use-cases. Just like were supported in the paper world. So it was equally capable, and yet more capable.

Some examples where BPPC are used:

Connecticut HIE:

For release of Privileged Care information, a consent document SHALL be registered with HITE-CT in the form of a BPPC conformant document using the Opt-in for Legally Protected Data (ALL) policy. Where the consumer does not wish to have their health information available to HITE-CT PHCSs, a consent document SHALL be registered with HITE-CT in the form of a BPPC conformant document using the Opt-Out (Routine Care) and at the direction of the consumer, Opt-Out (Emergency Care). All Opt-in documents SHALL include an expiration date. This date SHOULD be recorded as two (2) years from the date the agreement is executed. All policies are global within the HIE such that an Opt-Out or Opt-In captured at one location covers all HIE member organizations. Common consent language shall be provided by HITE-CT.

Table 10.2.3-1 Patient Privacy Policies

Patient Privacy Policy Identifier OID	Use	Consent Document to be Filed
1.3.6.1.4.1. 38571.2.1.3.1	Opt-Out (Routine Care): Opt-out is specific to Restricted to viewing data registered in HITE-CT and SHALL NOT reflect restrictions pertaining to any exchanges not delivered through HITE-CT.	HITE-CT Opt-Out Routine Care
1.3.6.1.4.1. 38571.2.1.3.2	Opt-Out (Emergency Care):	HITE-CT Opt-Out Emergency Care
1.3.6.1.4.1. 38571.2.2.3.1	Opt-in for general use (OPTIONAL use where PHCS has captured or chooses to capture specific consent for HIE participation from consumer)	OPTIONAL: Provider Generated Document
1.3.6.1.4.1. 38571.2.2.4	Opt-in for Legally Protected Data (ALL)	HITE-CT Opt-In for Legally Protected Data
1.3.6.1.4.1. 38571.2.2.4	Reflect that acknowledgement of information exchange practices has been collected from the healthcare consumer or their authorized representative	HITE-CT Acknowledgement of Information Exchange Practices

 Example: A consumer had elected to Opt-Out of sharing routine clinical health information through HITE-CT. A Privacy Policy Acknowledgement Document is submitted through the consumer’s primary care provider recording the document as a scanned document under the Patient Privacy Policy Identifier OID 1.3.6.1.4.1.38571.2.1.3.2 in the XDSDocumentEntry.eventCodeList. The documentationOf/serviceEvent is populated with an effective time reflecting the current date as the ‘low value’ and the current date +24 months as the effective data ‘high value’.

Texas HIE

As an example of how much is covered by BPPC; Texas HIE has a Privacy Policy document that is 111 pages long. Bringing together dozens of national, state, and region regulations. Addressing many different perspectives including BAA, Government reporting, and special sensitive health topics. This is the kind of thing we expected would be needed. One can't simply have a code "HIPAA" which is understood everywhere as meaning the same thing. One must always have interpretations of regulations, and that interpretation must consider other regulations, care setting, and other factors.

 Social Security Administration

Authorization to Disclose Information to the Social Security Administration (SSA) -- eAuthorization

SSA-827 Authorization to Release Information policy is: 2.16.840.1.113883.3.184.50.1.

Although this is just a 2 page form, the policy backing this form is not simple

 Conclusion

I am very proud to have been part of the creation of BPPC. I am surprised that it has taken 10 years to come up with an Advanced form. But I am very happy with how this Advanced form builds upon BPPC. I will explain this in another article.  The lesson is that we need Basic before we can get to Advanced; and Advanced still leverages the Basic. So we have advanced the art of Privacy Consent, while providing something simply Basic, while continuing to develop toward Advanced. 

This article is all about IHE Document Sharing, and not about FHIR. Yet the same lesson needs to be recognized in FHIR. We should start out Basic and then continue on to more Advanced. Same lesson needs to be recognized in HEART, with the UMA effort. We should start out Basic and then continue on to more Advanced.

Historic articles Patient Privacy controls (aka Consent, Authorization, Data Segmentation)

• electronic Privacy Consent -- Patient choice
• Privacy-by-Design Data-Analytics Platform on FHIR
• Simplified #FHIR Privacy Consent Directive resource
• Consent given to authorized representative
• Patient ID is critical to Enabling Privacy
• Consent to grant read access to a specific types of FHIR Resources
• electronic Privacy Consent -- Patient choice
• BPPC is not just for XDS/XCA
• How to set the ConfidentialityCode
• Strawman on Consent Directive
• Privacy Principles
• Break-Glass on FHIR
• 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

Extending the FHIR standard to handle provenance

I wrote a paper for W3C PROV program with Arnon and Adriane from Mitre. The paper discusses the experience so far with applying the W3C PROV model to the HL7 FHIR model. Much of the material and inspiration came from my blog post in March on "Provenance vs Audit - its not a competition". The paper is much better, and all of that better-ness is because of my co-authors.

The paper is published on Provenance Week 2016 - program agenda "PROV: Three Years Later". I was not present to present. Search for "FHIR".

You will also notice that Reed Gelzer has a paper published there as well.

The main point we make in our paper is to introduce the PROV community to the FHIR community, and thus enable the PROV community to better understand how other standards communities are using their standard, and thus the struggles they have with understanding and applying it to the Healthcare domain.  In fact pointing out that because of historic reasons healthcare has separated Audit from Provenance, and this might not please a provenance purist.

Abstract: 

In this work, we look at the problems a domain-specific standard committee faces when trying to “involve” provenance to meet domain requirements, without committing to the major expansion of adding a general provenance capability. We also begin the discussion of what the provenance community can do to assist the domain-specific creation committee with the easy inclusion and usage of well-specified, and provenance-community approved guidance.

That is not to say that the goal is to force all PROV use to be pure, but rather to help the PROV community understand how they need to be guiding force, not breaking force.

Privacy-by-Design Data-Analytics Platform on FHIR

In all the networking and interviewing I have been doing lately I have been thinking more and more about a really cool project that I would love to participate in. As far as I know someone must have tried this, but it will take many technology advancements yet. So if anyone is working on this, I want to talk to you and see if I can get on your team. Yes, I am still looking for a job.

The idea is I want to use Privacy-By-Design to design a Data-Lake that will respect Privacy Principles in all data uses.

Stories of poor security from vendors that should know better

I simply must point to a very specific episode of SecurityNow, a very good podcast every week. Episode 567 because he describes in detail five different products/services that simply did not do security right. All might look like well secured products to marketing, sales, or any leadership. But not done right at all. Sorry that the podcast is 2 hours long, but the whole thing is worth listening to because the whole two hours is full of story after story. These are not old stories, these are from this week or the week before. Symantic, StartCom, AuYou, etc...
The point is to

For those that want to read, not listen... He has fantastic notes he uses during the show; and later will have transcripts of the actual spoken word.

Interoperability will never be perfect - not even FHIR

I just finished a fantastic book "In the Land of Invented Languages: Adventures in Linguistic Creativity, Madness, and Genius" by Arika Okrent.

This book was recommended by Grahame Grieve. I don't have evidence he recommended it, but I am sure it was Grahame. I wondered why he would have recommended such an obscure book. I may have figured out why, but I might have completely over blown the thought.