security privacy & compliance for mhealth apps 2014 isrm conference 2014
TRANSCRIPT
Slide 1 © Symosis Security
Security, Privacy & HIPAA for mHealth
Kartik Trivedi & Clinton Mugge Symosis Security
Slide 2 © Symosis Security
Agenda
Introduction
HIPAA mHealth
Mobile App Risks to HIPAA Rule & Remediation
Countermeasures
Slide 3 © Symosis Security
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
Slide 4 © Symosis Security
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?
Slide 5 © Symosis Security
Agenda
Introduction
HIPAA mHealth
Mobile App Risks to HIPAA Rule & Remediation
Conclusion
Slide 6 © Symosis Security
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.
Slide 7 © Symosis Security
Criminal penalties can be up to $250,000 and/or 10 years in prison for deliberate, wrongful misuse of personal health information.
Slide 8 © Symosis Security
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
Slide 9 © Symosis Security
There is an App for that!
Slide 10 © Symosis Security
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
Slide 11 © Symosis Security
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
Slide 12 © Symosis Security
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
Slide 13 © Symosis Security
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
Slide 14 © Symosis Security
OWASP Top 10 Mobile Application Risks
Slide 15 © Symosis Security
Agenda
Introduction
HIPAA mHealth
Mobile App Risks to HIPAA Rule & Remediation
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
Slide 16 © Symosis Security
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
Slide 17 © Symosis Security
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
Slide 18 © Symosis Security
Demo 1: PHI Not Encrypted
Slide 19 © Symosis Security
Cached data in the clear
Slide 20 © Symosis Security
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
Slide 21 © Symosis Security
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
Slide 22 © Symosis Security
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)
Slide 23 © Symosis Security
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
Slide 24 © Symosis Security
Agenda
Introduction
HIPAA mHealth
Mobile App Risks to HIPAA Rule & Remediation
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
Slide 25 © Symosis Security
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
Slide 26 © Symosis Security
Demo 2: Credential Management Tools: DroidAtScreen, adb, Finder, TextEdit
Device: Galaxy S5, Android 4.4
SQLite files
Sample Applications: Cloud Electronic Health Records
- Doctors
Slide 27 © Symosis Security
Demo 2: Credential Storage
Slide 28 © Symosis Security
Credential Storage
Slide 29 © Symosis Security
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.
Slide 30 © Symosis Security
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
Slide 31 © Symosis Security
Agenda
Introduction
HIPAA mHealth
Mobile App Risks to HIPAA Rule & Remediation
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
Slide 32 © Symosis Security
Protect PHI in Transit– Insufficient Transport Layer (M3)
User PHI transmitted using encryption
■ Secure Client to server communication
■ Secure Email Communication
Slide 33 © Symosis Security
Demo 3: Insecure Transmission Tools: DroidAtScreen, adb, Finder, Gmail, Outlook
Device: Galaxy S5, Android 4.4
eMail files
Sample Applications: Medical Files and Health Records
- Doctors to Patients
Slide 34 © Symosis Security
Demo 3 - Insecure Transmission
Slide 35 © Symosis Security
Clear-Text Email
Slide 36 © Symosis Security
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.
Slide 37 © Symosis Security
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
Slide 38 © Symosis Security
Agenda
Introduction
HIPAA mHealth
Mobile App Risks to HIPAA Rule & Remediation
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
Slide 39 © Symosis Security
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
Slide 40 © Symosis Security
Demo 4: Side Channel Leakage
Tools: iExplore, Reflection
Device: iPhone 5, IOS 8.1 latest version
Failed Control
- Patient Prescriptions
Slide 41 © Symosis Security
Demo 4: Side Channel Leakage
Slide 42 © Symosis Security
Demo 4: Side Channel Leakage
Slide 43 © Symosis Security
Snapshot Storage
Slide 44 © Symosis Security
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
Slide 45 © Symosis Security
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
Slide 46 © Symosis Security
Agenda
Introduction
HIPAA mHealth
Mobile App Risks to HIPAA Rule & Remediation
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
Slide 47 © Symosis Security
Weak Server Side Controls (M1)
Insecure server controls - web, application and backend API - can lead to security compromise
Slide 48 © Symosis Security
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
Slide 49 © Symosis Security
Demo 5: Weak Server Side Controls
Tools: iExplore, Reflection
Device: iPhone 5, IOS 8.1 latest version
Failed Control –
- Patient Prescriptions
Slide 50 © Symosis Security
Weaker Mobile Controls
Slide 51 © Symosis Security
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
Slide 52 © Symosis Security
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.
Slide 53 © Symosis Security
Agenda
Introduction
HIPAA mHealth
Mobile App Risks to HIPAA Rule & Remediation
Conclusion
Slide 54 © Symosis Security
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.
Slide 55 © Symosis Security
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
Slide 56 © Symosis Security
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!