Glad 2021 is now passed

 I am reminded of "This too shall pass.", and I really hope it is true. The past two years have been monotonous, with very little positive things to get excited about. That said, I expect 2022 will simply be a workhorse of a year with small advancements that are not clear today. Yeah, that is the most blah prediction.

The most positive is that my household family continue to be COVID-19 free. However I lost my father with COVID-19 as a factor. COVID-19 has been the healthcare story in the standards I work on, but is also the thing that is preventing the standards groups from gathering and being more productive. I don't mind the pace slowdown, and initially didn't mind the lack of face-to-face meetings, but lately I have found myself wishing for the face-to-face workgroup meetings. I likely just want some of the positive meeting dynamics, while noting that most of the time the meetings were compulsory and a waste of time.

The last time I did a year-end report was at the end of 2017 - HIE Future is Bright - stepping into 2018. Looking back at that report, it is rather disappointing that none of the expectations have been achieved, yet so much has happened toward the direction of each of these. The activities that have happened are clear now that they were necessary, but of course at the time it felt like everything was ready for progress.

"The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and then starting on the first one." - Mark Twain

Over the year, my blog saw mostly the same amount of visitors (90k), and I posted mostly the same number of articles (30). The biggest impact I had this year:

1. IHE whitepaper on Health Information Exchange models (3.7k)
2. From Implementation-Guide to IHE-Connectathon (2.7k)
3. Healthcare use of Identity level of assurance (2k)
4. When is a document not a Document but still a document? (1.6k)
5. Agile improvements toward #FHIR (1.5k)
6. Security of #FHIR implementations concerns (1k)

It is good to see that the Alisa Knight cybersecurity attacks on #FHIR were not a big reason for visitors to my blog. 

2021 Themes

Health Information Exchange using FHIR

• IHE conflicting Patient Identity Feed patterns
• Updates to IHE foundational #FHIR profiles MHD, PDQm, and PIXm
• IHE IT-Infrastructure fall 2021
• #FHIR Basic AuditEvent for generic RESTful actions
• FHIR Document Digital Signatures
• FHIR data in existing Nationwide Health Information Exchange
• Book: IHE Profiles for Health Information Exchange
• User Management on FHIR
• Healthcare use of Identity level of assurance
• IHE is on #FHIR
• Why use current Exchange infrastructure rather than starting over?
• Set of documents that are very focused #FHIR
• When is a document not a Document but still a document?
• Agile improvements toward #FHIR
• IHE ITI February 2021
• IHE whitepaper on Health Information Exchange models
• From Implementation-Guide to IHE-Connectathon
• Actual Consent is more important than more standards for Consent

Healthcare IT Security

• Mantras for Secure FHIR Development
• Please secure your #FHIR API and Apps
• Security of #FHIR implementations concerns
• #FHIR Basic AuditEvent for generic RESTful actions
• FHIR Document Digital Signatures
• InScope podcast: #FHIR security
• Healthcare use of Identity level of assurance

Presenting and giving Tutorials

• Mantras for Secure FHIR Development
• HIMSS presentation on FHIR CarePlan
• InScope podcast: #FHIR security
• Tutorial Links
• FHIR Security & Privacy Tutorial

COVID-19

• note I am big fan of the HL7 Smart Health Cards
• Elitism is Vaccine Credentials Passport
• COVID-19 Immunization Summary Document - use-case analysis

Fun

• A good hot beverage on #FHIR (April 1st)

Mantras for Secure FHIR Development

This morning I presented to the India FHIR-Connectathon on the topic:

Mantras for Secure FHIR Development

The slides are available in google slide desk. Summarized below ---

Alissa Knight -- White Hat Hacker

The New Healthcare Ecosystem will depend on FHIR APIs, but are They Secure?

My reaction

1. EHRs are doing a good job of securing their FHIR implementations
2. FHIR is good and worthy
3. There is room for improvement in some implementations
4. There are included recommended improvements.

Grahame’s reaction

1. The report explicitly notes that no vulnerabilities were found or are documented in the EHR FHIR implementations themselves.
2. Nevertheless, lots of vulnerabilities were found. All of them are very basic house-keeping stuff well covered in the OWASP top ten risks.

Media Hype

1. Many media outlets did not get the facts right at all. Or even the impressions
2. Don’t trust the media, read the report

Basic failure to secure

Resource-Server not enforcing scopes in the OAuth token

• Change the URL by the attacker (change the Patient id parameter)
• Given a read-only token, able to change data (change a medication of another patient)

Client/Server architecture where all data is sent to the Client

• A Patient Engagement App… the client was being used by a Patient on the Patients computer

Resource-Server not validating tokens

• Intercept a legitimate client app request, extract out the OAuth token, put that token into a request from your hacking client - so enforce timeouts and refresh cycles

Clients with hardcoded API keys in the app

• Not hard for a hacker to decompile your app and find keys

Hack yourself before someone else does it for you

• Your API or App will be attacked, better that you prepare
• Look to cybersecurity experts - this is both a skill and an attitude
• There are recommendations like from OWASP - https://www.owasp.org/
• OWASP top 10 API
• OWASP mobile top 10
• Don’t assume tokens are valid, don’t assume token authorizes the request
• Audit Logging of everything, and regularly inspect the logs for deviations
• Provide a way for Vulnerabilities to be reported
• Methods: https://securitytxt.org/, or https://dnssecuritytxt.org/, or https://disclose.io/
• Expect issues to be reported, and be prepared (first response matters!)
• OAuth and TLS have Best Current Practices written by experts

Questions are welcome

Please secure your #FHIR API and Apps

 Just updated the FHIR core spec Security and Privacy Module with a simple message, yellow highlight for the new text:

6.0.3 Security 

FHIR is focused on the data access methods and encoding leveraging existing Security solutions. Security in FHIR needs to focus on the set of considerations required to ensure that data can be discovered, accessed, or altered only in accordance with expectations and policies. Implementation should leverage existing security standards and implementations to ensure that:

• All communications can be encrypted to prevent unauthorized access.
• No information leaks when errors occur
• No active script content can be injected into narrative resources
• Full audit trails can be constructed and used to detect anomalous access patterns

For general security considerations and principles, see Security. Please leverage mature Security Frameworks covering device security, cloud security, big-data security, service-to-service security, etc. See NIST Mobile Device Security  and OWASP . These security frameworks include prioritized lists of most important concerns.

Recent evidence indicates lack of implementer attention to addressing common security vulnerabilities emphasized by OWASP top 10 API . Reviewing the OWASP Top Ten and OWASP mobile top 10  and ensuring those vulnerabilities are mitigated is important for good security.

The Security Checklist also added two new items

12 When using OAuth  - Consider the draft Best-Current-Practice for OAuth 

13. Security / Privacy Event Reporting  - Consider legal obligations and ethical obligations to provide a means for Security and/or Privacy Event Reporting such as security vulnerability, or breach.

---------------------------------  Revised to add these notes ----------------------------- 

Not on the FHIR standard, because it is a bit too prescriptive for HL7. These are the highest takeaways from the past month:

1. Bad API security
1. Take initiative, hack your own API before someone else does.
2. Resource-Server MUST enforce authorization tickets, don't just trust that a valid ticket is authorizing the request being made -- 
1. OWASP -API5:2019 Broken Function Level Authorization
2. OWASP -API1:2019 Broken Object Level Authorization
3. Don't assume any level of trust, always check tokens on EVERY transaction 
4. Don't allow hardcoded API keys
5. And my personal favorite, log events AND audit the logs - OWASP -API10:2019 Insufficient Logging & Monitoring
6. Look to CyberSecurity experts, there are many. There are many tools. 
1. HITRUST.org - they do have a useful cross-reference, and are risk based.
2. Security / Privacy Event Reporting 
1. One method of advertising HOW to contact your security people -- https://securitytxt.org/
2. An alternative using DNS -- https://dnssecuritytxt.org/
3. Great community effort, including policy templates, somewhat more oriented towards researchers:   https://disclose.io/
4. Guidance from CERT on Coordinated Vulnerability Disclosure  
5. Guidance from USA Department of Homeland Security-
6. First.org guidance on MultiParty vulnerability coordination
7. ISO 27000 compliance ISO 29147/2018 and  ISO 30111/2019
8. A commercial product (Luta) maturity model for vulnerabilities  https://www.lutasecurity.com/vcmm
9. a bit on bug bounties, which can be a very useful technique, but one must have a mature baseline in place:   https://bugbountycoi.org/framework/
3. OAuth Best Practice
1. OAuth 2.0 Security Best Current Practice
2. OAuth 2.0 - Security Considerations
3. TLS Best Current Practice