Security & Trust Meeting 2010-11-04
Date: November 4, 2010
Time: 2:00pm-3:00pm EDT
Attendees: Mike Berry, Mike Davis, David Houlding, Don Jorgenson, Umesh Madan, Arien Malec, John Moehrke, Jack Ousey, Pete Palmer, Brett Peterson, Jas Singh
Actions from Two Weeks Ago
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 49 |
2010/08/26 |
Create a one page document further explaining the LDAP issue to be submitted to the Security and Trust WG at large for approval |
Open |
John Moehrke |
2010/09/02 |
| 57 |
2010/09/09 |
Explore participation in the IHE North America Connectathon 2011 and a demo for the 2011 HIMSS Annual Conference |
Open |
Arien Malec, Didi Davis |
On-going |
| 60 |
2010/10/14 |
Direct Project Security Overview: Read, provide feedback and vote on the Call for Consensus |
Open |
Entire WG |
TBD |
| 61 |
2010/10/14 |
Certificate Pilot Recommendations: Read, provide feedback and vote on the Call for Consensus |
Open |
Entire WG |
TBD |
| 62 |
2010/10/14 |
Duplicate risk assessment for the XD* Conversions for Direct Messaging specification |
Open |
John Moehrke |
2010/10/21 |
| 64 |
2010/10/21 |
Review and contribute to the Threat Model - Direct to and from XDR once John Moehrke finish the first cut |
Open |
Tim Andrews, David Houlding, Dave Juntgen, John Moehrke |
2010/10/28 |
| 65 |
2010/10/21 |
Bring the Direct Project Security Overview up for an IG Call for Consensus |
Open |
Arien Malec |
2010/10/28 |
| 66 |
2010/10/21 |
Provide comments on the Certificate Pilot Recommendations Discussion document |
Open |
Pat Pyette, John Moehrke, Mike Berry |
2010/10/28 |
Agenda
- Review Certificate Pilot Recommendations
- Review Direct Project Security Overview
- Review Threat Model - Direct to and from XDR
Notes
· Umesh Madan
o Leading his first call
o Agenda – Jas kindly posted on the wiki
o Recommendations to get to consensus
§ Certificate Pilot
§ Direct Project Security Overview
o Assume everyone has read them
· Arien Malec
o Theoretically over the deadline
· Umesh Madan
o Several yes’s
o Couple of issues that still remain
o Round on the issues, changes
o First comment – RWMN (Will Ross)
§ Seem reasonable
o Read out the comment
§ Recommends that they fix some basic terminology
· Change definition of community – a group of organizations that agree to common policies for DIRECTED exchange
· Definition for implementation – language would be – DEPLOYMENT of Direct technology to deploy messaging functionality to a community
· Grammatical error = Trust addresses trust enabling
· Fixed a typo RWMN
· Umesh Madan
o Any objections?
· Arien Malec
o Objects to the implementation notion change
§ John Moehrke has been looking at this in terms of SMTP
§ Implementation hear refers to HISPs
o If we change the way Will Ross suggests it, then
· John Moehrke
o Suggests that they call it a whole-service HISP
· Umesh Madan
o Asked about directed exchange
· Arien Malec
o Said that makes sense
· John Moehrke
o Asked about covered entities v. non-covered entities
· Arien Malec
o Might make sense to change “generally” to “may”
· John Moehrke
o No problem with the words logically
o People are looking for words like “for example” for a non-complete list
· Arien Malec
o Suggested a way to make them illustrious
· Umesh Madan
o Who will own these changes?
· Arien Malec
o Volunteered to own the changes
· Umesh Madan
o Siemens do you want to speak about your comments?
· Jack Ousey
o Indicated that he did not write the comments, but they are straightforward
o Read the comment out loud [INSERT THE COMMENT]
§ Everyone should install a new e-mail client, even if their current client is conformed well
· Arien Malec
o This raises the points of the initial HITSC concerns
§ Because it came from the HIT standard committee
o Does agree “must recommend or may” in the same way in the specification
· John Moehrke
o Would not like to see it
o This was a guidance document for the pilots
o This is not a specification, would have many other comments if that was the case
o Likes the way it currently is
· Jack Ousey
o As long as they are highlighting and clarifying will be okay
· Umesh Madan
o It is a recommendation, but does not disbar the option
· Jack Ousey
o It is the pilot, so get more information and make sure everyone is on the same page
· John Moehrke
o Agrees the spirit of the comments – probably written by David Tao
§ Things in here we could only publish in the context of the pilot projects
§ Wants to keep a lot of this stuff open for the specifications until they learn
o Likes the way it is worded right now – clearly a pilot decision
o Do not have to have a parenthetical after comment
· Umesh Madan
o If you choose not to adhere, there is not much they can do there
· Don Jorgenson
o Has some concerns about the special purpose language
§ Makes it seem like a problem
· Umesh Madan
o As long as there is an obvious wall
· Arien Malec
o “Dedicated meets the needs of the pilots”
· Jack Ousey
o Will talk to David Tao about this
· Arien Malec
o Volunteered to make the changes globally
o Knows the VA has specific concerns, so they should try to address them
o Asked Mike Davis if he had any comments
· Mike Davis
o Did not have time to review it yet
o Has more concerns about where the CERTs are and the trustworthiness of the CERTs
o Not likely to accept CERTs that do not have trustworthiness with
§ Unless they are on the federal bridge
§ Or if the DHHS plans to provide a certificate authority
· Arien Malec
o The document still allows the VA to put in their requirements
· Mike Davis
o Okay with it as far as it goes in that they can say they will not accept the CERTs until certain requirements are met
· Umesh Madan
o Is that a “yes” vote then?
· Mike Davis
o Yes
· Arien Malec
o I will make the edits, we don’t have any no’s left
o None of the edits will change at the WG level
o Already cleared Best Practices and Impl. Geographies
§ Change from “NIST level 2” to “consistent NIST level 2”
§ Verifying particular statements, etc.
· Equivalent processes
§ Any HISP can do a lot, so the “at least” gives more credibility/assurance
· Ongoing topic in the privacy and security “tiger team”
· Some of the things in NIST may not be appropriate for healthcare
o Next IG meeting they will ask for a consensus vote
§ Will give the rest of the IG the next week to vote
· Mike Davis
o 863 has an update as well 863.1
§ 863.1 significantly simplifies the process
· No proofing which will be marvelous for the healthcare
· New version will have broader applicability for the Obama Administration’s strategy for identity assurance in cyberspace
· Arien Malec
o Indicated that it make sense to “consistent with or higher”
· John Moehrke
o Agrees with it
· Mike Davis
o Would be worth checking on if it is a requirement
· John Moehrke
o Agrees – this does with the pilot’s discussion
o Be cautious about this – could put you in a touch corner
§ Still good to promulgate the
· Mike Davis
o Will do an interpretation of 863.1
o If the Feds say we have to do it, then we will do it!
· Pete Palmer
o Gets a little more complicated
o Needs to make sure the certification program is all right
· Arien Malec
o Mike Davis if you could do that pass, it would be very helpful
· Mike Davis
o Agrees, and would love to help
o Need to be careful with the federal healthcare agencies
o It’s one thing to say people can do whatever they can do, but if it excludes Feds then it is a bad thing
· Arien Malec
o It behooves anyone running a pilot that may involve the Feds to think about the certificate implications
· Umesh Madan
o People have been looking at this?
· Arien Malec
o Yes so people have been informed
· Umesh Madan
o Direct Project Security Overview
o Some small clarifications could make the document a lot more accessible
o Just start from the top
o Can summarize himself
§ Allscripts raised some issues about “circles of trust”
· Assumption that CA is “verisign”
· Clarification: Not just verisign, but can run their own CA
· Arien Malec
o Suggested they include the RFC with all the details about CAs
· Umesh Madan
o Restating the “circle of trust’ can happen
§ Message integrity
§ Message enforcement
§ Link for Simple Health Transport and the RFC
· Arien Malec
o Usually talks to people who know about security a lot
· Umesh Madan
o Same struggle
· John Moehrke
o Don’t want to duplicate
o We have the gory detail in other page
· Umesh Madan
o Suggestion: a couple of lines about how the trust is enforced
§ We look at the signing certificate, etc
o Solicited comments
· Arien Malec
o Confusing enough, but should be addressed
· Umesh Madan,
o So a short paragraph (Work Item)
o Ask John Moehrke to write it?
· John Moehrke
o Will give it a shot – but requested that they do remind him where it is
· Arien Malec
o Interjected that he will volunteer to finish
· John Moehrke
o Just send me the link when you are done
· Umesh Madan
o Epic had several questions:
o Main objection has implications
§ References S/MIME but does not allow a path to XDR/XDM
§ Also a comment about TLS, but perhaps address the XDR/XDS
· Arien Malec
o TLS is mandated anytime you are passing an unencrypted message
§ You are recommended, but don’t have to do so for the channel when you are sending encrypted message
o Follow the associated threats models as well as all the IHE recommendations
· Umesh Madan
o No statement in there that it is required
· Arien Malec
o Necessary distinctions are addresses in the threat models and mitigations
· John Moehrke
o And it is directly in the deployment models as well
· Umesh Madan
o Any suggestions?
· Arien Malec
o The consensus proposal says that if you got mutually agreed upon alternate transport, but must provide strong levels of security for transport
§ Will explicitly mention XDR and IHE specifications
· Umesh Madan
o Another comment from EPIC
§ Document should remove that individuals can specify “circles of trust”
· Arien Malec
o Concern is that if you are an enterprise, then the enterprise gets to choose
o If you are a individual provider, than you get to decide
· Umesh Madan
o Suggested that they approach it by clarifying things
· John Moehrke
o Adding a contextual piece that separates this from internet browsers
o Depends if ONC suggests the model
· Umesh Madan
o Assuming Arien handles all of this
o Any other higher priority things we should look at?
o Other issues all dealt with XDR and has been addressed
o Inpriva’s remarks:
· Don Jorgenson
o Issues as they are going through the implementation
o Is the community doing the identity proofing, or is that responsibility being pushed on to the policies of the certificate?
§ Issues between identity of the certificate and the proofing process
· Arien Malec
o Tried to address that
o If a community is running their own CA, then they already have the pieces in place to address the trust issues for the certificate
o If it is another organization, then that organization will have its own policies for issuing certificates which community should be comfortable with
§ Those communities will have their own policies
· Don Jorgenson
o If they are doing that, then we will be asking them to play the community certificate role
§ Those issued here agree to the terms of the community
§ Required to enforce the provisions of the community
§ That is where they are concerned
· Arien Malec
o Assumption is that the community is defining the set of practices which it is comfortable with
§ Running its own CA
§ Or choosing a CA which matches it own requirements
· Umesh Madan
o Its up to the community to say if you want to get a certificate from us, then you have to agree to our requirements
· Make Davis
o Might say that outside of your community, there should be an understanding amongst the different communities
· Umesh Madan
o You see our criteria for our CERT first and how we enforce those policies, and if those are agreeable, then you go forward with it
· John Moehrke
o Decision is not being made by the community, but actually organizations
· Umesh Madan
o Agreed with that statement
o Allows individuals to even make decisions in these cases
§ For cross organizational exchange
· John Moehrke
o Does not see any problem with communities with overriding power, but the LCD is that organizations will manage their own trust via other organizations or communities
· Mike Davis
o Do not think this will cause any grief
o The one-to-one
· Don Jorgenson
o Kind of addresses the concerns
o If you do have to look at the CERT policies of other HISPs, there is a scaling issue
· Arien Malec
o Agrees – long-term will be the CONTARA initiative or an HHS setup CA or set of CAs
· Don Jorgenson
o But the Direct Project does not have the authority for setting up such rules
· Arien Malec
o Will take a pass at it to make it more clear
· Umesh Madan
o Sorry if I missed anyone
o We are done.
XDR/XDM Threat Model
· It is up there
· Please be careful to read this, specifies
o Emphasizes there is a reliance on the other Direct Project threat models
o Also depends on the IHE threat assessment on XDR
o Connects to a Direct Project specification – rather constrained/lean
§ Otherwise it would have to repeat a lot
· Already received comments and made changes to it
o Let me know if you have any further comments