Security & Trust Meeting 2010-08-19

Notes from Security and Trust Workgroup
Date: August 19, 2010
Time: 2pm-3pm
Attendees: Nick Radov, Fred Totter, David McCallie, Greg Meyer, Justin Stauffer, John Moehrke, Don Jorgenson, Dave Juntgen, Mark Stine, Erik Horstkotte, Konda Mullapudi, Pete Palmer, Mike Davis, Brett Peterson, Uvinie Hettiaratchy, Caitlin Ryan

Actions from this week

#	Date	Action	Status	Owner	Due Date
46	8/19/10	Review harmonized threat assessment on wiki ([1] )	Open	All	8/26/10
47	8/19/10	Monitor both edits to table on wiki and discussion thread comments	Open	John Moehrke	8/26/10

Actions from last week

#	Date	Action	Status	Owner	Due Date
42	08/12/10	Help with providing guidance to provider offices with different options, if group decides to follow this model	Open	Ioana	n/a
43	08/12/10	Approach Will and Dragon of Documentation and Testing Workgroup to work together on security considerations document	Open	Pete, Ioana	8/18/10
41	08/12/10	Own the task of looking at two threat models	Closed	John	8/16/10
44	08/12/10	Open new wiki thread specifically for other workgroups to bring issues to WG’s attention. Will also socialize the thread and track new posts	Closed	Sean	8/16/10
45	08/12/10	Announce new thread at next week’s Face to Face meeting	Closed	Arien/Sean	8/18/10

Agenda

• Check in with John on reconciling threat models.
• Verify that Pete and Ioana have connected with Will and Dragon about "best practices" work.
• Certificate distribution with DNS vs. something like LDAP (introduction of issue below, from Sean’s email).
  • Issue Framing - Certificate Distribution
  • Our current state on certificate distribution comes down to the following:
  • Use of DNS for certificate distribution is a SHOULD. Advantage of having a single SHOULD is it pushes towards universality.
  • Other mechanisms are perfectly acceptable, especially in the pilot phase as we explore options.
  • Both reference implementations are implementing DNS as a baseline.
  • Cerner is planning to add LDAP as an option, with details are still to be worked out.
  • We would like to answer two questions today:
  • Do we want to change anything about this situation now?
    • If yes --- what? Options could be:
      • Replace the SHOULD with something else, like LDAP
      • Remove any SHOULD for the pilot phase
      • Make the SHOULD an or statement --- DNS *OR* LDAP
      • Just articulate more clearly the current state.
  • Sean's editorial: I think where we are is the best situation for now. We have a SHOULD that seems feasible and teams have implemented. There may be operational issues with it, and if so the pilots will discover that and have full freedom to pursue other models to resolve those. Post-pilot, we will have the option to change the SHOULD or even move to a MUST with those learnings.
  • Additionally, if we choose to elevate LDAP we will have to provide some guidance as to how it will work --- specifically, how will we find the right LDAP server for a given address? I do not think we will get to that discussion today. However, options I can think of are:
  • Use DNS SRV records to find the right server (e.g., address [[2]] results in a SRV request to endpoint.domain.com, fallback to domain.com).
    • Pro: SRV is a much more standard record type than CERT
    • Pro: Size of CERT records not an issue
    • Con: Just an indirection against what we do today ... still need DNS in the game
  • Have a naming convention to find the right server (e.g., address [[3]] results in an LDAP request to ldap.endpoint.domain.com, fallback to ldap.domain.com).
    • Pro: Simple, no DNS dependency
    • Con: Hacky; fixed naming requirements like this often cause operational issues
  • Central server
    • Pro: Easy
    • Con: Policy issues of control (showstopper if we are consistent with other decisions we've made)

Notes

John Moehrke

· Attempted to harmonize the two threat assessment models, Sean’s model which included security agent and John’s model that used end to end without HISP access. (Found on wiki: http://nhindirect.org/Security+and+Trust+Workgroup)
· Had a somewhat different flow to the two. Sean asked him to harmonize them so that if they both identified the same risk, they would use the same risk and identifier even if using different mitigation models.
· He used the same layout but a larger spreadsheet that includes the impact assessment and probability assessment to help guide as well as prioritize.
· He combined risks Sean had in his model into the new formatted table. When there was a similar risk identified, he reused the description.
· àAsked to have the WG look through the risk assessment
o Needs this audience to look at both models because having risk assessment by one or two individuals is not sufficient.
o Would like to hear from WG in the form of new edits directly to the wiki or comments via the discussion thread.
o After WG feels confident that the risk assessments work, the group will need to make sure mitigations are reflected in other NHIN Direct documentation, including the Overview, Security Requirements, etc.
o He wants WG members to question all aspects of his model: the impact, mitigation text, accuracy, descriptions to look for gaps and include risks that are not already included

Question to John
· What is the best forum for reacting to the threat model?

John Moehrke
· Feel free to add to the table on the wiki. Everything in there is questionable.
· Or else add comment to discussion tab.
· àJohn will monitor both ways.

Pete Palmer
· He and Ioana have begun email exchanges with Will and Dragon. Will continue.
Uvinie Hettiaratchy
· Proposes to table third agenda item, Certificate distribution, until Arien or Sean can lead.

All
· Agree

Uvinie Hettiaratchy
· Concludes meeting.