How application protection helps HIPAA compliance

The post How application protection helps HIPAA compliance appeared first on Intertrust Technologies.

AppSec/API Security 2022
  • The Health Insurance Portability and Accountability Act (HIPAA) outlines the obligations that health providers and insurers have for handling protected health information (PHI.)
  • HIPAA compliance obligations include apps developed for healthcare providers or insurers. 
  • To create HIPAA compliant apps, software developers must protect against any reasonably anticipated threats or hazards to PHI.  
  • A holistic package of application protection measures, including advanced obfuscation, anti-tampering, and white-box cryptography, is required to ensure PHI data security.

What is HIPAA, and why it matters for app development

The Health Insurance Portability and Accountability Act (HIPAA) outlines the obligations that health providers and insurers have for handling protected health information (PHI.) Though first signed into law in 1996, the act has undergone several iterations and expansions to keep up with modernizations in how health data is used, shared, and stored.

Protected health information is of particular concern to regulators because of its capacity to be used to commit crimes such as fraud or blackmail. Due to the extensive personal information disclosed in medical records, they are among the most valuable types of stolen online data, making them a prominent target for hackers. Health records, health histories, lab results, medical bills, and other physical or digital health information are considered to be PHI if they contain any data that makes them identifiable. This includes names, dates, social security numbers, email addresses, account numbers, web URLs, IP addresses, or any of the 18 PHI identifiers listed in the HIPAA rules.

The 2013 Omnibus Rule Update to HIPAA expanded the list of entities subject to compliance obligations, including apps developed for healthcare providers or insurers. This means that the same privacy and security rules apply to the data the app receives, transmits, and stores, making healthcare software developers responsible for HIPAA compliance.

Creating HIPAA compliant apps

For developers to create HIPAA compliant apps, they must understand their responsibilities and ensure they meet the requirements for the PHI the app comes in contact with. The US Department of Health and Human Services (HHS), which oversees HIPAA compliance, provides information on how to recognize if an app is regulated by the act, asking developers to answer questions such as:

  • Does your health app create, receive, maintain, or transmit identifiable information?
  • Are your clients covered entities? (e.g., hospitals, doctor’s offices, clinics, pharmacies, or health insurance issuers)
  • Does a covered entity (or a business associate acting on its behalf) direct you to create, receive, maintain, or disclose information related to a patient or health plan member?

An important first step to helping developers create HIPAA compliant apps is to identify the rules in the act which apply to them, namely the:

  • Security Rule: This outlines the technical, physical, and administrative safeguards that must be applied to PHI data in an app, such as activity logs, mobile device policies, and restricting third-party access.
  • Privacy Rule: This directs how data can be used and by whom, as well as obligating safeguards on patient privacy.
  • Breach Notification Rule: A major part of HIPAA is the requirement to report data breaches to the HHS. Breaches affecting less than 500 people can be reported via a web portal. 
  • Omnibus Rule: This governs what relationships between app developers and clients would make the former liable under HIPAA.

Threats to HIPAA compliance

The main concern for software developers regarding HIPAA compliant apps is protecting the electronic data created, stored, received, and transmitted by the app. The Security Rule specifies they must protect against any reasonably anticipated threats or hazards to the security or integrity of such information. Unfortunately, applications have many attack surfaces and vulnerabilities that hackers can exploit to gain access and steal data.

HIPAA does not list specific security threats or guidelines for medical software applications. However, the OWASP top 10 threat list offers important insight for building HIPAA compliant apps. Some of the most prominent threats to PHI data on healthcare apps include:

Insecure data storage

One of the foremost obligations of HIPAA is that those covered by the act must “ensure the confidentiality, integrity, and availability of all electronic protected health information.” For HIPAA compliant apps, that means tackling one of the biggest challenges that faces app security in general. There are several risk factors that contribute to insecure data storage on apps, such as poor encryption, insecure access protocols, or running software on jailbroken or rooted devices where security restrictions have been compromised.

Theft of encryption keys

Encryption of PHI data is a requirement for all HIPAA compliant apps; however, as strong as an encryption algorithm is, it is useless if the encryption key is stolen. Hackers have shifted their attention away from trying to break cryptographic algorithms onto stealing the encryption keys that could unlock them, including using side-channel attacks. To ensure PHI data is kept safe, encryption keys need to be secured at all times, even when in use.

Insecure communication

Communication of data between client and server and via chat apps is a target for hackers through what are known as man-in-the-middle attacks. These are where attackers intercept data sent or received by an app. To create HIPAA compliant apps that, for example, provide messaging solutions for healthcare professionals and patients, encrypting the data transmitted is only one element. They also need strong authentication methods as well as protection for the keys used to establish the connection and the session keys.

Reverse engineering

Reverse engineering is one of the first steps in almost any attack on software. An attacker will download an app and analyze the code and structure in order to identify its flow, algorithms, libraries, and other elements. Reverse engineering can reveal a vast array of information including any unprotected cryptographic keys and vulnerabilities that can be exploited to exfiltrate PHI, tamper with the code, or launch further attacks on medical apps and connected systems.

What can be done: In-app protection

A holistic package of application protection measures is required to ensure PHI data security. HIPAA compliant apps must build in robust security capabilities to counter the threats that face them and avoid the regulatory penalties laid out in the Enforcement Rule of the act. With a top-tier fine of $50,000 per violation, this represents a significant risk for the developers of medical apps. Common application shielding measures include:

Hostile environment detection

Running an application on jailbroken or rooted devices is a common method hackers use to avoid the security protections on Apple or Android OSes. They may also run them through debuggers or decompilers to better understand the app’s code and search for possible attack routes. HIPAA compliant apps need to be able to detect when they are being run in a hostile environment so they can take defensive action.

Advanced obfuscation

If a hacker manages to clearly understand an app’s code, they can discover sensitive data stored in the app, uncover exploitable vulnerabilities, inject malicious code, or spoof the application to fool users into entering private information into a fake version of the app. To slow down and frustrate attackers’ attempts to do this, code obfuscation measures can be taken. Examples of this defense are obfuscating the control flow, encrypting segments of the binary, and inlining functions.

White-box cryptography

Applications are particularly vulnerable to hacking attempts as they are often running on devices that don’t have hardware security support. White-box cryptography is a software-based method to secure cryptographic keys that combines obfuscation, encryption, and mathematical transformation techniques to hide cryptographic keys and algorithms so that even if a program or device is compromised, cryptographic keys remain safe.

Tampering protection

When trying to steal PHI data from a medical application, hackers may attempt to insert malicious code to hijack its normal and secure functions. For HIPAA compliant apps, where the developer has no control over the future conditions where the app will be run, it is critical for apps to be equipped with their own tampering detection and protection mechanisms. These include integrity checking, logic verification procedures, and the ability to block any detected tampering attempts.

How Intertrust helps medical app developers stay compliant

HIPAA is not the only regulatory framework governing healthcare and medical apps. Depending on your application’s function and market, it may also need to comply with GDPR, UL 2900-1, EU Medical Devices Regulation, In Vitro Diagnostic Medical Devices Regulation, FDA Policy for Device Software Functions and Mobile Medical Applications, ISO/IEC 27001, and other regulations that require medical application vendors to protect data and establish processes to ensure system security.

At Intertrust, we specialize in helping medical app developers ensure regulatory compliance. Our suite of application shielding solutions includes those mentioned here as well as advanced protections such as Secure Key Box for TLS connections, which protects apps from insecure communications.

Our whiteCryption application code and key protections help you meet regulations without adding to development time. To find out how Intertrust can help you to create regulatory compliant apps, read more about application protection or talk to our team.

*** This is a Security Bloggers Network syndicated blog from Intertrust Technologies - Security Blogs authored by Prateek Panda. Read the original post at: