1. 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

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

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

4. 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

5. 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

6. 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

7. Risk Management (ISO13335)
3/27/2017

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. HL7 PASS – Access control
3/27/2017

15. 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

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

17. 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

18. 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

19. 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

20. 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

21. 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

22. Resources
HL7 * Security * mHealth * FHIR Wiki IHE * web * IHE Wiki DICOM My blog
3/27/2017