HL7 Security Working Group John Moehrke Security - mHealth and FHIR: mobile health applications and other Internet uses Security in HL7 Standards HL7 Security Working Group John Moehrke

Agenda Basic mHealth security Communications security User Authentication Authorization Relationship to Privacy Consent Audit Logging and reporting 3/27/2017

Overall view of mobile device security Functional, Operational, Physical, Procedural, Network, User, etc.. NIST 800-53 - Security and Privacy Controls for Federal Information Systems and Organizations NIST 800-124 - Guidelines on Cell Phone and PDA Security 3/27/2017

NIST 800-53 Control Families 18 Families related to Security Access Control Media Protection Awareness and Training Physical and Environmental Protection Audit and Accountability Planning Security Assessment and Authorization Personnel Security Configuration Management Risk Assessment Contingency Planning System and Services Acquisition Identification and Authentication System and Communications Protection Incident Response System and Information Integrity Maintenance Program Management 8 Families related to Privacy Authority and Purpose Individual Participation and Redress Accountability, Audit, and Risk Management Security Data Quality and Integrity Transparency Data Minimization and Retention Use Limitation

Risk – Scalable Security Risk Assessment is a general and natural process Risk Assessment is applicable to many levels of design and deployment Standards development – Security Cookbook Software design – Medical Device ISO 14971 Network design Deploying systems onto network – IEC 80001 Organizational – beyond network scope – ISO 27001 Nationwide Exchanges – IHE Affinity Deployment 3/27/2017

Risk Scenario In this scenario: The vulnerability is the hole in the roof The threat is the rain cloud Rain could exploit the vulnerability As mentioned before, risk level is measured in terms of a combination of the likelihood of occurrence (probability) and degree of impact (positive or negative) of an anticipated event. Going back to the “hole in the roof” scenario, the risk is that weather (the threat) could cause damage to components inside the building as well as the building itself. As long as the weather report shows that there is little chance of precipitation, our risk level is low. However, this risk increases as the likelihood of precipitation increases. Since we cannot control the threat of precipitation, we mitigate our risk by changing the vulnerability; we fix the hole in the roof. The cost of fixing the vulnerability is much less, in this case, than the damage rain or snow would cause. The risk is that the building and equipment in the building could be damaged as long as the vulnerability exists and there is a likely chance that rain will fall. 3/27/2017

Risk Management (ISO13335) 3/27/2017

Risks – Resource protection Wrong people get access Right people get denied proper access Right people see too much (consent) Unauthorized Create/Update/Delete allowed Right people get wrong data Perception that wrong people got access Wrong people get access Snooping on network Non-encrypted storage of data No access controls Bad RBAC Right people get denied proper access DDOS on service prevented good access Not PurposeOfUse Right People see too much (consent) Consent not functioning right Patient getting data before release Provider getting access to unfinished/unsigned report Unauthorized CUD Corruption of data through overrights Incomplete access controls Right people get wrong data Server not authenticated, so got a malicious service Client not authenticated, so got malicious object created Communications not integrity protected, so malicious man-in-the-middle Perception that wrong people got access Need audit logs 3/27/2017

NIST 800-53 Control Families 18 Families related to Security Access Control Media Protection Awareness and Training Physical and Environmental Protection Audit and Accountability Planning Security Assessment and Authorization Personnel Security Configuration Management Risk Assessment Contingency Planning System and Services Acquisition Identification and Authentication System and Communications Protection Incident Response System and Information Integrity Maintenance Program Management 8 Families related to Privacy Authority and Purpose Individual Participation and Redress Accountability, Audit, and Risk Management Security Data Quality and Integrity Transparency Data Minimization and Retention Use Limitation

mHealth = Security layers TCP/IP + DNS IHE IUA (2013) IHE MHD HL7 FHIR HL7/OMG hData DICOM WADO Continua … RESTful Resources Secure RESTful HTTP Transport Internet

Basic HTTP security Using HTTPS – Server side TLS/SSL No impact on resource content and encoding Authenticates server Encrypts and Integrity protects communication Does Not authenticate client Use Client Authentication  Hard to manage Does not authenticate user (see next slide) 3/27/2017

User Authentication Using HTTP Authentication Basic – username/password  Not scalable Form – username/password  Not plugable tech Kerberos  Doesn’t work well outside organization SAML – SSO profile  okay if enterprise focused oAuth  best if internet focused 3/27/2017

Healthcare - Access Control Healthcare needs are more complex But leverage concepts: RBAC, Policy, Tags, Enforce Privacy Consents special consent rules, episodic, expired, revoked Data not simply classifiable into Role Leverage clinical types but need Security Tags Policies point at data characteristics Sensitive Health Topics, Care-Team Break-Glass – safety medical judgement Residual Rules  Obligations 3/27/2017

HL7 PASS – Access control 3/27/2017

Access Control Engine Context Break-Glass PurposeOfUse Workflow Policies FHIR API User Role Authz Facility Patient Consent Care-team Deligates Resource Sec Tags Class Dates 3/27/2017

mHealth Access Control Deployment Models Human uses Application uses FHIR-API intermediated by Access Controls using FHIR-API 3/27/2017

Internet User Authorization (IUA) Sub-Authorizations user would otherwise have Use-Case: Simple browser app, mobile application, embedded device, and third party service Enables separation of concerns: User Identity, User Authentication, User Delegation of their Rights… Authenticable claims: user identity, user authentication mechanism, roles asserted, purpose of use asserted, policy pointers, .. oAuth 2.0: JWT/SAML token - Can be proxied to SAML Authorization is from user perspective and may not be same as resource perspective authorization Profile built from mobile application use-cases, but the same security needs as the SAML profile Used by: IHE, HL7, DICOM, Continua, others? Based on: RHeX, OpenID-Connect, NSTIC Supported by big internet providers: google, facebook, linkedin, salesforce.com Enables pluggable user authentication systems while isolating the service and application from variance 3/27/2017

Resource – Security Tags Developing story – stay tuned Leveraging existing work Security/Privacy DAM DS4P – Metadata use IHE XD* metadata model Vocabulary (HL7, OASIS, ISO, etc) Access Control engine – Uses FHIR API too FHIR resources have Provenance FHIR resources have Security Tags 3/27/2017

User Management Best Practice: Use federated identity Leverage security layer, abstract healthcare specifics from user management Internet or Corporate – oAuth or SAML FHIR Servers need to be careful which Identity Providers they trust, and for what reason Might be added to FHIR – for those that really want it, it should be there in a consistently usable way 3/27/2017

The Role of the HL7 Security WG HL7 Security Risk Assessment Process Provides training on the HL7 Risk Assessment process Gives direct assistance to WGs during the risk assessment process Liason to mHealth Liason to FHIR 3/27/2017

Conclusion Building off of advancements in general Internet Security Standards (HTTPS, oAuth, SAML, Dir) pluggable authentication Building off of healthcare standards Layering Security in a way that is usable for many Healthcare projects (Continua, DICOM, IHE, HL7) Embedding Security Tags into FHIR Resources FHIR – Security Audit Log Resource 3/27/2017

Resources HL7 * Security http://wiki.hl7.org/index.php?title=Security * mHealth http://wiki.hl7.org/index.php?title=Mobile_Health * FHIR Wiki http://wiki.hl7.org/index.php?title=FHIR IHE * web http://www.ihe.net/ * IHE Wiki http://wiki.ihe.net/ DICOM http://medical.nema.org/standard.html My blog http://healthcaresecprivacy.blogspot.com/ 3/27/2017