11/25/2021 | News release | Distributed by Public on 11/25/2021 15:26
A white paper was recently released to the FHIR community titled, "Playing with FHIR: Hacking and Securing FHIR APIs". This white paper was authored by a cybersecurity expert in penetration testing and provides some interesting insights into the vulnerabilities of implementing FHIR.
First the good news - no vulnerabilities were found in the HL7 FHIR standard itself. All of the vulnerabilities actually lie on the implementation side of things. Here is a summary of four key findings from the report:
The bad news is that these vulnerabilities are relatively elementary when it comes to hacking. In fact, these vulnerabilities are covered in the OWASP top ten risks. The existence of such vulnerabilities in the early adoption of FHIR makes it clear that as much attention needs to be focused on securely implementing FHIR workflows as there is on leveraging the standard itself for innovation.
FHIR has tremendous upside potential to transform the way data is shared in healthcare over the next decade. The ONC and CMS have put their trust in FHIR by mandating its use in recent rules related to the exchange of data among patients, payers, and providers. Rather than being a stumbling block, it is hopeful that this report will push the industry forward with a tighter focus on the security of FHIR implementations moving forward.
In meeting the regulatory mandates and unleashing innovation in general, a well thought out FHIR ecosystem must deliver on a number of key items including:
Securing data should be front-of-mind in any FHIR implementation. Implementing FHIR requires diligent implementation processes and an API security product, such as an API Gateway, to build your implementation strategy upon.
As for the discovered vulnerabilities in the report, a key focus area for any FHIR implementation should be to utilize the SMART on FHIR authentication framework. By enforcing SMART on FHIR authentication, which uses oAuth2 and scopes, one can limit access to only the authenticated patient and only the interactions allowed in the scope down policy. Thus, accessing multiple patient records from a single patient login account would be mitigated. In addition, appropriate oAuth2 grant types should be chosen for public applications, data should always be encrypted in-transit and at-rest, and of course database segmentation should be followed by aggregators.
While I think everyone in interoperability would like to see FHIR move forward at light-speed, there will undoubtedly be bumps in the road. I believe it can be a good thing that these vulnerabilities were identified, and hopefully it will put more focus on implementation and having the right security tools in place so that FHIR can move forward to change interoperability in the way that we hope.
Rob Brull, Sr. Product Director