Injecting Mobile App Security into The HIPAA Healthcare Security Rule
Approov Mobile Security
Zero-Trust for Mobile Apps and APIs - iOS, Android and HarmonyOS
A proposed update to the HIPAA Security Rule to Strengthen the Cybersecurity of Electronic Protected Health Information was issued in June 2024. Comments were requested and Approov has proposed some changes. This blog outlines the Approov recommendations to strengthen The Rule, specifically around mobile apps on personal mobile devices accessing ePHI.
Background
The US Department of Health and Human Services (HHS or “Department”) has issued a notice of proposed rulemaking (NPRM) to solicit comments on its proposal to modify the Security Standards for the Protection of Electronic Protected Health Information (“Security Rule”). This was initially issued under the Health Insurance Portability and Accountability Act of 1996 (HIPAA) and updated with the Health Information Technology for Economic and Clinical Health Act of 2009 (HITECH Act).
The intent of HHS is to update the Security Rule in response to the evolving healthcare technology landscape, and to address new threats. The updated HIPAA Security Rule recommends that healthcare organizations implement advanced controls like mandatory encryption for all ePHI (both at rest and in transit), multi-factor authentication (MFA), network segmentation, regular vulnerability scanning and penetration testing, robust anti-malware protection, patch management, and configuration controls, while also conducting thorough risk assessments and maintaining strong access controls to limit unauthorized access to sensitive patient data. These are all valuable improvements but we believe it does not go far enough.?
Mobile app code is uniquely exposed: even when obfuscation techniques are used app code can be decompiled and analysed and this means that specific defenses are required. Traditional security approaches have proven insufficient for protecting these mobile healthcare apps and APIs and are difficult to maintain. Signature-based methods rely on known patterns and require constant updates, while anti-tampering measures can still leave APIs vulnerable. Even implementing robust Transport Level Security (TLS) can be problematic, since device environments are exposed and especially when devops teams resist implementing certificate pinning due to performance and availability concerns.
We believe that the updated HIPAA Security rule must address the specific risks presented by mobile healthcare apps running on personal devices.?
The Threats Exposed by Mobile App Usage in the US Healthcare System
The rapid adoption of mobile healthcare apps has been driven by the increasing demand for virtual healthcare services. Mobile apps are of course widely used by patients for access to healthcare data and "telemedicine" services such as consultations, prescription refills, appointment scheduling, accessing test results, etc. They are also used by practitioners to manage various aspects of treatment and healthcare data access. Practitioner apps are increasingly used from personal devices and outside the security provided by campus networks.?
An additional evolving threat window is the mobile apps associated with medical devices, which have become a distinctly efficient means of device access and control.?
Moreover, government regulations promoting interoperability and patient ownership of data in the healthcare industry have led to the widescale proliferation of APIs providing access to ePHI.
All of this presents an entire ecosystem of data-rich attack surfaces to hackers seeking to carry out multi-pronged attacks. These attack surfaces must be protected.?
The Need for More Specific Mobile App Protections in the HIPAA Security Rule
The following sections describe specific changes which should be incorporated in the updated Security Rule to improve mobile protections, covering the following topics:?
OWASP MASVS provides important guidelines for mobile app security, as well as useful resources for mobile app developers. We will refer to OWASP MASVS recommendations where appropriate in the following sections.
Defending Against Cloned/Modified Apps
Context: Mobile apps can be cloned and copied and their code can be manipulated. Fake apps masquerading as genuine healthcare apps have been deployed, sometimes downloading malware and viruses, and sometimes using stolen credentials to send well formed data requests to backend systems. In addition, app logic can be acquired and repurposed in scripts and tools, again with the intent of making API requests to access data or explore API vulnerabilities. OWASP MAS-Resilience focusses on app tampering.?
What HIPAA Security Rule June 2024 Says: The Security Rule extends the previous definition of authentication to “technology assets” in addition to “persons”. Authentication in the new definition, means corroboration that either a person or technology asset is the one they are claiming to be. This is intended to reflect the role played by technology assets in electronic information systems today but is very general and covers anything from client software to cloud storage. The guidelines do mention explicitly the case of individuals accessing their own PHI using an application that connects to the software that runs the covered health care provider's patient portal. In this case, not only must the individual be authenticated as a user, but the application must be authenticated such that the covered entity's software can verify that the application is what it claims to be. How this app authentication is carried out is not specified.?
Proposed Improvement: In the case of mobile apps which access ePHI there is a proven way to authenticate that apps which access ePHI are genuine and unmodified. App Attestation is a proven technique which prevents copying, cloning, or run time modification of apps and ensures that only genuine versions of apps can access APIs. Both Android and Apple iOS provide versions of app attestation and third-party solutions exist. App attestation should be mandated for any apps which access ePHI.?
Runtime Protection Against Device Environment Manipulation
Context: Because hackers have access to end-user devices, they can jailbreak (iPhone) or root (Android) devices, bypassing any vendor controls on the phone. In addition there are many tools such as Frida and Mitmproxy which can hijack the operation of a running app to steal data, secrets or modify the operation of the app. The controls in OWASP MAS-Platform aim to ensure that the app is running on a trusted platform, prevent tampering at runtime and to ensure the integrity of the app's intended functionality.
What HIPAA Security Rule June 2024 Says: The document does modify and strengthen the definition of “malicious software” in a way that can cover the types of tools which can be deployed on mobile devices (print page 926). However it is currently too general to address the specific issues presented by weaponized software running on mobile devices. The document also proposes that unique identifiers, including numbers or other identifiers, be assigned to each user and technology asset. The CPG for Unique Credentials, calls for regulated entities to use unique credentials to ( print page 966) help detect and track anomalous activities. Unfortunately this is too complex and impractical when apps are generally available on personal devices.?
Proposed Improvement: The Rule should be strengthened to explicitly cover the risk of malicious software running on mobile devices. This should include continuous scanning of any devices for problematic software, run time reporting of the state of device environments and the ability to block requests coming from compromised devices, in real time. Again, basic device environment validation is provided by Google and Apple and more extensive commercial solutions are available. Run Time Device Attestation of all device environments should be mandated by the Rule.?
Protecting against Man-in-the-Middle Attacks
Context: Man-in-the-middle (MitM) attacks occur when an attacker intercepts or manipulates mobile device communications to gain access to sensitive information. Attackers can extract login information, API keys and useful credentials from messages and can modify messages and intercept sensitive commercial or personal data, or even easily launch a denial of service attack against the service being accessed via a mobile app. Even use of TLS is not sufficient: if an attacker is able to modify the set of trusted device certificates, directly or via a device vulnerability, or fraudulently obtain a trusted certificate for the target domain, then a MitM attack is still possible. In mobile, because attackers can get access to devices, off-the-shelf tools can be installed to execute MitM, even when traffic is encrypted.
Certificate pinning replaces dependence on the device’s set of certificates with a limited set of certificates known and trusted by the app itself. This approach is recommended by OWASP to protect the communication from mobile apps to back end servers. Dynamic pinningimproves on this by building a secure pin update mechanism into the app logic so that pins can be dynamically and immediately updated across all apps when the certificates used by required APIs change. This eliminates any risk to service continuity when certs and pins change, which does unfortunately happen.
What HIPAA Security Rule June 2024 Says: The Rule does not directly address the issue of MitM attacks. The Rule does however cover transmission security, as well as some recommendations for network security, which seem grounded in a pre-Zero-Trust world of closed networks which no longer exists in practice. Encryption of ePHI both "at rest and in transit" is mandated by the Rule, but certificate pinning is not mentioned as an additional defense to protect encrypted traffic from being accessed.?
Proposed Improvement: Dynamic pinning should be implemented on all the communications channels healthcare apps use, including to 3rd party APIs. Certificates and pins should be managed independently from apps. The way the apps acquire and use the pins when they need them must be secure, and mechanisms must be available to update them immediately across all apps when they need to be changed. In addition any tools which enable Trust Store manipulation or MitM attacks from the device should be blocked - see previous section “Runtime Protection Against Device Environment Manipulation”. Use of certificate pinning should be mandated by the Rule.
API Secret Protection
Context: The most nefarious mobile attacks are when a hacker weaponizes a mobile app and uses it to scale up attacks on critical APIs. In order to carry out these attacks, all hackers need are API Keys which they can then use in scripts or modified apps. In the US Healthcare sector there have been numerous attacks involving API keys. A 2023 report stated that 79% of Healthcare organizations had experienced an API related security incident in the previous 12 months. API keys are notoriously easy to extract from app code or find in on-line code repositories. They can even be harvested via MitM attacks which intercept and inspect requests from the communications channel to your APIs. The management of API keys merits special attention in the HIPAA Security Rule. OWASP MASVS has a specific guideline, MASVS-CRYPTO-2, which specifies that apps must perform key management according to industry best practices.?
What HIPAA Security Rule June 2024 Says: The current document does not use the terms "API keys" or "secrets", but does propose strong authentication, access controls, multi-factor authentication, configuration management, and regular maintenance - in other words, a comprehensive approach to security and risk management that implies rather than explicitly states that the careful management of API keys and other secrets, and their regular rotation, is an important component of compliance.?
Proposed Improvement: We believe that API keys and other secrets are so critical to the US Healthcare ecosystem and their exposure in mobile apps so troublesome that this requires explicit guidelines in the Rule. The Rule should mandate that API keys for access to ePHI APIs are never stored in mobile app code, and are delivered only as needed, and only to apps which are verified via attestation. Storage and management of keys and secrets should be secure and it should be possible to rotate them across all apps immediately as required.
Run time Zero Trust Protection of Identity Exploits
Context: Identity theft and credential stuffing attacks are an ongoing threat to the US Healthcare sector.
What HIPAA Security Rule June 2024 Says: The document emphasizes the importance of strong authentication and access controls to protect ePHI, including MFA and password management techniques. The document proposes that regulated entities must implement technical controls that monitor in real-time all activity occurring in their relevant electronic information systems, and identify indications of unauthorized activity.?
Proposed Improvement: Additional controls should be put in place to protect against identity abuse. App and device attestation at run time, as described in previous sections of this document can provide an additional layer of zero-trust protection and prevent automated credential stuffing attacks, ensuring that even if an attacker obtains initial access, they will face additional hurdles when trying to escalate privileges or use stolen credentials to attack APIs. In addition, tracking signs of identity abuse should be called out as an explicit requirement for run time security monitoring.
Breach Readiness and Service Continuity?
Context: The "assume breach" mentality in Zero-Trust encourages organizations to prepare for potential security incidents, acknowledging that breaches can happen regardless of preventive measures. ZT recommends organizations should have established protocols for quickly addressing breaches, such as revoking access, quarantining affected systems, and conducting thorough investigations. For mobile, continuous monitoring and verification help mitigate the impact of security incidents. In addition it is critical to be able to react immediately: to update policies as threats evolve, to isolate compromised apps and devices, and rotate keys and certificates should breaches occur.
What HIPAA Security Rule June 2024 Says: The document stresses that addressing security incidents is an integral part of an overall security program and mandates a well thought-out, well-tested security incident response plan as integral to ensuring the confidentiality, integrity, and availability of a regulated entity's ePHI. The Rule cites Key Activities and Guidance from NIST (National Institute of Standards and Technology).
Proposed Improvement: In a complex ecosystem like the US Healthcare sector it is important that Incident Response plans extend to third-party breaches, for example if a third-party API used by a healthcare application is compromised, the application owner should have a contingency plan. The Rule should make this explicitly part of each entity's incident plan. The Rule should also explicitly highlight management of API Keys and certificates in the case of a breach - that there is a process and plan in place for rotating third-party API keys, as well as any other secrets and certificates the app uses. The Rule should also require specific procedures to quickly block rogue devices and compromised users without affecting genuine users.
Conclusion?
In our submission, we presented specific improvements to the “HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information” which take into account the proliferation of healthcare apps on mobile devices. The recommendations are in the following categories.?
Together these changes will strengthen the Rule and enhance the security of the US Healthcare ecosystem.?
Approov and US Healthcare
We have been very active in driving improvements to cybersecurity in US Healthcare, sponsoring major research on mobile healthcare app vulnerabilities and the risks to FHIR APIs. Read our Healthcare Mobile Security Brief and find more healthcare research here.
Approov are experts on app and API security. We would be happy to set up a call to see if we can help you quickly and effectively improve your healthcare app security.