Security Privacy & Compliance for mHealth Apps 2014 ISRM Conference 2014

Slide 1 © Symosis Security

Security, Privacy & HIPAA for mHealth

Kartik Trivedi & Clinton Mugge Symosis Security


Agenda

Introduction

HIPAA mHealth

Mobile App Risks to HIPAA Rule & Remediation

Countermeasures


Symosis Security

Security Assessments, Penetration Testing, Compliance, and Training

Average 15 years experience in information security, software development, business and network management

Domain experts, authors, speakers

Consulted with 100+ companies across all industries


Audience Poll

•  What does mobile mean? •  How many of you are involved

with HIPAA Compliance around mobile security audits or development

•  Does your employer have mobile presence? Wifi, email, apps?


Agenda

Introduction

HIPAA mHealth


Conclusion


What is HIPAA?

HIPAA Security Rule Administrative Safeguards

Technical Safeguards

Physical Safeguards

Organizational Requirements

Policy and Procedure Requirements

HIPAA Privacy Rule

The HIPAA Enforcement Rule

Contains provisions relating to compliance and investigations, the imposition of civil money penalties for violations of the HIPAA Administrative Simplification Rules, and procedures for hearings.

The HIPAA Breach Notification Rule

Requires HIPAA covered entities and their business associates to provide notification following a breach of unsecured protected health information.


Criminal penalties can be up to $250,000 and/or 10 years in prison for deliberate, wrongful misuse of personal health information.


What is PHI?

1.  Names;

2.  All geographic subdivisions smaller than a State, including street address, city, county, precinct, zip code

3.  All elements of dates (except year) for dates directly related to an individual, including birth date, admission date, discharge date, date of death;

4.  Telephone numbers;

5.  Fax numbers;

6.  Electronic mail addresses;

7.  Social security numbers;

8.  Medical record numbers;

9.  Health plan beneficiary numbers;

10.  Account numbers;

11.  Certificate/license numbers;

12.  Vehicle identifiers and serial numbers, including license plate numbers;

13.  Device identifiers and serial numbers;

14.  Web Universal Resource Locators (URLs);

15.  Internet Protocol (IP) address numbers;

16.  Biometric identifiers, including finger and voice prints;

17.  Full face photographic images and any comparable images; and

18.  Any other unique identifying number, characteristic, or code, except as permitted by paragraph (c) of this section; and


There is an App for that!


mHealth Top Threats

1.  Theft or loss of the mobile device

2.  No encryption / Screen lock not enabled

3.  Interception of transmission of ePHI by an unauthorized person

4.  Basic passwords – Devices do not include physical keyboards

5.  Improper disposal of the device

6.  Push notifications and other user communications

7.  Sharing PHI using Social media and email

8.  Phishing, Mobile Malware


Does Your Mobile App Need to Comply with HIPAA?

If your application is going to send or share health data to a doctor, hospital, or other covered entity, it must be HIPAA-compliant

Adhering to the Privacy and Security Rules of HIPAA is essential, especially considering the dangers that come with handling protected health data on a device


Which 2 Apps are Required to be HIPAA Compliant?

1.  Allows users to record their weight and exercise routines

2.  App is used to record and share patient information with a covered entity

3.  Gives users access to medical reference information

4.  Lets average users look up illness information

5.  Defines various illnesses or diseases

6.  Lets users keep up with their daily diets

7.  App stores PHI that includes appointment date with medical history but not records


Applying HIPAA to Mobile Apps

Technical Safeguards ■  Access Control

◆  Unique User Identification (Required)

◆  Emergency Access Procedure (Required)

◆  Automatic Logoff (Addressable) ◆  Encryption and Decryption

(Addressable)

■  Audit Controls ■  Integrity Controls ■  Person or Entity Authentication

■  Transmission Security ◆  Integrity Controls ◆  Encryption

Physical Safeguards ■  Facility Access Controls ■  Device and Media Controls ■  Workstation Security & Use

Administrative ■  Assign a privacy officer

■  Complete a risk assessment annually

■  Implement employee training ■  Review policies and procedures ■  Execute BAA

Mobile Apps Developers need to mostly focus on the Technical and Physical safeguards outlined in the Security Rule


OWASP Top 10 Mobile Application Risks


Agenda

Introduction

HIPAA mHealth


1.  Encrypt PHI Data in Storage

2.  Secure and Unique User Identification

3.  Protect PHI in Transit

4.  Un-encrypted Side Channel Leakage

5.  Weak Server Side Controls

Conclusion


Encrypt PHI Data in Storage – Insecure Data Storage (M2)

Locally stored data both on native and browser based apps that includes

■  SQLite

■  Sensitive Files

■  Downloaded Documents


Demo 1: PHI Not Encrypted Tools: DroidAtScreen, Finder, Preview

Device: Galaxy S5, Android 4.4

SQLite files

Sample Applications: Medical Files and Health Records

- Doctor or Personal Use


Demo 1: PHI Not Encrypted


Cached data in the clear


Countermeasure – Encrypt PHI Data in Storage

Avoid local storage on the device. If required, encrypt data securely

■  Data Protection API (iOS)

■  Keychain (iOS)

■  Common Crypto (iOS)

■  Sqlite (iOS & Android)

■  Android Java Crypto


Countermeasure – Data Protection API & Keychain

Protection Class

NSFileProtectionNone

NSFileProtectionComplete

NSFileProtection CompleteUnlessOpen

NSFileProtection CompleteUntilFirst UserAuthentication

Attribute kSecAttrAccessibleWhenUnlocked

kSecAttrAccessibleAfterFirstUnlock

kSecAttrAccessibleAlways

kSecAttrAccessibleWhenUnlockedThisDeviceOnly

kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly

kSecAttrAccessibleAlwaysThisDeviceOnly

Data protection API and Keychain require the passcode to be set. Even if passcode is set, data can be compromised if

■  Passcode can be brute forced

■  Using iTunes backups

■  Public decryption tools


Countermeasure – 3CC & SQLCipher

The Common Crypto library, also known as CCCrypt and 3CC, provide access to a number of types and flavors of encryption algorithms.

Choose appropriate algorithm, key size and mode Supports AES, DES, 3DES, and other encryption standards

SQLCipher is an open source extension to SQLite that provides transparent 256-bit AES encryption of database files

256-bit secure encryption using OpenSSL

Open source (BSD License)


Countermeasure – Android Data Encryption

By default, files that you create on internal storage are accessible only to your app. Avoid using the MODE_WORLD_WRITEABLE or MODE_WORLD_READABLE modes for IPC files

Files created on

external storage, such as SD Cards, are globally readable and writable.

Content providers offer a structured storage mechanism that can be limited to your own application or exported to allow access by other applications.

If you do not intend to provide other applications with access to your ContentProvider, mark them as android:exported=false


Agenda

Introduction

HIPAA mHealth







Conclusion


Secure User Management – Poor Authorization and Authentication(M5)

Credentials transmitted transmitted and stored securely, access rights enforced

■  Prevent client side bypass

■  Prevent server side bypass

■  Opt/In for persistent auth

■  Store credentials securely


Demo 2: Credential Management Tools: DroidAtScreen, adb, Finder, TextEdit


SQLite files

Sample Applications: Cloud Electronic Health Records

- Doctors


Demo 2: Credential Storage


Credential Storage


Countermeasure – Unique User / Secure Authentication

■  Never use device ID or subscriber ID as sole authenticator. Use Contextual data but only as part of multi-factor authentication

■  Ensure user roles and privileges are mapped and tied with user unique identifier such as session ID or constant parameter on server side.

■  Require authentication on all pages and resources. Ensure authentication controls fail securely

■  Verify that re-authentication is required before any application-specific sensitive operations are permitted.


Countermeasure – Unique User / Secure Authentication

Implement Automatic Logoff

■  Developers should assume all client-side authorization and authentication controls can be bypassed by malicious users.

■  Authorization and authentication controls must be re-enforced on the server-side whenever possible

Due to offline usage requirements, mobile apps may be required to perform local authentication or authorization checks within the mobile app's code. If this is the case, developers should instrument local integrity checks within their code to detect any unauthorized code changes


Agenda

Introduction

HIPAA mHealth







Conclusion


Protect PHI in Transit– Insufficient Transport Layer (M3)

User PHI transmitted using encryption

■  Secure Client to server communication

■  Secure Email Communication


Demo 3: Insecure Transmission Tools: DroidAtScreen, adb, Finder, Gmail, Outlook


eMail files

Sample Applications: Medical Files and Health Records

- Doctors to Patients


Demo 3 - Insecure Transmission


Clear-Text Email


Countermeasure – Protect PHI in Transit

Assume that the network layer is not secure and is susceptible to eavesdropping Apply SSL/TLS to transport channels that the mobile app will use to transmit sensitive information, session tokens, or other sensitive data to a backend API or web service.

Apply SSL to outside entities like third-party analytics companies, social networks

Use strong, industry standard cipher suites with appropriate key lengths. Use certificates signed by a trusted CA provider.

Never allow self-signed certificates, and consider certificate pinning for security conscious applications. Always require SSL chain verification.


Countermeasure – Protect PHI in Transit

IOS - when using CFNetwork, consider using the Secure Transport API to designate trusted client certificates. In almost all situations, NSStreamSocketSecurityLevelSSLv3 or NSStreamSocketSecurityLevelTLSv1 should be used for higher standard cipher strength

IOS - After development, ensure all NSURL calls (or wrappers of NSURL) do not allow self signed or invalid certificates such as the NSURL class method setAllowsAnyHTTPSCertificate.

Android - Remove all code after the development cycle that may allow the application to accept all certificates such as org.apache.http.conn.ssl.AllowAllHostnameVerifier or SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. These are equivalent to trusting all certificates.

Set-Cookie with Secure Flag AuthenticatedID=nNTzKhxV10bzwW1vMfZXhqVGxWXh4D8QrkynxV2QMqv2K032WS02!-2076712369; path=/; /secure


Agenda

Introduction

HIPAA mHealth







Conclusion


Unencrypted Accidental Storage - Side Channel Leakage (M4)

Data leakage via platform defaults, use of third party libraries, logging, etc

■  Property List Files

■  SnapShot (ie- iOS Backgrounding)

■  iOS logs

Sometimes result of programmatic flaws


Demo 4: Side Channel Leakage

Tools: iExplore, Reflection

Device: iPhone 5, IOS 8.1 latest version

Failed Control

- Patient Prescriptions






Snapshot Storage


Countermeasure – Avoid Unintended Data Leakage

■  Disable Snapshots (IOS) - Set the key window’s hidden property to YES

◆  [ UIApplication sharedApplication ].keyWindow.hidden = YES;

■  Disable Cache (IOS) - Set UITextField to OFF to prevent caching. Clear keyboard dictionary periodically

■  Prevent HTTP caching – Implement NSURLConnection delegate and disabling newCachedResponse

■  Disable Crash & Debug Logs – Disable NSLog & NSAssert

■  Be Aware of Keyboard Cache / Copy-Paste


Countermeasure – Avoid Unintended Data Leakage

Perform Threat Modeling and security review of OS, platforms, and frameworks, to see how they handle

■  URL Caching (Both request and response)

■  Keyboard Press Caching

■  Copy/Paste buffer Caching

■  Application backgrounding

■  Logging

■  HTML5 data storage

■  Browser cookie objects

■  Analytics data sent to 3rd parties


Agenda

Introduction

HIPAA mHealth







Conclusion


Weak Server Side Controls (M1)

Insecure server controls - web, application and backend API - can lead to security compromise


Mobile Controls Enforced on Server - Weak Server Side Controls (M1)

Mobile controls should be supported on the server

■  Client logic does not enforce security

■  Mobile API’s enforce same controls as web API’s

■  Server logging should be enforced

■  Harden mobile endpoints

Sometimes result of programmatic flaws


Demo 5: Weak Server Side Controls

Tools: iExplore, Reflection

Device: iPhone 5, IOS 8.1 latest version

Failed Control –

- Patient Prescriptions


Weaker Mobile Controls


Countermeasures – Weak Server Side Controls

■  Secure coding and configuration practices must be used on server-side of the mobile application

■  Web Services / API Hardening – Logic flaws, strong session management

■  Do not trust the client, verify all transactions on the server

■  Validate all access controls on server side, Ensure access control over protected functions, services and data

■  Avoid accessing unnecessary/additional user’s services , Perform periodic security scans and audits

■  Secure coding and configuration practices must be used on server-side of the mobile application


Countermeasures – Weak Server Side Controls

■  Do not trust the client, verify all transactions on the server

■  Validate all access controls on server side

■  Ensure access control over protected functions, services and data

■  Avoid accessing unnecessary/additional user’s services

■  Perform periodic security scans and audits

■  Database/API calls - If your application is relying on data from any CE (such as a doctor's office) it will have to be compliant. Same goes for any integration you need to do with a business associate of a covered entity.


Agenda

Introduction

HIPAA mHealth


Conclusion


Others Mobile Apps Considerations

Keep PHI out if possible - Keeping PHI out of your application is the easiest way to avoid potential breaches of that information while reducing the technical debt required to build and maintain compliant systems.

HIPAA Hosting and compliance - Developers should never use third-party file storage and hosting platforms unless the providers explicitly state they are HIPAA-compliant and agree to sign a Business Associate Agreement. Any service providers that you use for any part of your app must also be HIPAA-compliant themselves and willing to sign a Business Associate Agreement.


Others Mobile Apps Considerations

Email - Emails are usually not compliant with HIPAA and could lead to HIPAA violation is PHI is inadvertently sent. If you are sending email communications that include or might include protected health information from your mobile app you should send those emails via a HIPAA compliant email service provider

Push notifications - Native push notifications run the risk of violating the privacy regulations outlined in HIPAA. Do not include any PHI in any push notifications

Encourage the user to set a PIN Enabling remote wiping of lost phones


Questions? - [email protected]

Symosis Resources for Mobile Apps / HIPAA Compliance

Training Evals – Security for Developers, OWASP Top 10, JAVA / .NET, IOS, Android, Emerging Threats, PCI/HIPAA Security Awareness

Security Checks – Automated Scans on Mobile Apps, Web Apps & External IP

Compliance Gap Templates - HIPAA, PCI DSS

PLEASE

REMEMBER TO FILL OUT THE

SESSION EVALUATIONS.

THANK YOU!

Technology

Security Privacy & Compliance for mHealth Apps 2014 ISRM Conference 2014