Considering the recent “Playing with FHIR” research report together with the earlier “All that We Let In” research report (which looked at the state of mHealth app/API security), it would be understandable if healthcare organizations were unsure of what immediate actions they should take. In this article we will focus on healthcare service companies who have patient or clinician mobile apps, for whom we will recommend 3 immediate steps which should be taken today.
The latest report has certainly sparked a lot of debate about the security of healthcare apps and a broader discussion about who is accountable for keeping patient data safe as the ecosystem expands. The bottom-line is that everyone in the healthcare ecosystem needs to take steps to shield their APIs efficiently and effectively.
Following the release of the latest report, we hosted a very lively webinar with Alissa to discuss the report and the reaction to its findings. The audience asked many challenging questions and these, along with some which we didn’t have time to answer live, were captured in a later blog post. The breadth of topics covered in the post-report discussions reflects the diversity of the healthcare sector itself, hence we thought it would be useful to break down the immediate recommendations based on healthcare service provider type.
Quoting from the report, "...the weakest link in the security of FHIR API implementations is the last mile...", meaning that the most impactful actions which could be taken to improve the security picture relate to the technology and services that are directly accessed by patients and clinicians. The most obvious examples of this are mobile apps which are used to access healthcare services.
So, if your primary touchpoint with your healthcare customers is a mobile app, what positive action should you take from the FHIR API implementation security research? The answer is that you should implement the following 3 action points, if you haven’t already done so.
0% of mobile apps which were tested as part of the FHIR security research employed certificate pinning. Pinning helps mobile app developers protect mobile apps from man-in-the-middle (MitM) attacks - when a hacker intercepts or manipulates mobile device communications to gain access to sensitive information. However, despite its usefulness, it is often considered complex to understand and risky to implement, and hence isn't widely used.
Pinning allows mobile applications to restrict communication only to servers with a valid certificate matching the expected value (pin). The connection is terminated immediately if communication is attempted with any server that doesn't match this "expected" value. Here’s a webinar recording which covers the topic, including solutions, in detail.
Certificate pinning does not have to be difficult to implement, monitor and manage. And it delivers significant value in preventing your data and your API traffic from being intercepted. Check out our MitM whitepaper for further explanations and hints.
60% of the FHIR APIs tested were found to have vulnerabilities, some of them exhibited as many as 5 of the OWASP top 10 API security vulnerabilities. Almost all APIs have vulnerabilities, divided into the ones your organization knows about and the ones you don’t know about. It is of course very important to test for vulnerabilities regularly and to rectify any that are found.
However, more important than that is to ensure that vulnerabilities can’t be exploited. Noting that ALL of the exploits carried out by Alissa during the FHIR research utilized scripts which copied (aka impersonated) API requests coming from genuine software clients, it should be clear that the vast majority of attacks against vulnerabilities in APIs are done by automated scripts. Therefore it should be clear that the most efficient way to protect your business against exploitation of vulnerabilities, both those you know about those you don’t, is to block scripts from using your APIs. It seems obvious when you think about it.
Businesses relying on mobile apps as their customer touchpoint can shield their APIs by simply ensuring that all API requests come from a genuine and unmodified instance of their mobile app, executing in a safe mobile runtime environment, and that there is no man-in-the-middle intercepting or manipulating the traffic. Implementing such a shielding strategy is easier than you might think. Check out this API shielding webinar for more information.
To be clear, we are not advocating that you ignore API vulnerabilities that you find; we are saying that looking for and fixing API vulnerabilities is a constant and never-ending process that you must undertake. However, it is vital that you first implement a simple but effective API shielding solution so that attackers can’t exploit the inevitable vulnerabilities that will likely always exist in your APIs.
53% of the mobile apps tested in the FHIR security research contained hard coded API keys and tokens. Now, your immediate reaction to this might be “OK, but given that the API endpoint needs to see the API key to grant access, where am I supposed to store it in a mobile channel?”, and that’s a very reasonable question.
The point is not that API keys and tokens are stored in mobile apps, but rather that a). they are not well protected within the mobile app itself, and b). they can be used outside of the context of the mobile app. In security, context is everything.
Regarding making secrets such as API keys and tokens difficult to extract from mobile apps, remember that anyone can download your mobile app from the app stores and examine its code and its operation. Therefore you must use a comprehensive obfuscation/hardening tool on your app code in order to make introspection by bad actors much more difficult. There are free and commercial offerings in this area and for further information, a comparative review of your options can be found here.
It’s important, however, to recognize that you can’t assume that your API keys and tokens are safe just because you have protected your mobile apps. What happens if your API key was erroneously left in a github repo, or the key gets intercepted in transit? Therefore it is necessary to ensure that your keys and tokens can’t be exploited at scale.
In this context we return to the scripting attacks which were discussed above. These scripts will of course require an API key to succeed. Therefore you must ensure that the API key by itself is not enough to gain access to backend resources. Implementing a second factor through app authentication, analogous to two factor authentication which is commonly adopted for users, is a required step to prevent API abuse. You can read more on this topic here.
You're running a healthcare service and that must be your main focus. Security is important of course but it mustn’t distract you from your core activities. Good security hygiene can be implemented quickly and easily and without you and your team needing to become security ninjas.
Find solution providers who have a proven track record in delivering ongoing protection for businesses like yours, can deliver the 3 capabilities described above, and rely on them. Security is never done and you need to establish a relationship with your chosen solution providers to ensure that you are up to date with the latest threats in your sector. Choose wisely but also choose quickly.
Approov can help your business secure its mobile APIs quickly and effectively. Want to learn more about how we help dozens of companies ensure that only their mobile apps can use their APIs? Book a demo.