NOWSECURE UNVEILS FIRST AUTOMATED OWASP MASVS V2.1 MOBILE APP SECURITY AND NEW PRIVACY TESTING

NowSecure MARI is the industry’s first simple risk score based on millions of assessments that identifies third-party apps vulnerable to PII and IP exfiltration, supply-chain and MiTM attacks and sensitive data theft.

MARI Datasheet featured image 768X480
NowSecure Launches Mobile App Risk Intelligence Solution to Combat Threats to Customer and Employee Security, Safety and Privacy NowSecure Launches Mobile App Risk Intelligence Solution to Combat Threats to Customer and Employee Security, Safety and Privacy Show More
magnifying glass icon

Developing HIPAA compliant mobile apps: 5 vital tips

Posted by
Brian Lawrence

Brian Lawrence

Solutions Engineering Manager
At NowSecure, Brian helps enterprises design and implement solutions to secure their mobile transformations and develop higher quality, more secure mobile apps. Prior to a stint in the restaurant and hospitality industries, Brian instituted a managed services provider's SaaS delivery model as a solutions engineer.
Develop HIPAA compliant mobile apps

With an explosion in the number of mobile health apps hitting the market over the last several years, many companies are being forced to consider the scope of the Health Insurance Portability and Accountability Act and how to develop HIPAA compliant mobile apps. Keeping protected health information (PHI) secure in order to ensure HIPAA compliance can be a daunting task for mobile developers unfamiliar with the Privacy Rule.

On top of that, ambiguous and outdated guidelines make for an often frustrating road forward. I’ve helped a number of organizations decipher HIPAA but found that clear information was hard to come by. Here I wanted to help the mobile development community with some clearer information that relates specifically to them.

“What can I do so that you won’t fine me?”

In another life, I planned a charity event to be held at a bar and restaurant I ran. To entice people to attend, I wanted to offer nickel beers.  Unfortunately, our local enforcement officer caught wind and told me it wouldn’t fly.

Eventually we had to scrap the idea completely because no matter what we planned to charge for suds, the officer said he’d shut us down. We felt helpless about how to move forward. We couldn’t remedy the problem, and the body that prohibited us from offering the special refused to offer any rational response.

If you have any experience with HIPAA, this sort of situation might sound familiar. First enacted in 1996 as a broad reform to the health insurance sector, the bill contains an entire section dedicated to the protection and communication of sensitive medical data. For those who may not remember what 1996 was like, here is a refresher:

  • Java 1.0 was first introduced
  • Google embarked upon the development of a search engine
  • Apple announced a loss of $740 million in a single quarter and announced the return of Steve Jobs
  • The Motorola StarTAC — later versions of which would introduce a radical new technology called “texting” — was the best selling cell phone

Motorola StarTAC without hipaa compliant apps

Why should developers care about HIPAA compliance for Mobile Apps?

The market for mobile health will continue to grow for the foreseeable future. If you’re responsible for risk or compliance or mobile apps at a healthcare organization, I’d hope you’re already familiar with HIPAA and why it matters. If you’re part of an app development shop, you need to be aware of the important legal and regulatory requirements of  healthcare clients in order to capitalize on new opportunities for growth in the space.

HIPAA provides no safe harbor for organizations — anyone who transmits or stores Protected Health Information (PHI) is liable, and ignorance is no excuse. This means that if you market an app that handles PHI, and you are not complying with HIPAA, you could already be violating the regulation.

What do I need to know about HIPAA compliance?

There are two primary components to be concerned with: The Privacy and the Security Rules. The Privacy Rule defines what qualifies as PHI, and who is responsible for ensuring that it is not disclosed improperly. PHI is essentially any individually identifiable medical information transmitted through any medium. And this is not only information stored or transmitted by a hospital or other care provider. Again, any entity that has anything to do with the storage or transmission of this data is liable.

The Privacy Rule divides firms that are subject to HIPAA into two categories:

  • Covered Entities – Covered entities are  (1) health plans, (2) health care clearinghouses, and (3) health care providers who electronically transmit any health information in connection with transactions for which the Department of Health and Human Services (HHS) has adopted standards.
  • Business Associate – anyone who stores, collects, maintains, or transmits protected information on behalf of a covered entity.

The Security Rule relates specifically to electronic information and sets guidelines for how to secure PHI. It breaks down protection methods into three categories: administrative, physical, and technical. The three categories are fairly straightforward: administrative revolves around access control and training, physical safeguards are for actual devices, and technical relates to the data itself. But don’t worry, here comes the good part.

Let’s take a look at one of the clauses of the Security Rule that first outlines general guidelines for securing information (bold emphasis mine):

164.306 Security standards: General rules.

(a) General requirements. Covered entities and organization associates must do the following:

(1) Ensure the confidentiality, integrity, and availability of all electronic protected health information the covered entity or organization associate creates, receives, maintains, or transmits.

(2) Protect against any reasonably anticipated threats or hazards to the security or integrity of such information.

But how do we know what can be reasonably anticipated? Here is one of the specific guidelines for accomplishing this task:

(iv) Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information.

That seems reasonable, but what is strong enough? There are people working every day – good and bad – to compromise the systems that we use to secure information. Even recent protocols such as TLS 1.0 have been proven vulnerable. Given HIPAA’s ambiguity, the determining factor for what qualifies as strong enough might simply be the bureaucrat examining your particular case.

A HIPAA checklist for mobile apps and developers

As I mentioned earlier I want to focus primarily on technological protections as they apply to mobile developers, whether they are developing for a covered entity or a BA. I’ve created a five-item checklist to guide developers as they build a mobile app that may fall in-scope for HIPAA. The nuances of HIPAA can get tricky, so make sure you consult an expert. Taking these items into account will by no means guarantee compliance.

But, if you follow these best practices and run your app through mobile app security testing to validate that you have, you’re at least part of the way there in terms of due diligence. As you should when developing any app, make sure you conduct a circumspect and thoughtful review at every stage of development. Security should be a strategy, not an afterthought.

  1. Understand your role and responsibility
  • The security requirements for a healthcare app should be clearly defined and architecture reviewed by a qualified security specialist. Regular app developers should not be expected to be HIPAA or security experts.
  • If you are the product owner, take time to think about your use case for the app. Considering what information will be handled and stored and where in particular it will be stored is key if when you are dealing with PHI.
  • You should also consider what other regulations might play a prominent role in shaping your application’s design. The FTC offers a tool to help you determine what will apply.
  1. Minimize your risk and exposure
  • Avoid accessing, displaying or storing data you don’t need. For example, if you don’t need full birthdate then don’t gather it. Any personal info you ask for should have a clear purpose.
  • Write and follow a clear privacy policy. This is important in any mobile app that collects user data, but especially so in health apps.
  • A highly effective and often overlooked way to avoid data security problems  is not to store it at all. Avoid storing or caching PHI whenever possible. Because of how flash storage works — e.g., wear leveling, block mapping — you can’t actually guarantee that data you write to system memory will be deleted (see our best practice about the secure deletion of data).
  • If you are planning to store data in the cloud, keep in mind that it must be transmitted securely and stored securely. Additionally, you will also need a Business Associate Agreement with any third party providers. For more information, review a whitepaper about cloud architecture and HIPAA compliance published by Amazon Web Services.
  • Be careful with geolocation data. HIPAA guidance for what constitutes geographically identifying someone is information about any subdivision smaller than a state. Geolocation data about a patient can turn data that is fairly innocuous into PHI.
  1. Store and transmit data securely
  • Here is another category where encryption is a huge factor. This should be obvious, right? Unfortunately, NowSecure CTO David Weinstein found that 80 percent of the 200 most popular, free iOS apps opt out of App Transport Security (ATS) — a feature that forces mobile apps to connect to back-end servers using HTTPS, instead of HTTP, to encrypt data in transit.

iOS apps opting out of ATS

  • Given the tools and protocols available today there is simply no excuse not to implement them. As mentioned earlier, data must be encrypted when stored and when transmitted. This also ensures that the data is verified – another important compliance item – constantly.
  • Mobile devices use a number of different protocols for sending information. Are you sending text notifications? SMS and MMS are not encrypted, so make sure they don’t contain PHI.
  • When encrypting data locally, use widely tested protocols based on some sort of standard — in other words, avoid writing your own encryption algorithm.
  1. Secure your app
  • Local session timeout — your  app should certainly force re-authentication after inactivity. Consider your use-case for a good idea of how long that period should be.
  • Push notifications are often called out as a vulnerability. Ensure that PHI is never sent to push notifications that could easily be seen by someone other than the patient it pertains to.
  • Data can leak out where it’s not intended. Avoid leaking PHI into backups and log files which are generally very loosely protected. SD cards in Android devices often have very loose access permissions and are particularly vulnerable as a result.
  • Follow best practices like guidance like that in the OWASP list of Top 10 Mobile Risks  and presented in our Secure Mobile Development Best Practices guide.
  1. Validate your security
  • The only real surefire way to assess the security of a mobile app is via dynamic and static application security testing.
  • Technology exists that can help you do some of this yourself, but if you’re not an expert, you should consider hiring a third party to perform a penetration test of the app. And be sure to mention that the app is in scope for HIPAA compliance — and suggest that they read this blog post so they know what to look for :).

What should I do next to develop HIPAA compliant mobile apps?

Unfortunately many of the resources available from the government are too outdated to be useful. However, if you need additional guidance there are two relevant sites available: