APIsecure 2023 - All #FHIRed Up, John Moehrke

APIsecure 2023 - The world's first and only API security conference
March 14 & 15, 2023

All #FHIRed Up
John Moehrke, Co-Chair, Security Working Group at Health Level 7 International (HL7)

------

Check out our conferences at https://www.apidays.global/

Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8

Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io

Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/

Transcript

1. FHIR up the CyberSecurity Community John Moehrke (ByLight) Co-Chair: HL7 Security Workgroup Co-Chair: IHE ITI Planning Committee https://healthcaresecprivacy.blogspot.com/
2. Background - Healthcare newest Interop API definition - Please don’t hack without an invite. - Use all the tools and skills mentioned by everyone else - I will be focusing on additional factors when you know the FHIR API Keynote: Katie Paxton-Fear → read the API documentation
3. FHIR – https://fhir.hl7.org FHIR –Fast Health Interoperability Resources - But realistically “FHIR” has taken on an identity beyond being an acronym - Pronounced “Fire” – leading to many puns - Initially focused on delivery of Health Care medical treatment – Health IT. - Expanded to Healthcare support roles: Provider Directory, Healthcare Billing, etc - Primarily a RESTful model available in JSON and XML … - “Standard API”, but not a “standard implementation” - Many open-source implementations of clients and servers (HAPI is the reference)
4. FHIR Core - enabled for security/privacy • FHIR https://fhir.hl7.org • Based on platform of https, RESTful, json/xml, and oAuth • Well formed resources with profiling structure validator ◦ Data input can be validated to structure • TestScript resource for automated testing specification • Implementation guides and reference implementations • Not just for Patient Treatment purposes ◦ Security/Privacy Category: Patient, Individual, Business, Anonymous, Other ◦ Practitioner / Organization directory ◦ Vocabulary … but NOT secure or privacy protecting without Implementation
5. FHIR Core - enabled for security/privacy • All resources have well-placed security tags - .meta.security • FHIR has compartments designed-in ◦ Structured/coded data are more deterministic vs free-text • FHIR has structured datatypes to hold verifiable digital signatures • FHIR has Consent resource to support consent, dissent, and conditions • Break-Glass - a mitigation to risks to Availability when patient safety risk • Also FHIR Provenance and AuditEvent to aid with transparency • FHIR Signature datatype. Not well matured yet. • Permission resource under development … but NOT secure or privacy protecting without Implementation
6. Health IT market - FHIR as a standards based API specification – https://fhir.hl7.org - Safety - corruption can cause health harm or death - Privacy - exposure can’t be ‘revoked’ - Growing with many new software / app entrants - Not as careful regarding Privacy or Safety - Mature vendors are much better and have long standing process - Many open-source reference servers and clients - Many sandboxes available for testing Please be ethical, don’t knock without permission.
7. Finding FHIR servers - Metadata endpoint -> CapabilityStatement -> ‘defined’ supported API - http://hl7.org/fhir/http.html# capabilities - Tells you what “is” supported - Most servers do NOT implement everything in the FHIR standard …
8. oAuth is common - oAuth protection … most of the time - Profiled use-cases and scope pattern - SMART App Launch - http://hl7.org/fhir/smart-app-launch - Clinician (user) vs Patient vs System - Often based on OpenID-Connect - Often app is authenticated with client id / password - Trending toward certificate backed application registration - CORS is commonly enabled - Biggest historic opportunity – where most things go wrong today …
9. FHIR Specification opportunities - http RESTful CRUD - Some search parameters are more powerful - _include and _revinclude - automatic navigation to other - _summary, _history – are they as well protected - _total – side channel leakage - _query, _filter - complexity of search - paging - less than full page, next encoding - patient/subject - navigate to other patient - .id - abuse - html text - elements should be constrained html - Datatypes - abuse - Write over read-only
10. And there is more - GraphQL – http://hl7.org/fhir/graphql.html - Bulk Data Access - https://hl7.org/fhir/uv/bulkdata/ - Operations - http://hl7.org/fhir/operations.html
11. Test for overall Privacy Principles Health IT is very Privacy sensitive - Not keeping to posted Privacy Principles - Not keeping to agreed Privacy Consent - Not tracking access, use, and disclosure - Patient should be able to see when their data are used - Not regularly finding audit log evidence of inappropriate access - Real-time detection of abuse - Maintaining data beyond appropriate data lifecycle
12. 12 Questions? John Moehrke Consultant with By Light Gmail JohnMoehrke @JohnMoehrke@techhub.social healthcaresecprivacy.blogspot.com