November 21, 2017 Security Conference Call

Back to Security Main Page]]

Attendees

x	Member Name		x	Member Name		x	Member Name		x	Member Name
.	John Moehrke Security Co-chair		x	Kathleen Connor Security Co-chair		.	Alexander Mense Security Co-chair		.	Trish Williams Security Co-chair
x	Christopher Shawn Security Co-chair		x	Suzanne Gonzales-Webb		.	Mike Davis		x	David Staggs
.	Mohammed Jafari		x	Beth Pumo		.	Ioana Singureanu		.	Rob Horn
.	Diana Proud-Madruga		.	Serafina Versaggi		.	Joe Lamy		.	Greg Linden
.	Paul Knapp		.	Grahame Grieve		.	Johnathan Coleman		.	Aaron Seib
.	Ken Salyards		.	Jim Kretz		x	Dallas Haselhorst		.	Dave Silver
.	Oliver Lawless		.	Lisa Nelson		.	David Tao		x	Francisco Jauregui

Back to Security Main Page

Agenda

1. (2 min) Roll Call, Agenda Approval
2. (3 min) Review and Approval of November 14, 2017 minutes
3. (5 min) PSAF cancelled so no report out. Is Privacy Obsolete Study Group report - Mike has made substantial progress in his analysis of international Privacy Policies. - Chris
4. (10 min) SECURITY Sensitivity Codes Ready for final review and approval for submission by deadline. Possible additional clarification for MH. - Kathleen
5. (30 min) Need to Update HL7 V2 Privacy and Security section in HL7 v2. Should Security and CBCP collaborate on an update? Dallas Haselhorst, CISSP, GSEC, GCIH, GCCC, GCPM, GPEN, GMON, GCIA, author of the v2 Security risks will present on his articles (links at the wiki page) - Kathleen and Dallas
6. (5 min) FHIR Security Report out - Call later? - John Moehrke
7. (2 min) HL7 Response Letter ONC ISA 2018 Comments Submitted to ONC] - See Meeting Materials for highlights.

Minutes

• Chris Shawn chaired.
• Agenda informally approved.

Approval of November 14, 2017 Minutes, minutes reviewed

• (Kathleen/Suzanne) Vote: 0 objections; 1 (Beth) Abstention; 6 approve

discussion: re. Mike's comments

PSAF

• No meeting,

• Mike has made substantial progress in his analysis of international Privacy Policies
• Mike is lining up his international privacy framework/framework, analyzing if they are more restrictive especially respective to on-line tracking, etc. Mike will make the information available on the wiki page or in the study group listserve--Kathleen will let everyone know when that has been updated.

Security Sensitivity Codes

• one adjustment made (substance abuse disorders and mental health area)
  • discussion Ken Salyards, Jim Kretz, CBCP WG
• Mental Health - (need to confirm that Ken accepts)
  • in some jurisdictions, they treat MH as protective information above the norm. Kathleen added as a distinguishing characteristic. Please let Kathleen know if there are any objections--please send queries/comments to Kathleen (must be turned in within a 2-week periods to differentiate from psychiatric tendencies; Did discuss last week to determine if a sensitivity code should be added (March harmonization) sensitivity codes are added as use cases are added by policy.

Motion: To approve harmonization proposal (with above edits) as final version for harmonization

• Vote: 0 objections 0 abstentions 6 approve

Need to Update HL7 V2 Privacy and Security section in HL7 v2. Should Security and CBCP collaborate on an update?

• work that we do with security labels is out of scope for v2, we are already adopting security v2 labels--controls chapter (infrastructure, messaging) will accept the header (where we put the high-water mark). there are other topics which we work on such as access control; our WG has relationships with Access Control catalogs, we speak of accountability, trust frameworks, etc. ensuring that end users that access information are held accountable for xx prohibition.
• noted in the section that security labels are supported-- John M has sent out his concerns (via e-mail) in response to point out some of the items in v2. one question is if we should even both with v2---and in transition with FHIR
• John would like to see consensus in the WG; chapters in the v2 are controlled by the sponsoring WGs. the security WG does not have chapters in scope of v2.

Dallas Risk Mitigation article - Achilles Heel Article

• introduction; worked in hospital IT since college, also interface; currently security consulting to have companies make decisions based on best practices
• making healthcare better,
• synopsis - how valuable healthcare data is on the blackmark and it is extremely vulnerable.
  • HL7 is a fundamental blah(?) by using coming attack techniques--how an attacker could use

--and modifying data to use in real time; this is real-time problems. it's off the shelf software that someone would need to perform this type of attack.

• DOS attacks; the most telling item is that... (18.23)
• sending of unauthorized messages
  • using things that interface engineers that users use to send data (Figure 8); using tools of the trade to perform the attack
• ARP Spoofing
  • Figure 9
  • Man in the middle allows us to do 1. allows us to collect data (another system on the network which allows us to see data between two systems--whether collecting data to send off somewhere else. 2. ability to manipulate that data as well
  • HL7 uses MLLP,

Dallas received papers from Bernd Blobel (from 17 years ago); the research is Dallas did not see a lot of implementations based off the research. there have been many things that have changed in security--even in the way internet is set up. i.e. a firewall is just not enough. As we see more and more breaches, because systems inside the network are what is becoming compromised. this is relevant because the way HL7 is designed--they are sitting inside a firewall and are unencrypted. Dallas uses the analogy when people hear telnet and ftp--because they are clear text. they could be transporting must mundane information--it is a failure for PCI, but we have HL7 which is carrying the most xxx data and its xxx (25:00)

• encryption technologies that should be used...? VPNs- depends on where it is at for the data--it is very relevant to how this data is concerned.

most e-mail is secured through TLS servers (direct exchange)

mutual TLS -

• one of the ways that the way it received data was via HL&, using VPNs, some of the hospitals were segmenting traffic; however internal traffic--there was no security that appeared segmented. coming up with mutual TLS was this used? most of the time used VPN and did not use mutual TLS because received was not able to figure it out

Another mutual TLS - dealing with a large state HIE; asked Dallas why mutual TLS was not discussed---Dallas explanation was largely on system 2 interface engine. if you look at the MER? the SSL piece is an add on; when working with it it’s the job of trustor.

the other common response--HL7 is a messaging standard and nothing more. this is not how security works--its everyone's job that we are doing in everything we can to security the data. looking at interface engine, it’s using the MLLB standards and trying to communicate through that method. if a vendor wants to use hl7 it’s the same NLP(?)

security in healthcare is lagging; on this call, the security folk identify

HIE issues - interface transport - is this fairly security?

• most of the time from what the has gathered--most are done as VPNs, there are VPNs implementations which by in large are a security connections. where you need to be careful is that VPN at a firewall--the problem is if the interfaces (i.e. ADTs being sent to HIE...) if you are doing this, the often, the firewall acts as a VPN--dong the cyber sweep, encryption, the problem is before the data gets to firewall, there is a problem that someone may intercept.

you can also do a client to server use case; its s site to site rather than client to server

direct exchange

other items found - HL7 was discussed on Capitol Hill (unflattering); a security researcher (Hannes McCalvery?) focused on cyber security; John is a primary engineer behind IoT inhouse--and has the ear of the senators and congressmen; Hannes describes this as a hell of xxx' Scott rowletter - a technical CIO - when a person enters a healthcare facility, one of the last ... due to insecurity between these folks, they have a good understanding about what that means; talking about the biggest problem in healthcare that no one talks about. HL7 and security; it is not HL7 security WG. what do we do next, what needs to happen? how do we change this narrative where it involved with the security WG? one concern - there is always changing approaches to security; how do we provided guidance at a conceptual level but not bound to any protocol. if we can put any guidance in chapter one... referencing them to a wiki page where we could keep track of the specification. Dallas wrote a lot of the suggestion where they are almost timeless... if we at still using v2 in hl7 and none of those changes, recommendars are taking place are still valid. don't become so specific

Hannes quote is at the end of the first research paper, also in references and cited to the minutes from that capitol hill meeting. see Capital Reporting;

http://wiki.ihe.net/index.php/Audit_Trail_and_Node_Authentication IHE has xx for pointing to ATNA; specification for interoperability

Meeting Adjourned at 1413 Arizona Time --Suzannegw (talk) 16:13, 21 November 2017 (EST)

Meeting Recording: https://fccdl.in/fFk1toal3 (temporary link)

Meeting Material

• HL7 Response Letter ONC ISA 2018 Comments Submitted to ONC]

HL7 submits comments on ONC 2018 Interoperability Standards Advisory highlighting VA sponsored privacy and security standards: The Security and Community Based Care and Privacy Work Groups appreciate that HL7 Executive Board highlighted the Work Groups comments: "Considering the increased focus on security and privacy as health data is shared across providers, we have included various comments on the inclusion of security labels in Section I Vocabulary, and across a variety of interoperability needs in Section II. This includes: o The SAMHA stewarded NIH VSAC sensitive clinical code value sets, which enable the computable assignment of security labels; o The HL7 vocabulary referenced by the HL7 Privacy and Security Healthcare Classification System (HCS), which are used for security labeling across HL7 Product Families. This vocabulary is used or required by HL7 Version 2 CON and ARV segments, CDA Consent Directive, Data Segmentation for Privacy, and Data Provenance Implementation Guides; and the FHIR AuditEvent, Provenance, and Consent and Contract (typed as a privacy consent directive) Resources to convey computable privacy, consent, security, provenance, and trust policies."