When building mobile apps, many tend to think that the mobile platform provides the security needed. We have seen multiple clients come to us for Cybersecurity Verification, only to find that they didn’t follow the basic mobile security practices. There are multiple protections needed of the app, particularly for a medical device. Promenade wrote a blog about this awhile back but being such an important topic that is regularly forgotten, I will reiterate some of the important security controls.
Storage
Make sure stored sensitive such PHI/PII (Personal Health Information/Personally Identifiable Information) is stored encrypted with keys of at least 2048 bits. The tools to encrypt are readily available for the developer; no one needs advanced cypher expertise. But assuming security by obscurity is not a strong position to take, and not justifiable to your regulatory auditor.
Note also that the best encryption is only as good as its secure key storage. Creating a great key but storing it directly with the data is just head-scratching. Google’s Keystore or Apples KeyChain should always be used for storing passwords and keys.
Network
Ensure all traffic to servers uses TLS. Use HTTPS, not HTTP and verify it is used under all circumstances. Developers can inadvertently use low level APIs that do not ensure use of TLS. To ensure a secure channel, it is also advised to only use specific Certificate Authorities (CAs) (certificate pinning).
Updates
Allowing your app to run on old versions of the OS makes your app exposed to the known vulnerabilities of that version. Many OS updates fix security vulnerabilities, so make sure your app requires the latest OS version to run.
And it’s not just the OS. More than 90% of your app is from 3rd party libraries, so regularly review your app’s SBOM (Software Bill of Materials) for known vulnerabilities.
Security is like whack-a-mole; it’s a moving target. To keep up, you will need to be able to enforce updates to your app appropriately.
Code Obfuscation
Code Obfuscation is something that app developers rarely think about but is pretty easy to reverse engineer most apps built. This means the source code can be read directly from the loaded app, and an attacker can see how the internals work. Being able to view the code is not only a potential loss of intellectual property, but also a security risk. The first step to tampering with an app is understanding it. When doing Penetration tests for clients, we have found all sorts of clear vulnerabilities visible from the reversed engineered code, (including hard-coded passwords and back doors). Make sure the code is obfuscated to make reverse engineering really hard.
Platform Integrity
We expect our mobile OS to be secure, but it is imperative to check for tampering. If the platform has been rooted or jail-broken, all OS controls, such as sandboxing, biometrics, etc. cannot be trusted. Your app should do an initial check of the OS integrity, and halt execution if tampering is detected.
OWASP Can Help
At Promenade, we develop our apps using the OWASP MASVS industry standard for Mobile Security. OWASP MAS provides a great, free, online resource for describing mobile vulnerabilities and providing test code and tools to verify they are mitigated. OWASP MAS covers the topics listed here in much more depth, as well as many more topics.
Conclusion
Mobile apps are increasingly a part of medical devices and device manufacturers need to be vigilant in following security best practices. The potential consequences of security breaches have caused regulators and healthcare organizations to require proper security safeguards, including the topics discussed here. If you need help with any aspect, please reach out to us.