This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "HL7 FHIR Security 2017-04-04"

From HL7Wiki
Jump to navigation Jump to search
Line 43: Line 43:
  
 
===Open Issues===
 
===Open Issues===
TODO: John to arrange these for the meeting.
+
The following are currently in Deferred state. Now to be worked on for STU4 (release 4):
  
The following are currently in Deferred state. Now to be worked on for STU4 (release 4):
+
====Discus====
 +
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12501 12501] Provenance.reason+and+Provenance.activity+should+be+CodeableConcept (Grahame Grieve) None
 +
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13015 13015] Provenance+doesn%27t+follow+event+pattern+for+onBehalfOf (Lloyd McKenzie) None
 +
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13016 13016] Provenance.agent.role+should+be+1..1 (Lloyd McKenzie) None
 +
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13012 13012] Provenance.period+should+be+a+choice (Lloyd McKenzie) None
  
 +
====Assigned to John====
 +
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12941 12941] Security+Role+vocabulary+should+include+ISO+21298 (John Moehrke) None
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=9167 9167] AuditEvent+needs+to+make+more+obvious+how+to+record+a+break-glass+event (John Moehrke) Considered for Future Use
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=9167 9167] AuditEvent+needs+to+make+more+obvious+how+to+record+a+break-glass+event (John Moehrke) Considered for Future Use
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=10343 10343] Three+additional+Signature.type+codes (Kathleen Connor) Considered for Future Use
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=10579 10579] New+Security+and+Privacy+%22Module%22+page+needs+content (John Moehrke) Considered for Future Use
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=10580 10580] How+should+test+data+be+identified%3F (John Moehrke) Considered for Future Use
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=10581 10581] something+should+be+said+about+de-identification (John Moehrke) Considered for Future Use
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12462 12462] Security%2FPrivacy+Module+page+should+explain+W5+realty+that+provenance+elements+in+other+resources+vs+use+of+Provenance+as+a+resource (John Moehrke) Considered for Future Use
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12463 12463] explain+relationship+between+Provenance+and+AuditEvent.+ (John Moehrke) Considered for Future Use
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12501 12501] Provenance.reason+and+Provenance.activity+should+be+CodeableConcept (Grahame Grieve) None
 
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12502 12502] Provenance.agent.relatedAgentType+is+nonsensical (Grahame Grieve) None
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12502 12502] Provenance.agent.relatedAgentType+is+nonsensical (Grahame Grieve) None
 +
** Need feedback from Grahame. John to pursue. We did not intend to break
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12660 12660] HCS+use+clarification (John Moehrke) None
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12660 12660] HCS+use+clarification (John Moehrke) None
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12939 12939] Security+Role+vocabulary+should+be+mentioned+on+the+security.html+page (John Moehrke) None
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12941 12941] Security+Role+vocabulary+should+include+ISO+21298 (John Moehrke) None
 
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13011 13011] The+value+set+for+security-role-type+is+broken+for+Provenance (Lloyd McKenzie) None
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13011 13011] The+value+set+for+security-role-type+is+broken+for+Provenance (Lloyd McKenzie) None
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13012 13012] Provenance.period+should+be+a+choice (Lloyd McKenzie) None
+
** Need to get actionable feedback from Lloyd. John to pursue.
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13013 13013] Valueset+for+Provenance.activity+is+broken (Lloyd McKenzie) None
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13013 13013] Valueset+for+Provenance.activity+is+broken (Lloyd McKenzie) None
 +
** Need to get actionable feedback from Lloyd. John to pursue.
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13014 13014] Provenance.agent.relatedAgentType+doesn%27t+make+sense (Lloyd McKenzie) None
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13014 13014] Provenance.agent.relatedAgentType+doesn%27t+make+sense (Lloyd McKenzie) None
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13015 13015] Provenance+doesn%27t+follow+event+pattern+for+onBehalfOf (Lloyd McKenzie) None
+
** Need to get actionable feedback from Lloyd. John to pursue.
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13016 13016] Provenance.agent.role+should+be+1..1 (Lloyd McKenzie) None
 
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=11071 11071] Improve+security+label+guidance+-+2016-09+core+%2390 (Kathleen Connor) Not Related
 
  
===Outline for Security & Privacy Module===
+
====Assigned to Kathleen====
Use this CR or create a set of new CR as needed.
+
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=10343 10343] Three+additional+Signature.type+codes (Kathleen Connor) Considered for Future Use
**[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=10579 10579] New Security and Privacy "Module" page needs content ()  
+
** need to work with some organization (e.g. HL7) to create three new vocabulary values. These vocabulary values need to be defined as OID values, because they are used in external standards that have a data-type of OID (i.e. XML-Signature). So they can't be text vocabulary, and they need to be fully OID.  
 
 
http://build.fhir.org/secpriv-module.html
 
  
====Use of Security Labels====
 
  
From email discussion between Kathleen and John -- Summary by John
+
====Narrative improvements====
  
The FHIR community is unclear on how how to use the security-labels. When is it appropriate to use each type. Where is it appropriate to use each type? Specifically what are the risks they need to consider.
+
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=10580 10580] How+should+test+data+be+identified%3F (John Moehrke) Considered for Future Use
 +
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=10581 10581] something+should+be+said+about+de-identification (John Moehrke) Considered for Future Use
 +
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12462 12462] Security%2FPrivacy+Module+page+should+explain+W5+realty+that+provenance+elements+in+other+resources+vs+use+of+Provenance+as+a+resource (John Moehrke) Considered for Future Use
 +
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12463 12463] explain+relationship+between+Provenance+and+AuditEvent.+ (John Moehrke) Considered for Future Use
 +
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=10579 10579] New+Security+and+Privacy+%22Module%22+page+needs+content (John Moehrke) Considered for Future Use
 +
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=11071 11071] Improve+security+label+guidance+-+2016-09+core+%2390 (Kathleen Connor) Not Related
 +
*[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12939 12939] Security+Role+vocabulary+should+be+mentioned+on+the+security.html+page (John Moehrke) None
  
I agree with this.. This is hardly understood by the core people in the security wg...  I am however concerned at declaring any specific policy -- such as the sensitivity codes shall never be used.
 
  
Seems we could create a few scenarios that outline proper use, and include description of the security considerations that went into that use.
+
http://build.fhir.org/secpriv-module.html
 
 
1) Use of HCS tags within a highly-trusted environment (All inside my security boundary, within my own trust environment. my own trust framework). -- This is minimally use between the Access Control services and the REST server, including use of an SLS to enable access control decisions. I could see this highly-trusted environment being bigger than this, but think that most people need to understand that exposing the full HCS security-labels does present a risk.
 
 
 
2) Exposure of Resources to a Moderate-Trusted environment (They are outside my security boundary, but we have a trust framework that assures me they can protect sensitive information and follow obligations) -- the HIE environment. As you say, where _confidentiality and obligations. This is where we can talk to Bundle being a high-water, of only the _confidentiality codes; and where obligations would go.
 
 
 
2.1 ) The placement of obligations seems important enough that we should have a specific scenario just for that, so as to highlight it.
 
 
 
3 ) Having a USA specific example using 42 would be useful too. This is a rollup of all the things we want to say. I think it is okay to be USA centric, but when we do this we should explain the situation in terms that are not overly USA centric.
 
 
 
4) Use of HCS tags when in a low-trusted environment (I trust they will not expose what I give them, but they have limited ability to protect highly sensitive information or to enforce obligations) -- Where you are going to block access to anything sensitive. Showing that blocking access might be silent, or might be explicit (we have outlined this in the http error codes for security). Both are useful policy choices.
 
 
 
4.1 ) do we include your concern around returning obligations only when you KNOW that the recipient will enforce them? It needs to be said somewhere. Here might be good place.
 
 
 
5) Always good to remind people that they are not to expose information when the trust is not there.
 
 
 
Not sure if it is proper to use highly-trusted, moderate-trusted, and low-trusted -- I think the trust framework is key
 
 
 
is this what you are proposing? Did I miss a concept? I think this would be a good discussion today.
 
 
 
 
 
 
 
====Access Control====
 
* Outline for a FAQ improvement on the module page
 
* Access Control
 
** Access Control diagram from Mike (Inputs – Decision – Enforcement – Outputs)
 
** Using OAuth
 
*** Identity
 
**** Leverage OpenID Connect
 
**** Federate (cross-reference, mapping) to local identity descritions
 
***** Informally, or Formally
 
***Roles
 
****Using Standard roles from HL7
 
****Using local codes
 
****Clearance
 
***Scopes
 
****Using SMART scopes
 
*****Basic starter set
 
*****Supports Organizational use-cases with simple consent
 
*****Doesn’t support fine-grain
 
*****Doesn’t support complex consent
 
****Using HEART – UMA
 
***Using Cascading Authorization Servers
 
****Bridging SMART and UMA and organizational requirements
 
**Using Security labels
 
***HCS conformance
 
****MUST have a _confidentiality value (1..1)
 
****Use of persistence label
 
****Bundle use of security_tags – high-water
 
****Comprehensive security_tags on each resource communicated to a trusted peer
 
****Using security lables from a consent directive (privacy policy) on goverened resources
 
****Using Clearance with security labels
 
**Bring in stuff from the Privacy Consent Implementation Guide (Consent IG)
 
***TODO
 
** Should we create a new page, parellel with security.html -- privacy.html
 
*** Privacy Principles
 
*** Consent as a way to control Collection/Use/Disclosure
 
*** ISO four models (In, Out, In with exceptions, Out with exceptions)
 
**Trust Framework
 
***impact on the Conformance resource published by partners.
 
***Establishing trust Contracts between trading partners
 
 
 
=== Improvement opportunity for our security/privacy pages===
 
* Should point at Duane's code
 
** ?
 
* Questions Mike has received
 
** What is different about FHIR security than from security anywhere else?  Don't we still just have encryption, authentication, authorization and audit?
 
** FHIR Privacy?  ONC and OCR are talking about privacy ("patient choice" and "patient right of access")  Does FHIR security support patient privacy?  What do I need to do to meet HIPAA?
 
** What do we actually need to do to implement FHIR security? How is it related to NIST security?
 
** We've invested dollars in EHRs already.  How can we afford changes in these systems to support FHIR security?
 
* What are the "Frequently Asked Questions" regarding Security and Privacy?
 
** Input from the Mobile group?
 
** Tactical Security
 
*** Device security, cloud security, big-data security, service-to-service security, etc.
 
*** Building trust -- how do I know this App is safe? How do I know this cloud is safe?
 
*** Point at NIST  https://nccoe.nist.gov/projects/building_blocks/mobile_device_security
 
*** Point at OWASP https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10
 
*** Each of the 10 risks has a drill down page such as https://www.owasp.org/index.php/Mobile_Top_10_2016-M3-Insecure_Communication
 
** Transport Security
 
*** TLS - Server Auth
 
*** TLS - Mutual Auth
 
*** Problems with crypto deprecation (aka SHA1)
 
** Privacy Consent
 
*** Consent Resource
 
*** Use of Questionnaire to interact with patient with result as a Consent
 
*** Use of Consent Resource to point at evidence -- consent locator
 
*** Use of Consent Resource to hold consented rules
 
*** Interaction between Consent Resource and AuthZ decision engine (e.g. XACML)
 
**** Push vs Pull vs Service
 
***** Push: When a consent is gathered, the AuthZ data is updated as well as a Consent resource stored; therefor when an AuthZ decision needs to be made all the consent knowledge is contained within the AuthZ environment
 
***** Pull: When a AuthZ decision is made, the Consent Resource is interrogated as a PIP. Thus the FHIR Server holding consents are viewed as a PIP from the AuthZ architecture perspective.
 
***** Consent as a service --- See HEART use of UMA -- Patient interacts in non-standardized ways with a UMA authority. All actors wanting access to FHIR Resources get re-directed toward UMA service for AuthZ decision.
 
** AuthN + AuthZ -- OAuth vs SAML vs TLS-mutual-Auth
 
*** SMART
 
*** HEART
 
*** IHE IUA
 
*** Interaction with Consent
 
** Audit Logging
 
*** Genera need (See general security frameworks like NIST 800-53)
 
*** Use AuditEntry
 
** Provenance
 
*** Provenance as a standalone resource
 
*** provenance elements as part of resources -- see W5 report
 
*** provenance as parts of containers like DocumentReference, Composition, Message, etc
 
** Other?
 
  
 
=Minutes=
 
=Minutes=

Revision as of 20:52, 4 April 2017

Call Logistics

Weekly: Tuesday at 05:00 EST (2 PM PST)

Web conference desktop and VOIP https://www.freeconferencecall.com/join/security36 
Online Meeting ID: security36
Phone: +1 515-604-9567, Participant Code: 880898
 Please be aware that teleconference meetings are recorded to assist with creating the meeting minutes 

Back to HL7 FHIR security topics

Attendees

Member Name Member Name Member Name
x John Moehrke Security Co-Chair x Kathleen Connor Security Co-Chair . Alexander Mense Security Co-chair
x Suzanne Gonzales-Webb CBCC Co-Chair . Johnathan ColemanCBCC Co-Chair x Mike Davis
. Reed Gelzer RM-ES Lead x Glen Marshal x Joe Lamy
. Diana Proud-Madruga . Rob Horn . Beth Pumo

Agenda

Open Issues

The following are currently in Deferred state. Now to be worked on for STU4 (release 4):

Discus

  • 12501 Provenance.reason+and+Provenance.activity+should+be+CodeableConcept (Grahame Grieve) None
  • 13015 Provenance+doesn%27t+follow+event+pattern+for+onBehalfOf (Lloyd McKenzie) None
  • 13016 Provenance.agent.role+should+be+1..1 (Lloyd McKenzie) None
  • 13012 Provenance.period+should+be+a+choice (Lloyd McKenzie) None

Assigned to John

  • 12941 Security+Role+vocabulary+should+include+ISO+21298 (John Moehrke) None
  • 9167 AuditEvent+needs+to+make+more+obvious+how+to+record+a+break-glass+event (John Moehrke) Considered for Future Use
  • 12502 Provenance.agent.relatedAgentType+is+nonsensical (Grahame Grieve) None
    • Need feedback from Grahame. John to pursue. We did not intend to break
  • 12660 HCS+use+clarification (John Moehrke) None
  • 13011 The+value+set+for+security-role-type+is+broken+for+Provenance (Lloyd McKenzie) None
    • Need to get actionable feedback from Lloyd. John to pursue.
  • 13013 Valueset+for+Provenance.activity+is+broken (Lloyd McKenzie) None
    • Need to get actionable feedback from Lloyd. John to pursue.
  • 13014 Provenance.agent.relatedAgentType+doesn%27t+make+sense (Lloyd McKenzie) None
    • Need to get actionable feedback from Lloyd. John to pursue.

Assigned to Kathleen

  • 10343 Three+additional+Signature.type+codes (Kathleen Connor) Considered for Future Use
    • need to work with some organization (e.g. HL7) to create three new vocabulary values. These vocabulary values need to be defined as OID values, because they are used in external standards that have a data-type of OID (i.e. XML-Signature). So they can't be text vocabulary, and they need to be fully OID.


Narrative improvements

  • 10580 How+should+test+data+be+identified%3F (John Moehrke) Considered for Future Use
  • 10581 something+should+be+said+about+de-identification (John Moehrke) Considered for Future Use
  • 12462 Security%2FPrivacy+Module+page+should+explain+W5+realty+that+provenance+elements+in+other+resources+vs+use+of+Provenance+as+a+resource (John Moehrke) Considered for Future Use
  • 12463 explain+relationship+between+Provenance+and+AuditEvent.+ (John Moehrke) Considered for Future Use
  • 10579 New+Security+and+Privacy+%22Module%22+page+needs+content (John Moehrke) Considered for Future Use
  • 11071 Improve+security+label+guidance+-+2016-09+core+%2390 (Kathleen Connor) Not Related
  • 12939 Security+Role+vocabulary+should+be+mentioned+on+the+security.html+page (John Moehrke) None


http://build.fhir.org/secpriv-module.html

Minutes