January 24, 2023
Key takeaways:
- Tampering attacks in the medical and healthcare field have happened throughout history and bring real-life risks for patients and healthcare providers alike.
- A mHealth app is a logically sensible attack target for threat actors due to its high degree of interaction with many components in the healthcare system.
- Risk management planning for mHealth app tampering is complex due to the elusive and unpredictable nature of the risk, but automation can help simplify this process.
Recent advancements in technology have led to the digital transformation of the healthcare industry. This has consequently led to easier and more accessible healthcare, making our lives far easier and more comfortable. Moreover, healthcare providers can now tailor communication, diagnosis and treatment approaches based on the patient’s specific needs by leveraging the interconnectivity of modern technology, possibly through mHealth apps. As a matter of fact, the mHealth app market is predicted to exponentially grow from US$ 5.37B in 2021 to US$ 38.47B by 2029, a CAGR of 27.90%.
However, the increased opportunity to bring healthcare closer to the customer side has to be coupled with the increase in healthcare providers’ cybersecurity posture. Earlier last year, the US Department of Health and Human Services (HSS) highlighted a report that found a 69% increase in cyber-attacks targeting healthcare in the first half of 2022 compared to 2021.
In this blog, we are going to talk about mHealth app tampering in the healthcare world, its risks and implications, and how to mitigate them.
Tampering in the medical field
By definition, tampering is an intentional process of modifying something or its environment to alter its intended behavior. This unauthorized action has happened throughout the history of medical care, often with malicious intentions such as:
- Blackmailing and Extortion: E.g., The 1982 Chicago Tylenol murder case, where the alleged perpetrator laced the painkiller medicine with Potassium Cyanide and claimed the lives of 7 people. He later sent a letter to the manufacturer, demanding US$ 1 million to stop the murders.
- Killing and insurance scamming: E.g., The 1988 Excedrin tampering, where a woman laced her husband’s Excedrin capsules with Cyanide to get his life insurance money.
- Causing harm: E.g., The 2004 FDA warning after finding traces of extremely potent chemical poison, Ricin, in two jars of baby food in Southern California.
If threat actors are willing to go to these extremes to cause harm to an individual or a healthcare organization, an attack on a mobile app designed for healthcare purposes should be expected.
Tampering in mHealth apps
Fig 1. Tampered medical apps may be used to attack patients.
Medical and healthcare apps are designed to make patient and healthcare professionals’ lives easier. These apps interact with many components that the users utilize, such as wearable medical devices and hardware monitors for multiple purposes, including communication, record keeping, and diagnosis, to delivering treatments. These highly sensitive data and related functionalities are extremely attractive for threat actors, making mHealth apps a critical attack vector. Although mobile app tampering requires a certain degree of technical skills, it is significantly more scalable and more challenging to control compared to other physical tampering attacks.
Just like other medical devices, regulatory bodies such as FDA or EU-MDR prescribe developers and publishers to do their own risk management for their mHealth apps. You can use multiple frameworks to do threat modeling, including the S.T.R.I.D.E. framework that is recommended in the FDA playbook. You can learn more about the role of mobile app security in FDA approval for mHealth apps in this blog.
Tampering is an elusive risk
From the table below, you can see some examples of what tampering risks might look like in your risk charter. However, these risks do not represent even a fraction of what your mHealth apps could be facing. And despite all of the tools recommended by regulatory bodies such as the FDA, it is hard to plan for app tampering risk management.
|
FAILURE MODE |
RISK |
PATIENT HARM |
| A hardware-connected medical app maliciously manipulated to cause harm. | Unprotected apps can be modified to misuse the hardware device or deliver unreliable readings. | May cause severe harm or death to the patient. |
| A hardware-connected medical app reverse-engineered & unauthorized mods get distributed. | Unauthorized mods may not be as well tested as the genuine app, leading to bad device readings or damage to the hardware device. | Depending on the nature of the issue may cause severe patient harm. |
| An app with chat or other communication functions with medical professionals maliciously manipulated to cause harm. | Unprotected apps may be modified to redirect communication from the authorized medical professional to a malicious actor. | Malicious medical advice may cause severe patient harm or death of the patient. |
| An app containing or processing patients' data maliciously manipulated to eavesdrop on the patient's data. | Unprotected apps may be modified to send a copy of the patient data to a malicious actor. | Patient privacy breach. |
This is due to the elusive nature of the risk, the technical complexity of app tampering mechanisms, and the ever-evolving security landscape - not to mention the inadequate public data available. The International Organization for Standardization (ISO), even acknowledges that app tampering risk estimation is complicated:
Tampering is a “risk whose probability is very difficult to estimate” (ISO 14971:2007 Informative Annex D, D.3.2.3). Based on that, the standard prescribes estimating such risks as “it is usually necessary to evaluate the risk on the basis of the nature of the harm… and on the basis of a reasonable worst-case estimate of probability.” (further in D.3.2.3).
So what can you do about it?
Automating your mHealth app security on all Man-At-The-End attack stages
Guardsquare simplifies your benefit-risk exercise by automating the protection, testing, and monitoring of your mHealth apps throughout your software development lifecycle (SDLC). This ensures comprehensive protection for all stages of tampering attacks, from recon, execution, and distribution, all the way to automation.
Fig 2. Risk mitigation with Guardsquare
Our Android and iOS protection solutions, DexGuard and iXGuard, respectively, protect your mHealth apps against tampering by automatically applying multiple layers of code hardening and RASP checks. Our polymorphic protection approach resets the clock for threat actors, rendering the knowledge they gain from their prior attacks useless.
Our free app scanning solution, AppSweep, can be easily integrated into your CI/CD pipeline to improve your app’s security during the development cycle. This free, developer-oriented tool can help you identify and fix security issues and dependencies by providing actionable recommendations and insights, including OWASP MASVS categories.
Our real-time threat monitoring solution, ThreatCast, provides insights into the threats your mHealth apps are facing, allowing you to proactively analyze tampering attempts and adjust your security strategy promptly. This is especially useful to fulfill the postmarket surveillance requirements laid out by regulatory authorities such as FDA.
By implementing Guardsquare solutions into your risk management chapter, you can shift your focus on the apps' functionality without sacrificing the app's usability while continuously improving your security posture.
