Health care Fast Healthcare Interoperability and Resources APIs are vulnerable to abuse by compromised apps and automated scripts, even those designed in accordance to FHIR guidelines, according to new report from Approov, based on research from cybersecurity researcher Alissa Knight.
The entirety of the app ecosystem examined in the report contained “pervasive authorization vulnerabilities” that enabled Knight to access more than 4 million patient and clinician records with just a single patient login account.
In fact, every tested FHIR app enabled API access to patient health data belonging to other individuals. And over 60% of the tested apps and APIs had flaws that enabled unauthorized access to data outside of the authorized users’ scope.
To compile the report, Knight examined three FHIR APIs across an app ecosystem of 48 FHIR apps and APIs and aggregated EHR data from more than 25,000 health care providers and payers.
While the report found that the EHR platforms examined in the study had good security in place, third-party clinical data aggregators and mobile apps were a completely different story: with “widely systemic” vulnerabilities that allowed access to EHR data.
The report makes it clear that the vulnerabilities aren’t inherent to FHIR, rather, it’s how the blueprint is implemented as it’s up to the developer. In short, “hackers are efficient and will always locate and exploit the weakest link in the chain which, based on this report, is in the healthcare data aggregators and mobile apps which rely on EHR data to deliver their services.”
Further, 100 percent of the mobile apps tested by Knight did not prevent person-in-the-middle attacks that could allow attackers to harvest credentials and manipulate or steal patient data. Fifty-three percent of the tested mobile apps used hardcoded API keys and tokens, which could be leveraged by a threat actor to attack the EHR APIs.
As for the clinical data aggregators, 50% did not implement database segmentation allowing access to patient records belonging to other apps developed on their platform for other providers.
Critical risk to patient data, As HHS drives interoperability
The primary, pressing concern is that the use of APIs is crucial to the Department of Health and Human Services’ info blocking and interoperability rules, which will be supported by the Trusted Exchange Framework and Common Agreement. TEFCA is slated to go live in 2022.
The HHS Office for the National Coordinator selected FHIR as the API specification from which these processes will be built. Following the announcement, most industry stakeholder groups expressed support for the use of FHIR and APIs for data sharing across the sector.
But during the initial comment period in 2019, several stakeholder groups raised several privacy and security concerns that could be introduced by leveraging APIs without an industry standard. In particular, the Medical Group Management Association urged ONC to design a process to create assurances that third-party applications meet minimum security measures and ensure patients are educate on rights, responsibilities, and threats to their data.
MGMA also expressed concerns with health care data that falls outside of The Health Insurance Portability and Accountability Act, which is one of the biggest challenges with these ongoing initiatives. AMIA added that Congress needs to address these gaps in consumer protections before fully enacting these rules.
As noted in the report, app developers and data aggregators are joining the health care ecosystem, blurring the lines of data privacy. It’s likely part of the reason the Federal Trade Commission reaffirmed it would be enforcing its long dormant Health Breach Notification Rule on Sept. 15, which applies to all entities that interact with health care information.
“When this future is viewed alongside the current reality of scant consumer protections outside the HIPAA-regulated environment, the near-term goal espoused by the ‘without special effort’ clause in Cures [Act] has the real and significant potential to create privacy risks and opportunities for fraud,” the American Medical Informatics Association wrote, at the time.
“[AMIA] does not raise these concerns to advise ONC against proceeding with these policies,” they continued. “The challenges posed to privacy, fraud, and abuse in the near-term API-driven future are far too large for ONC to handle on its own.”
Recommendations
The report calls for an urgent application of API security shielding solutions, which would prevent exploits of mobile health care app ecosystem vulnerabilities. The use will “immediately protect sensitive personal data from exfiltration while the underlying vulnerabilities are addressed.”
Congress and the Department of Health and Human Services are being urged to ensure the info blocking rules provide a mechanism, such as control reviews and pen testing, for service providers and EHR vendors to assess the security of API aggregators and application developers that connect to their API.
HHS must clarify that the info blocking rule’s security exception allows EHR vendors to require specific controls for any system that connects to their APIs, while reinforcing security guidelines with requirements for tokens and scopes — rather than recommending the use. The application of which would ensure all entities that interact with EHR are properly secured.
Regulators should also mandate the implementation of certificate pinning for all SMART on FHIR mobile apps, as well as shielding solutions to ensure only legitimate apps and users can communicate with the APIs.
Recommendations for FHIR API owners include an assessment of configuration of third-party apps prior to allowing them access to the EHR, implement API threat management solutions, and pen testing, performed by a third party with specific API testing experience.
The researchers warned app developers that “obfuscation of mobile app code to secure source code against decompilers isn’t enough.” Developers must leverage run-time shielding, as well, which will prevent any tampering of the app and its environment.
The apps and devices must also be authenticated with SDK-powered solutions using a token for the APR request. The solutions should eliminate developer friction and limit disruption to the software development lifecycle and improve hardcoded app privacy.
The report contains a complete list of vulnerabilities, possible tools that could better support FHIR API providers, and the recommended steps to solve some of these core issues, prior to the full enactment of the interoperability rules.
Approov “sees it as a positive step that open APIs are already creating a plethora of health care services which are being adopted and appreciated by patients and consumers,” David Stewart, Approov CEO, said in the report.
“However, health care organizations and regulators who handle and oversee this sensitive data must give equal attention to security enforcement as they do to empowering citizens to take control of their patient data,” he added.
