Application programming interfaces (API) are being used by more healthcare organizations every year. The APIs help healthcare organizations to coordinate care for patients in a way they’ve never experienced. Interoperability is at an API’s core and it’s able to retrieve or send data that update’s a patient’s medical information into a system. The API makes things much faster and easier for healthcare organizations to send or store valuable patient data.
However, with the implementation of innovative technology, comes security risks. Yes, APIs seems like the ultimate solution to the healthcare industry’s interoperability issues, but there are still challenges when working with them. Because most healthcare organizations don’t manage their own APIs, it leaves the door open for devastating cyber attacks.
Cybercriminals know that the healthcare industry is not as prudent about securing their cyber environments as other industries and they will take every opportunity they can to infiltrate their systems and networks. Every day, threat actors are realizing how lucrative it can be to target APIs. The failure of traditional security measures is the prime reason why APIs are a favored attack vector for threat actors. Let’s take a look at what APIs are, API attacks/vulnerabilities, and how healthcare organizations can stay safe when using one.
Related reading: What Software Companies looking to develop for the Healthcare Industry need to know
In May 2022, Avertium published a Threat Intelligence Report regarding API attacks and best practices. An API is a software that allows two applications to communicate with each other. If you’ve checked the weather on your mobile phone, used a social media app, or sent an instant message, then you’ve used an API.
Healthcare organizations use APIs to help close the gap in how information is sent, retrieved, and processed. For example, it can be cumbersome to have to wait for every patient to get to a medical office to fill out forms, but APIs make the process simple, easy, and efficient for both the healthcare provider and the patient. Healthcare providers are now able to put a patient’s information into a system that works with insurance companies and that system can determine if the patient is covered for a particular medication or medical procedure.
When you use an app on your mobile phone, the app connects to the internet – sending data to a server. After the data is sent, the server retrieves the data and interprets it before sending it back to your phone. Once the application interprets the data, it then presents you with the information you wanted in a readable way.
Although it may appear as such, your phone’s data is not completely exposed to the server and the server is never completely exposed to your phone. Both your phone and the server communicate with small packets of data, and they only share what’s necessary.
In the past, APIs were described in generic terms as a connectivity interface to an application. However, today’s APIs are more complex and have characteristics that make them far more valuable than in previous years. Today’s APIs adhere to HTTP and REST standards and are developer friendly. They are also designed for consumption by particular audiences and are documented for consumption and versioning.
Prior to APIs, interoperability was quite tedious and daunting. Most healthcare organizations were sending, retrieving, and processing patient data through calls and fax machines. A healthcare clinic would call a local hospital to schedule surgeries or fax a patient’s chart over before scheduling a pre-surgical screening for their patient.
On the day of the patient’s surgery, a physical copy of the patient’s chart was given to the operating physician with the patient’s pre-surgical test results and their physical examination history. This would all have to be done weeks or days leading up to the surgery.
The process was quite tedious with a lot of moving parts, which means that APIs are much needed within the healthcare sector. APIs have the chance to revolutionize interoperability efforts within healthcare and to comply with the CMS Interoperability and Patient Access final rule, healthcare organizations are implementing APIs at a quick rate.
As we stated above, with innovative technology comes security risks. Imperva recently released a report analyzing API-related incident data and quantified the cost of API security. The organization found that the lack of security APIs may cause is $12 billion to $23 billion in average annual API-related cyber loss in the U.S. Globally, the average annual API-related cyber loss is between $41 billion and $75 billion.
According to Imperva’s report, the estimated losses are entirely avoidable. If organizations invested in properly securing APIs, their losses would decrease even if they continued to adopt APIs into their daily operational processes. The report also discovered that the healthcare sector is one of the largest adopters of APIs across all sectors. In 2020, healthcare API traffic grew by more than 400%. By 2021, health monitoring API use increased by 941%. Additionally, the report stated that there is an increase in account scraping, account takeovers, and malicious traffic surrounding API use.
According to the Daily Dot, in July 2022, a mental health app called Feelyou exposed over 80,000 of its users' email addresses. Up until the company issued a patch, anyone could obtain the personal email addresses of users and link them to anonymous posts by accessing the app’s GraphQL API, which didn’t require authentication. The security issue had been present since January 2022.
Because there are so many APIs currently available, attackers are seeing APIs as a new attack vector of opportunity. Threat actors are gathering the tools they need to exploit every vulnerability they can find in APIs. Also, organizations are not treating APIs in the proper way, instead, they are treating them as if they are standard web applications. Healthcare organizations aren’t doing enough to ensure that they’re being used safely.
Interestingly, the same attacks that stopped working on websites years ago, still work on APIs. If APIs are not secured properly, healthcare organizations run the risk of patient data exposure and cyber attacks. Cyber security content creator Alissa Knight conducted research on API vulnerability and the mHealth app. As a result of her research, she was able to access more than 4 million patient and clinician records with a single patient login account.
Knight tested three APIs, that serve a network of over 48 mobile apps and APIs. All of the APIs allowed her to gain access to health data from other patients by using one login. Fifty-three percent of the mobile apps Knight tested had hardcoded API keys and tokens that could enable attackers to infiltrate the APIs.
The most disturbing part of Knight’s research was that she didn’t use complicated hacking techniques. Her techniques have been described as “kindergarten cybersecurity”.
“There were no vulnerabilities found in the EHR companies themselves,” said Knight, discussing the report during the same YouTube Livestream. “These issues were found because of a lack of harmony and secure co-development with the integrators and the app developers. That is an important distinction here.” – Alissa Knight (FierceHealthcare.com)
There are many risks healthcare organizations face when dealing with APIs – one of them being Broken Object Level Authorization (BOLA). In Alissa Knight’s published report, she explained that BOLA is the most prevalent API vulnerability today. During Knight’s research, she found that in every API she tested and exploited, BOLA was leveraged to access data that she should not have been able to read, write, put, or delete.
In fact, many of the vulnerabilities Knight found, were BOLA vulnerabilities. BOLA is described as an insecure direct object reference or IDOR. IDOR means that a user is able to directly access resources they shouldn’t be able to access by way of user input functionality.
User input functionality can be carried out in various ways, including changing an ID somewhere the user can input information (i.e., cookies, URL, etc.). Because the API doesn’t check whether a user owns a resource before the user can do anything (modifying or deleting the resource), the API becomes vulnerable after the ID parameter has changed. This means that an attacker could gain access to a health care organization’s patient data, which then can be used for further attacks like targeted phishing attacks, complete account takeover, or social engineering.
APIs use an ID in the request, taking the form of UserIDs, UUID, cookies, URLs, and other forms. Evidence of a BOLA exists when changing the ID in the request allows users to gain access to information that they didn’t have prior access to. There is a way to prevent this from happening, but healthcare organizations need to implement API best practices to get a handle on the issue.
Another issue that makes APIs a risk to healthcare organizations is the fact that APIs are often managed by third parties or middlemen, and not the healthcare facility using the API.
Unfortunately, third-party APIs don’t always practice API best practices because they don’t need to adhere to HIPAA regulations – making patient data easily accessible for attackers.
Yes, using third-party APIs saves healthcare organizations time, but there are consequences.
Cybercriminals research business systems and try to identify weak tools and packages on targeted servers. These weaknesses open up many options for threat actors, depending on how well the third-party’s API was designed for security. The common vulnerabilities exposed by APIs that threat actors find include cross-site request forgery, denial of service, man-in-the-middle attacks, replay and spoofing, and unencrypted transport of data.
According to a Trustwave Report, the biggest API security risk is cross-site scripting (XSS) – an attack that’s used in 40% of all attacks reviewed in the report for 2018. SQL Injection (SQLi) and Path Traversal attacks were also used often and are used to steal data and credentials.
Related reading: How to Raise Your Organization’s Game to Combat Cybercriminals
Unfortunately, existing security measures don’t work for APIs in general and those measures are not stopping threat actors from stealing sensitive data and causing damage to an organization’s API. A lot of times, organizations will implement API gateways, API management tools, firewalls, and IAM tools to prevent API attacks. However, the truth is that those tools were not designed to prevent API attacks, and securing APIs comes with its own set of challenges. Those challenges include:
Related reading: Reducing Ransomware Risk in Healthcare
Fortunately, API attacks are preventable. To help keep your organization safe, implement the following:
Maintaining a robust security architecture can and implementing API best practices can help keep your healthcare free from threat actors seeking financial gain. Avertium offers services that prevent API cyber incidents and keep patient data secure:
What you need to know about healthcare APIs and interoperability | Healthcare IT News
API Attacks & Best Practices (avertium.com)
As API Adoption in Healthcare Skyrockets, Cybersecurity Risks Follow (healthitsecurity.com)
Mental Health App Had Data On Tens Of Thousands Of Users Exposed (dailydot.com)
The Biggest Security Risks of Using 3rd Party APIs - Ipswitch
All That We Let In: Hacking Mobile Health APIs (Part 1) | by Alissa Knight | Medium
Broken Object Level Authorization - Traceable API SecurityAs API Adoption in Healthcare Skyrockets, Cybersecurity Risks
Importance of API Security in Healthcare Grows as Cyberattacks Increase (healthitsecurity.com)
All That We Let In: Hacking mHealth Apps and APIs (Part 2) | by Alissa Knight | Medium
Broken Object Level Authorization - Traceable API Security
This document and its contents do not constitute, and are not a substitute for, legal advice. The outcome of a Security Risk Assessment should be utilized to ensure that diligent measures are taken to lower the risk of potential weaknesses be exploited to compromise data.
Although the Services and this report may provide data that Client can use in its compliance efforts, Client (not Avertium) is ultimately responsible for assessing and meeting Client's own compliance responsibilities. This report does not constitute a guarantee or assurance of Client's compliance with any law, regulation or standard.
COPYRIGHT: Copyright © Avertium, LLC and/or Avertium Tennessee, Inc. | All rights reserved.