Scribe: @Suzanne Gonzales-Webb
Weekly calls Tuesdays 3PM ET
FreeConferenceCall Online Meeting Link https://www.freeconferencecall.com/join/security36
Dial-in Number (United States): (515) 604-9567 Access Code: 880898#
Motion to Approve with amendment to update # of approval 10/15 Minutes
Moved: Beth Pumo Second: Matt Blackmon
Carrie Hammond abstained
|PSAF Provenance NIB|
Kathleen - Review and request approval for PSAF Vol 3 Provenance to proceed to next ballot opening 20191227, closing 20200127. Normative 3. Project 914
Description of Proposed Document: The Privacy and Security Architecture Framework (PSAF) Provenance Volume 3 is the remaining PSAF volume to be balloted as normative. This ballot rectifies approved disposition changes from the September 2019 ballot including clarification that scope includes both enterprise and federated architectures, the normative vs. informative portions, and various simplifications and corrections noted by commenters. It does not extend the substantive content beyond responding to September ballot comments.
Summary of changes of material interest since last ballot: Changes include clarification that scope includes both enterprise and federated architectures, the normative vs. informative portions, relationship to other Provenance standards, and various simplifications and corrections noted by commenters.
Motion to Approve submission of PSAF Provenance Volume 3 NIB
Moved: Beth Pumo Second: Matt Blackmon
Carrie Hammond abstained
Share with Protections
Update on SwP Part 1 and Part 2 (to be presented Drafts). Recommend FHIR IG PSS for SwP.
DaVinci IG Privacy and Security Considerations
Continue discussion 10/29 because DaVinci team has conflicts
Mohammad Jafari and Kathleen offer additional Privacy and Security Considerations for
John suggested possible additions to Security Module AnonymousRead, or BusinessSensitive classifications http://build.fhir.org/security.html#Anonymous as well.
Proposed Privacy Considerations:
The following privacy risks should be considered and addressed by both the formulary mobile application and the formulary service developers. Note that this IG is focused on the specification of the formulary service and does not discuss details of the formulary mobile application implementations, therefore, this is not a comprehensive list of privacy risks and considerations for the formulary mobile applications; mobile app developers must seek other resources to ensure the protection of consumer’s privacy.
- The formulary mobile app SHALL NOT send any information which can directly identify the consumer (e.g., consumer identifier or name) when querying a formulary service, including in the HTTP headers. A conformant payer formulary service SHALL NOT require formulary mobile applications to send any consumer-identifying information in order to query for the list of health plans provided by that payer and the medication costs for each plan, specific to the consumer's set of medications.
- Any information that can identify the mobile app (e.g. OAuth client ID ), even if it does not directly connect the app ID to a consumer, can be used to correlate and cross references the pattern of requests from the mobile app. This can significantly increase the risk of compromising consumer's privacy by inference, including by cross-referencing with other information such as public databases. Even more general identifiers such as the request IP address of the formulary mobile app, when paired with the details of the queries (especially in the case of uncommon drugs) can lead to statistical inferences about the consumer and can lead to compromising consumer’s privacy.
- While API client authentication is often necessary for business reasons (e.g., protecting access to the service, billing, and rate-limiting), access to the formulary service SHALL NOT require any authentication which ties the mobile app to a consumer identity and the server SHALL NOT maintain any records that could associate the consumer with the medication list that was queried.
- Any information uniquely identifying the formulary mobile app (e.g. OAuth client ID) SHALL be subject to privacy-protective measures if recorded for audit or quality assurance purposes on the service side, since it can potentially lead to divulging or narrowing down the identity of the consumer.
- Formulary mobile applications SHALL use the POST (as defined by the [FHIR REST API specifications](https://www.hl7.org/fhir/http.html#search)) method and only include the parameters in the body of the request. This is especially important for for queries that include formulary drugs codes, to ensure that the drug codes are in the body of the HTTP request and do not appear in the HTTP request URL, which are prone to being logged by intermediaries (e.g., proxies, reverse proxies, load balancers, and TLS terminators) together with the IP address of the client. This mitigates the risk of leaking query details in logs.
-Because patient information shared between the Client and the Formulary Service is released under HIPAA Individual Right of Access directive, and is thereafter offered little protection beyond Consumer protection laws, a Formulary Service SHALL only accept POST queries that only pass sensitive search parameters in the HTTP body. For detailed guidance, see the Security and Privacy Module sections...(hoping John Moehrke can provide the correct references.)
Data sharing practices of medicines related apps and the mobile ecosystem: traffic, content, and network analysis BMJ 2019; 364 doi: https://doi.org/10.1136/bmj.l920 (Published 20 March 2019)
Grahame Grieve: It's been brought to my attention that some members of the community are seeking to prohibit the use of GET for search requests in particular IGs, and possibly more broadly.
I think we should have a clear view on this across the community. Some background:
For these reasons, the specification has never made any rule about this not using GET, but it does say that servers SHALL accept POST searches, mainly for this reason, so that clients can use POST instead of GET if they want.
Individual IGs are welcome to make their own rules, but in general, I would recommend against hard SHALL NOT use GET, since this is actually based on bad threat analysis (as outlined above). I would recommend that
John Moehrke: I think it is appropriate for us to state that there exists a risk of un-managed audit logging (managed is by definition managed). I do not see that this risk of un-managed audit logs is a rational to forbid the use of GET and mandate of use of POST. (especially as Grahame points out there is nothing stopping an un-managed audit log from logging POST body).
Matt Blackmon: I would agree with the above.
I agree in that there is a risk of propagating the "misunderstanding" of "SHALL NOT use GET mitigates" a certain risk.
It also eliminates a potentially useful action (namely, GET) that may not have been fully explored or utilized. I don't have anything particularly in mind for this, but it seems dreadfully overly restrictive for what such a prohibition would actually deliver.
Finally, the existing recommendation to utilize https/secure transport mitigates much of this concern while addressing security in turn by measures at the proper layers of the OSI model.
Jenni Syed: Do we have anything about this in a security guide? It's such a common misunderstanding, I'm curious if we have a similar list of bullets and considerations for reference
Jenni Syed: I know we've talked about this quite a bit over the years
Lloyd McKenzie: We could also add guidance in the IG- guidance IG.
Mohammad Jafari: Adding my comment for the Security WG RE this:
There's also some draft language if we want to address and mention this in the security/privacy page.
I also think that instead of a SHALL NOT, we should suggest this as a possible design choice which mitigates some risks.
Jenni Syed: Interesting on assumption of TLS terminating. In public clouds, we've been given guidance that TLS in transit is recommended for all sensitive health data (which would matter depending on how deep the stack/logging goes)
Jenni Syed: I know of a few frameworks that default to logging bodies on POSTs for failure
Jenni Syed: And a few reverse proxies that parse bodies for similar TLS or URL manipulation issues for architectures referenced there
Jenni Syed: (to make sure the URL going outbound matches what the caller used inbound when behind a termination or proxy of some sort)
Jenni Syed: Essentially: everything your data transits through unencrypted has to be considered part of the model to protect data
No. Hence my proposal above to say something explicitly
k connor: RE • GG "any organization collecting logs of FHIR RESTful calls is a party to PHI and needs to manage their logs accordingly. Given a secure connection to the app server, only the organisation should have access to the call to log it"
Unfortunately, it doesn't matter that the organization has access to the logs in scenarios where the entities accessing the PHI in logs have no laws restricting how they use PHI, in particular, where a US consumer releases PHI to entities not governed by HIPAA (and now no longer PHI and perhaps vaguely governed by Consumer Protection laws), perhaps it makes sense for IG authors to restrict queries to POST especially when their IGs are about "Consumer-centric control of their information.
Thankfully, some are developing API consumer privacy protective guidelines such as Xcertia Guidelines https://xcertia.org/wp-content/uploads/2019/08/xcertia-guidelines-2019-final.pdf and CARIN Alliance Code of Conduct https://www.carinalliance.com/wp-content/uploads/2019/05/2019_CARIN_Code_of_Conduct_05082019.pdf, which may decide that restrictive conformance requirements are appropriate for the policy context in which they operate. Providing approaches to Sharing Consumer Information with Protections would be a useful FHIR P&S, to which IGs wishing to distinguish their Consumer Centric Capabilities could assert conformance.
That's the core confusion here: if the organization is collecting logs, it doesn't matter whether you use a post or a get since they may collect the bodies.
k connor: Those able to log PHI because they're the end point is one problem that can't be solved with POST vs GET. It's the intermediaries logging the GET HTTP headers, who aren't even covered by the Consumer Protection Laws that are the other issue.
The whole idea that intermediaries only log the URL is bad security analysis that we shouldn't allow
k connor: The US FTC has some consumer protection laws if the terms of agreement in Apps are not followed. No protections against intermediaries for the most part. Even HIPAA X12 transactions have to be opened beyond the envelope by whatever Clearinghouse among any number of Clearinghouses (and not necessarily with Business Associate Agreements with the Source/Recipient Covered Entity) happens to need to find out the transaction end points. Likely there needs to be more analysis/research on existing analysis about the lack of protections by intermediaries. I don't think any of us has enough research to make any assertions about what intermediaries are doing with GET Header or POST Header/Body. Doesn't hurt to try to minimize damage. Suggest that a more comprehensive review of the literature/practices be done so that we can give appropriately tuned guidance about the risks HL7 implementers should be considering/mitigating against.
k connor: May want to check out Data sharing practices of medicines related apps and the mobile ecosystem: traffic, content, and network analysis BMJ 2019; 364 doi: https://doi.org/10.1136/bmj.l920 (Published 20 March 2019)
k connor: Here's FTC Medical App guidance https://www.ftc.gov/tips-advice/business-center/guidance/mobile-health-app-developers-ftc-best-practices
Laura Hoffman: The ONC and CMS interoperability rules are going to require providers to push health information to consumers via apps at a pace never before seen. There are no substantive privacy protections for consumers using apps and since the information is leaving the covered entity space, HIPAA obviously won't apply. Certified APIs should need to check for app attestation to whether they adhere to industry guidelines around app development and data use (Xcertia Guidelines, CARIN Code of Conduct, FTC Best Practices), as well as whether they provide consumers with easy-to-understand, model privacy notices (e.g., ONC's Model Privacy Notice). Otherwise apps are free to do what they want with health information on patients and their families.
Grahame Grieve: right. So obviously there are concerns here, and only using POST is a mitigation.. but my point is - it's a very minor mitigation, far less than people think. Doing your client crypto good is a far better protection, to reduce the prospect of accidental leakage - you will be connected directly to the source, who can log whatever they want
Mohammad Jafari: Intermediaries can indeed log POST bodies but in most cases they don't because that will lead to large volume of log data. It's much more likely for intermediaries to log URLs than full HTTP bodies. Note that this is about the customery configurations rather than what each entity can technically see and log.
2019-10-21T14:20:41-07:00 test heroku/router at=info method=GET path="/endpoint?parameter1=value1" host=test.herokuapp.com request_id=87eef4da-3eb2-4cdc-a9ee-914607fbbaa9 fwd="126.96.36.199" dyno=web.1 connect=0ms service=42ms status=200 bytes=515 protocol=https
Once again, people can configure things to cease generating these logs or filter them. What we are saying is that using POST is also an additional mechanism to subject sensitive parameters to less exposure and mitigate the risk of exposure via logs due to possible misconfiguration. This is not about a definitive prescription; it's just bringing to attention a possible mitigating measure.
Grahame Grieve: so I agree to bring it people's attention as a mitigating factor. But not to support that by bad analysis.
|PSAF Provenance Volume 3 Ballot Reconciliation|
Kathleen - Discuss proposed resolutions for block vote 10/22 call.
Jonathan Coleman comments 67 - 74
Also request a block vote on Beth Pumo's comments 58-66.
Next week, we plan on block votes for Bernd Blobel, and votes from Netherland Affiliates.
Reviewed dispositions. Block vote for 58 - 74 approved.
Moved: Mike Davis Seconded: Beth Pumo. Carrie Hammod abstrained
Comply with Policy Obligation Codes Proposal
Create a new Specializable parent [CPLYPOL in the ObligationPolicy ActCode system under which the various policies requiring compliance can be nested. Add a new ObligationPolicy_CPLYPOL_CPLYCUI to support emerging US realm need to inform recipients of Federal Agency source Controlled Unclassified Information (CUI) that they must comply with the applicable laws, regulations, executive orders, and other guidances, such as included in DURSAs, to persist, mark, and enforce required CUI controls. Add a Comply with Jurisdictional Security Policy.
Update current CPLYPOL to be a Specializable parent of
CPLYJSP (comply with jurisdictional security policy)
Custodian security system must retrieve, evaluate, and comply with applicable jurisdictional security policies associated with the target information.
CPLYCUI (comply with controlled unclassified information policy)
Custodian security system must retrieve, evaluate, and comply with applicable US Controlled Unclassified Information (CUI) policies associated with the target information.
Change Leaf Concept PRIVMARK to Specializable with a CUIMark child concept Proposal.
Create Leaf Concept
CUIMark (display CUI Mark)
CUI Custodians must create, persist, display, and convey computable and human readable security label CUI tags as required by CUI Marking policies including US 32 CFR Part 2002 and US Executive Order 13556 "Controlled Unclassified Information . CUI Custodians must enforce CUI Security Controls per applicable CUI policies.
Custodians include a CUI classifier of original CUI content; or a CUI derivative classifier, which reclassifies CUI content that has been aggregated with other CUI or Unclassified Uncontrolled Information (U) or dissembled from a larger CUI content
Recipients of CUI tagged content, CUIMark Obligation security labels must consume, persist, display, and enforce CUI controls per applicable CUI policies.
Usage Note: Applicable CUI policies include:
Add Upgrader Role Code Proposal
Add UPGRDER as a child of RoleCode_AffiliationRoleType_AgentRoleType
An individual authorized to raise the classification level of labeled content and provide rationale for doing so as directed by a classification guide.
Reviewed several substantively complete proposals and put on notice that several additional technical corrections/specializations of current codes will be submitted by initial deadline for subsequent review.
Approval of Initial submission of Harmonization Proposals
Moved: Kathleen Seconded: Beth
Carrie Hammond abstained
Note the call time has moved to 1PM ET, which is the hour after the CBCP calls.
John reported out on discussions related to proposed Change Requests for 3 Security Label extensions on codings with the following DataTypes:
Annotation: To support CUI display requirements and the Designator's Agency name/contact information
RelatedArtifact : To support references to specific Policy or Consent Directive governing the Security Labels assigned to FHIR Resources
Contributor: To support indicating the role of an entity that orginates or reclassifies a Security Label
Kathleen to submit Change Requests for these items.
Discussion thread on Zulip @ https://chat.fhir.org/#narrow/stream/179247-Security-and.20Privacy/topic/Proposed.20extension.20for.20CUI.20codes
|WGM Report out|
Kathleen - Draft WGM Minutes - in process.
Kathleen has not had time to complete these WGMs to date.
|(SP) 800-207, Zero Trust Architecture|
Mike Davis: Should HL7 Sec WG provide comments on NIST Zero Trust Architecture relevant to standards work? Reference HL7’s PSAF Vol 1 with links to relevant sections such as Fig 7, 9, 12, 18 etc.
|Mike will continue his review and report to WG about any healthcare specific use cases about which the WG would like to recommend that HL7 PAC develop/submit comments. Due date is11/22. To review NIST SP 800-207 and provide input please check (SP) 800-207, Zero Trust Architecture|
|Federal Health IT Strategic Plan|
Mike Davis Should HL7 security comment on Federal Health IT Strategic Plan –
|Mike will provide links to this document once it is publicly available.|
|Adjournment||Meeting adjourned at 4PM ET|
Temporary Meeting Recording: https://fccdl.in/XWfrXbMAsy
John Moehrke Co-Chair
Kathleen Connor Co-Chair
|VA (Book Zurman)||@Trish Williams Co-Chair||Flinders University|
Chris Shawn, Co-Chair
John Davis (Mike)
|Sequoia||Julie Chan email@example.com||HL7 FHIR|
|VA (Book Zurman)||Kaiser|
|VA (Book Zurman)||@Adam Wong firstname.lastname@example.org||HHS|
@Ricky Sahu, @1up.health
|EMR Direct||Laura Bright email@example.com|
|PJM Consulting||@David Staggs firstname.lastname@example.org||SRS|
|Ready Computing||Terence Cunningham email@example.com (Terry)||AMA|
|Trustworthy EHR||Laura Hoffman firstname.lastname@example.org||AMA|
|Heather McComas email@example.com||AMA||Matthrew Reid firstname.lastname@example.org||AMA|
|Stephen MacVicar email@example.com||MITRE||Saul Kravitz firstname.lastname@example.org||MITRE|
Robert Dieterle email@example.com
|Enablecare||David Staggs firstname.lastname@example.org||SRS|
|Carie Hammond email@example.com||Aegis|