Spurred by the growth in wearables and health & well being apps, mHealth is growing fast, not just as a way to track personal fitness but as a way for medical professionals to improve patient care and remotely identify the signs of serious illness for example.  In the US it is estimated that wearables could drop hospital costs by 16 per cent over the five years, and remote patient monitoring technologies could save our healthcare system $200 billion over the next 25 years.

What remains consistent is the need to generate and store vast amounts of patient data yet by its definition, personal data for health services is hyper-sensitive and as with any other consumer data, prone to attack. Here Shyam Iyengar, Head of Technology, Enterprise Architect at Health Fabric outlines the key issues and offers 10 steps to designing in data security in medical apps.

With over 45,000 health and medical apps just in the App Store and thousands more on the Play Store, Health and Fitness is undeniably one of the more popular categories in the app market. Adoption rates of mobile apps in the healthcare sector is increasing and this is partly being fuelled by the need for a patient to actively manage their health and well-being. Agencies such as the FDA are approving mobile apps and the National Health Service has its own Health Apps library. A recent explosion of medical and fitness devices is further propelling the market.

Most of the health and fitness apps collect health related data from the user. These could be body measurements, running times, fitness statistics, allergies, medications and in some cases complete medical records and personal information about yourself. Data concerning health and personal information is sensitive data and it is imperative that the privacy of the user is protected and suitable precautions are taken to ensure this health data is not lost or stolen.

When developing a mobile health app which collects or uses this data, we need to ask ourselves this question – what is the cost to a user if their health data is lost?

Medical/health data could leak into public domain, Land on the wrong hands creating an opportunity for ransom-ware or cyber-bullying, Sold in the black market for a profit or in some cases medical records could be tampered resulting in serious harm to the user especially if the user relies on the app for their health and well being. Fitness data such as running times could result in someone knowing when you are outside the house.

In comparison with financial data breaches, health data breach has a serious problem – it is difficult to detect a health data breach. If a credit card is stolen and misused then it is pretty likely that the user will know about it soon enough, not so in the case of a health data breach. So it is all the more important that health data in the app is monitored in addition to being secured.

If you are thinking of entering into the Health & Fitness app market or are already in the space, what are some of the steps you can take to ensure the privacy of your user is protected?

1. Information risk assessment: How can we ensure confidentiality, integrity and availability of our data, If we do not know what data we hold and what is the risk of losing that data?  It does not make sense to secure all the data by putting in policies, procedures, architecture and design patterns in place  – It takes time, money, valuable resources and also impacts run-time performance of products.The key is to identify what is to be secured and why, understanding the cost of losing the data and putting a mitigation in place. An information action plan and regular reviews to ensure the loose ends are tied follows next. This process is very important if you deal with sensitive data.

2. Protect personal identifiable data: Personal identifiable data is data that can be used to uniquely identify an individual. Some examples of personal identifiable data include: Name, birth date, address, government issued ID numbers, user ID and password. This is the number one data that should be secured.

Authentication and authorization is a start to secure access to such data but is not enough – this is assuming the passwords are salted and hashed in your data store. Plain text passwords are a thing of the past, please stay away from them.

Start by identifying your access points to this piece of data across the layers of your application. If your application is on a client-server model then these could be client presentation – network – services – data access – data store. For every access point ask yourself these questions “what steps have I put in place to ensure data is consistent and is exposed only to the authorized user?”.

If you have an app, ensure sufficient validation testing of user inputs is covered in your user interface.

Be curious and take on a challenge from a requirements, design and test perspective on how you can get access to somebody else’s data. You might be amazed at your own skills.

3. Un-link medical data and personal identifiable data: Yes, it is simpler and faster to have both these data sets linked, just write a query and pull up medical data given a username but doesn’t this also makes it simpler for the attacker?

Aim for design patterns where medical data is segregated from personal data so that even if personal data is compromised the medical records belonging to your users are not obtained and even if medical data is maliciously obtained then they are not traced back to the user. Use annonymisation patterns such as data masking and pseudonymisation where required to break the links.

4. Only hold what you need: Reduce the surface area of damage, only hold and process the data that you need. Sometimes (or rather many times) more data is not a good thing.

Understand what your customer’s truly want.  Taking a leaf out of Agile principles, just focus on things that need doing. Castles could be built later.

5. Encrypt the contents: Encrypting medical and other sensitive data makes it very difficult (if not impossible) to read and make sense of the data. As a general rule, wherever you store sensitive data encrypt it. Leaving sensitive data in plain text is akin to leaving your priced possessions on display with the door open.

Technologies such as Transparent Data Encryption are readily available with most database systems that provide a level of encryption. Mobile platforms also provide encryption API’s. There would be a performance impact in some cases but this is a trade off that will need to be made. As a bonus, your database backups are also encrypted by most encryption systems.

6. Use secure programming guidelines: Integrate secure coding practices into your software development life-cycle, it is less expensive and faster to secure the code at the start of a project rather than at the end. As more and more devices are now connected to the internet, application layer theft has become common than network and physical threats.

OWASP Top 10 security guidelines is a good place to start and they have a comprehensive checklist and super documentation. They communicate the message in a very simple way “A development team develops an application thinking what the application is intended to do, An attacker thinks what an application can be made to do”.

7. Privacy plan: Designing with privacy and protection in mind from the start of a product pays huge dividends at the end. Potential problems are identified at an early stage, it gives an opportunity to employ appropriate architecture and security patterns at lower cost (than at the end) and also gives time to put appropriate test cases and a test harness.

Overall It creates a collaborative environment between different teams as data privacy is not just a technical issue.

8. Secure transmission: If your product at any time connects to another service via the internet and sends sensitive data, this must be encrypted in transit. If it is not encrypted, your data is sent in plain text which when intercepted could easily be read. The point is not “IF” it is intercepted but “When”Using SSL/TLS and a PKI infrastructure will help you encrypt your data and also provide a level of authentication so that data is sent to the right server. This infrastructure is not expensive nowadays and almost all platforms support this.

9. Hire an experienced security testing service: Yes, there are in-house test teams that will cover all levels of testing from Module to System tests but security testing is a totally different domain.

But why security test, haven’t we designed with security in mind, aren’t all the security patterns in place and isn’t the product working? This is similar to saying the product is coded so let’s launch it.

The value of security testing cannot be underestimated, a simple pen test will at-the-least show the vulnerabilities that can be exploited. Hiring an experienced security testing service will give your team rare security domain expertise that is very much needed in this age of complicated hacking maneuvers.

Shyam Iyengar

Head of Tech & Architecture

HealthFabric

  

10. Access management and change control: If your product follows a client-server model, it is imperative that you have an access and asset management plan in place. It is well documented that majority of the security risks (and attacks) happen from inside the organization.

Ensure you have a policy and procedure in place on what, who and how data can be accessed. Assets could be physical or just data – the principles are the same.

Think of change control as flood gates in operation, with time to market pressures and race to go live first – code moves as fast as flood water.

Pause for a moment, understand the impact of changes across your system, ensure nothing else breaks and regulate the flow.

This article originally appeared on Linkedin Pulse and is reproduced here with the authors permission.