HIMSS has released its June Healthcare and Cross-Sector Cybersecurity Report in which healthcare organizations are warned about the risk of exploitation of vulnerabilities in application programming interfaces, man-in the middle attacks, cookie tampering, and distributed denial of service (DDoS) attacks. Healthcare organizations have also been advised to be alert to the possibility of USB devices being used to gain access to isolated networks and the increase in used of Unicode characters to create fraudulent domains for use in phishing attacks.

API Attacks Could Be the Next Big Attack Vector

Perimeter defenses are improving, making it harder for cybercriminals to gain access to healthcare networks. However, alternative avenues are being explored by hackers looking for an easier route to gain access to sensitive data. Vulnerabilities in API’s could be a weak point and several cybersecurity experts believe APIs could well prove to be the next biggest cyber-attack vector.

API usage in application development has become the norm, after all, it is easier to use a third-party solution that to develop a solution from scratch. APIs allow healthcare organizations to integrate third-party services. A study by One-Poll suggests that on average, businesses are managing 363 different APIs and two thirds of organizations expose the APIs to the public or their partners. As with any software solution, if vulnerabilities exist, it is only a matter of time before they are exploited.

Torsten George at Security Week has explained several ways that APIs can be exploited to gain access to sensitive data.

Unicode Characters Used in Convincing Impersonation Attacks

The ability to include Unicode characters in domain names is allowing cybercriminals to easily create highly convincing domains using homographs. These domains can be virtually indistinguishable to the genuine domain to the casual eye, making them ideal for use in phishing attacks. Examples include use of the Cyrillic small letter a in place of a standard a, or the use of the Latin small letter iota or the Latin small letter dotless i, in place of an i. Farsight Security has released a useful report on the matter in its Global Internationalized Domain Name Homograph Report.

New USB-Based Attack Method Identified

A new attack method has been detailed by Eleven Paths on the exploitation of hidden networks created via USB devices. This attack method could allow access to be gained to isolated computers not connected to the Internet. Simply disconnecting a computer from WiFi or not connecting the device to a network via an Ethernet cable may not be sufficient at preventing a malicious actor from gaining access to the device and sensitive data, as was demonstrated by the infection of an isolated computer with Stuxnet malware at a Nuclear power plant.

The post HIMSS Warns of Exploitation of API Vulnerabilities and USB-Based Cyberattacks appeared first on HIPAA Journal.

The American Hospital Association (AHA) has voiced the concerns of its members about the HHS’ Centers for Medicare and Medicaid Services’ hospital inpatient prospective payment system proposed rule for fiscal year 2019, including the requirement to allow any health app of a patient’s choosing to connect to healthcare providers’ APIs.

Consumer Education Program Required to Explain that HIPAA Doesn’t Apply to Health Apps

Mobile health apps can con collect and store a considerable amount of personal and health information – in many cases, the same information that would be classed as protected Health Information (PHI) under Health Insurance Portability and Accountability Act (HIPAA) Rules.

However, HIPAA does not usually apply to health app developers and therefore the health data collected, stored, and transmitted by those apps may not be protected to the level demanded by HIPAA. When consumers enter information into the apps, they may not be aware that the safeguards in place to protect their privacy may not be as stringent as those implemented by their healthcare providers.

There is even greater cause for concern when PHI flows from a healthcare provider to a health app. Consumers may not be aware that their PHI ceases to be PHI when it is transferred to the app and that app developers would not be bound by HIPAA Privacy Rule requirements that prohibit the sharing of health data with third parties.

“Most individuals will not be aware of this change and may be surprised when commercial app companies share their sensitive health information obtained from a hospital, such as diagnoses, medications or test results, in ways that are not allowed by HIPAA,” explained AHA in its comments.

AHA suggests the CMS work closely with the Office for Civil Rights and the Federal Trade Commission to develop a consumer education program to communicate this to consumers.

AHA suggests that the education program should explain to consumers the distinction between PHI and health data in health apps, that app developers may choose to share health data with third parties, and that it is important for consumers to carefully review the privacy policies and terms of conditions of the apps to find out what is likely to happen to their data and with whom the information is likely to be shared.

A Secure App Ecosystem Must Be Developed

Health apps can allow patients to engage with their healthcare providers and encourages them to take greater interest in their own health care. AHA notes that “America’s hospitals and health systems are committed to moving forward with new forms of sharing health information with individuals.”

The CMS has proposed that healthcare providers should allow any application of a patient’s choice to connect with their APIs, provided they meet the technical specifications of the API. While sharing healthcare information in this manner will help to engage patients in their own health, there are security issues to consider. “We believe that CMS must balance the pace for moving in this positive direction with the real and developing risks that this approach raises for systems security and the confidentiality of health information,” wrote AHA.

To improve confidence in the security of provider to patient exchange, AHA suggests stakeholders should work together to develop a secure app ecosystem for the sharing of health data. Standards should be developed to ensure a baseline of security, similar to the Payment Card Industry Data Security Standard (PCI DSS) and that there should be a vetting process for apps, similar to that used by the CMS before apps can connect to Medicare claims data via the Blue Button 2.0 API.

In the case of PCI DSS, safeguards need to be incorporated to ensure the security of payment card data. In the case of the Blue Button 2.0 system, an app evaluation process exists to assess apps before they are permitted to connect. Developers must also agree to the terms and conditions of the CMS. It is not possible to connect any app that meets the technical specifications of its API.

The AHA suggests the protections put in place by the CMS could serve as a basis for a sector-wide approach to developing a trusted app ecosystem.

Concern has also been raised about the potential for healthcare organizations that deny an app from connecting to their API out of security concerns to be seen to be information blocking, thus placing them at risk of a meaningful use payment penalty. CMS suggests, “To ensure that reasonable actions to secure systems are not considered noncompliant, we recommend that CMS work with ONC and OIG to ensure that these protective measures are included in the forthcoming guidance on actions that do not constitute information blocking.” Further, CMS recommends “CMS work with ONC and FTC to develop a place for hospital and health systems to report suspect apps so that others can be aware and take needed steps.”

The post AHA Voices Concern About CMS’ Hospital Inpatient Prospective Payment System Proposed Rule appeared first on HIPAA Journal.