Understand security and privacy threats in Mobile Health mHealth applications & environment Evaluate if HIPAA compliance applies to my mHealth App and if it does how to comply Integrate security due diligence during mHealth App Development Assess risk and support compliance as health providers

1. Slide 1
© Symosis Security
Security, Privacy & HIPAA for
mHealth
Kartik Trivedi & Clinton Mugge
Symosis Security

2. Slide 2
© Symosis Security
Agenda
Introduction
HIPAA mHealth
Mobile App Risks to HIPAA Rule & Remediation
Countermeasures

3. 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

4. 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?

5. Slide 5
© Symosis Security
Agenda
Introduction
HIPAA mHealth
Mobile App Risks to HIPAA Rule & Remediation
Conclusion

6. 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.

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

8. 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

9. Slide 9
© Symosis Security
There is an App for that!

10. 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

11. Does Your Mobile App Need to Comply with
Slide 11
© Symosis Security
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

12. Slide 12
Which 2 Apps are Required to be HIPAA
© Symosis Security
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

13. Slide 13
Mobile Apps Developers need to mostly focus on the Technical and Physical
© Symosis Security
Applying HIPAA to Mobile Apps
Technical Safeguards
■ Access Control
safeguards outlined in the Security Rule
◆ 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

14. OWASP Top 10 Mobile Application Risks
Slide 14
© Symosis Security

15. 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

16. 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

17. 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

18. Slide 18
© Symosis Security
Demo 1: PHI Not Encrypted

19. Slide 19
© Symosis Security
Cached data in the clear

20. 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

21. Slide 21
© Symosis Security
Countermeasure –
Data Protection API & Keychain
Protection Class
NSFileProtectionNone
NSFileProtectionComplete
NSFileProtection
CompleteUnlessOpen
NSFileProtection
CompleteUntilFirst
UserAuthentication
Attribute
kSecAttrAccessibleWhenUnlocked
kSecAttrAccessibleAfterFirstUnlock
kSecAttrAccessibleAlways
kSecAttrAccessibleWhenUnlockedT
hisDeviceOnly
kSecAttrAccessibleAfterFirstUnlock
ThisDeviceOnly
kSecAttrAccessibleAlwaysThisDevic
eOnly
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

22. 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)

23. 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

24. 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

25. 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

26. Slide 26
Demo 2: Credential Management
Tools: DroidAtScreen, adb, Finder, TextEdit
Device: Galaxy S5, Android 4.4
SQLite files
Sample Applications: Cloud Electronic Health Records
© Symosis Security
- Doctors

27. Slide 27
© Symosis Security
Demo 2: Credential Storage

28. Slide 28
© Symosis Security
Credential Storage

29. 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.

30. 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

31. 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

32. 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

33. 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

34. Slide 34
Demo 3 - Insecure Transmission
© Symosis Security

35. Slide 35
© Symosis Security
Clear-Text Email

36. 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.

37. 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=nNTzKhxV10bzwW1vMfZXhqVGxWXh4D8QrkynxV2QMqv2K032W
S02!-2076712369; path=/; /secure

38. 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

39. 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

40. Slide 40
© Symosis Security
Demo 4: Side Channel Leakage
Tools: iExplore, Reflection
Device: iPhone 5, IOS 8.1 latest version
Failed Control
- Patient Prescriptions

41. Slide 41
© Symosis Security
Demo 4: Side Channel Leakage

42. Slide 42
© Symosis Security
Demo 4: Side Channel Leakage

43. Slide 43
© Symosis Security
Snapshot Storage

44. 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

45. 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

46. 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

47. Slide 47
© Symosis Security
Weak Server Side Controls (M1)
Insecure server controls - web,
application and backend API - can
lead to security compromise

48. 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

49. Slide 49
Demo 5: Weak Server Side Controls
Tools: iExplore, Reflection
Device: iPhone 5, IOS 8.1 latest version
Failed Control –
© Symosis Security
- Patient Prescriptions

50. Slide 50
© Symosis Security
Weaker Mobile Controls

51. 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

52. 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.

53. Slide 53
© Symosis Security
Agenda
Introduction
HIPAA mHealth
Mobile App Risks to HIPAA Rule & Remediation
Conclusion

54. Slide 54
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
© Symosis Security
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.

55. 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
Slide 55
Others Mobile Apps Considerations
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
© Symosis Security

56. Slide 56
© Symosis Security
Questions? - info@symosis.com
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

57. PLEASE
REMEMBER TO FILL OUT THE
SESSION EVALUATIONS.
THANK YOU!