Artificial Intelligence (AI) is transforming the delivery of healthcare in the United States. It is also responsible for one of the biggest threats to the delivery of healthcare in the United States – the theft of healthcare data.

AI has been described as a double-edged sword for the healthcare industry. AI-based systems can analyze huge volumes of data and detect diseases at an early and treatable stage, they can diagnose symptoms faster than any human, and AI is helping with drug development, allowing new life-saving drugs to be identified and brought to market much quicker and at a significantly lower cost. However, AI can also be used by cybercriminals to bypass security defenses and steal healthcare data in greater volumes than ever before – potentially disrupting healthcare operations, affecting health insurance transactions, and preventing patients from receiving timely and effective treatment. This article discusses seven ways AI can be used by hackers to steal healthcare data and suggests ways that healthcare organizations can better prepare for future AI-driven and AI-enhanced attacks.

7 Ways AI Can be Used by Hackers to Steal Healthcare Data

The Increased Threat from AI-Enhanced Phishing Emails

Generative AI models are capable of generating text, images, and other media, and can be used to craft flawless phishing emails that lack the red flags that allow them to be identified as malicious. Security researchers have shown that generative AI is capable of social engineering humans, and AI algorithms can be used to collate vast amounts of personal information about individuals, assisting hackers in crafting highly convincing spear phishing emails.

While this development alone is cause for concern, what is more worrying is AI significantly lowers the bar for conducting phishing campaigns opening. Hackers do not need to be skilled at spear phishing, and AI removes any language constraints. Any bad actor can take advantage of generative AI software to launch spear phishing campaigns at scale to obtain users’ login credentials, deploy malware, and steal healthcare data.

Malicious Emails Written by AI are More Likely to Bypass Email Filters

AI-produced malicious emails are more likely to bypass email filters than malicious emails produced manually. The emails use perfect grammar, lack spelling mistakes, use novel lures, target specific recipients, and are often sent from trusted domains. Combined, this results in a low detection rate by traditional email security gateways and email filters.

AI has also been leveraged to combine obfuscation, text manipulation, and script mixing techniques to create unique emails that are difficult for cybersecurity solutions to identify as malicious. Manually coding these evasive tactics can be a time-consuming process that is prone to error. By leveraging AI, highly evasive email campaigns can be developed in minutes rather than hours.

Most Antivirus Software Cannot Detect Polymorphic Malware

Polymorphic malware is malware that modifies its structure and digital appearance continuously. Traditional antivirus software detects malware based using known virus patterns or signatures and cannot detect this type of threat because polymorphic malware is capable of mutating, rewriting its code, and modifying its signature files.

Polymorphic malware is not specific to AI. Hackers have been programming malware to continuously rewrite its code, and it poses a major challenge for network defenders as it is capable of evading traditional cybersecurity solutions. However, when polymorphic malware is created by AI, code complexity and delivery speed increase – escalating the threat to network security, computer systems, and healthcare data while lowering the entry bar for hackers with limited technical ability.

Brute Force Password Cracking is Quicker with AI

Brute force password cracking is a technique for automating login attempts using all possible character combinations, By using the latest, powerful GPUs, hackers can attempt logins at a rate of thousands of potential passwords per second. In May, we reported on how advances in computer technology were reducing the length of time it takes to crack passwords by brute force and – to demonstrate – published the following Hive Systems table.

Time it takes a hacker to brute force your password in 2023. Source: Hive Systems

Since then, Hive Systems has recalculated these times to demonstrate the potential of using GPUs with AI hardware. It is important to note that these tables compare the times it takes to crack random MD5 hashed passwords. Passwords that include names, dictionary words, sequential characters, commonly used passwords, and recognizable keystroke patterns (i.e., “1qaz2wsx”) will take far less time to crack.

Using ChatGPT hardware to brute force your password in 2023. Source: Hive Systems

AI Can Find Vulnerabilities and Unprotected Databases Faster

AI-driven software not only analyzes software and systems to predict vulnerabilities before patches are available, but can trawl cybersecurity forums, chat rooms, and other sources to detect vulnerability and hacking trends. The speed at which hackers can move using AI reduces the time security teams have to detect and address vulnerabilities before the vulnerabilities are exploited, from a few weeks to days or even hours.

Additionally, the attack surface has grown considerably in healthcare due to the number of connected devices, providing even more potential targets for breaching internal networks. Hackers can use AI to exploit vulnerabilities in IoT and IoMT devices – or in their connections – to gain access to networks and steal healthcare data. Alternatively, hackers could use AI to manipulate patient data or alter the function of medical devices to target patients.

Hackers can Manipulate Customer Service Chatbots

Conversational AI chatbots (rather than rule-based chatbots) can be manipulated by hackers using a process known as jailbreaking to bypass the chatbot’s guardrails. The process can be used to extract healthcare data from a chatbot on a hospital website or get the chatbot to send healthcare data to the hacker each time the chatbot service is used by a patient.

A similar threat made possible by AI is indirect prompt injection. In this process, adversarial instructions are introduced by a third-party data source such as a web search or API call, rather than directly, which could be via a website or social media post. The injection indirectly alters the behavior of the chatbot to turn it into a social engineer capable of soliciting and stealing sensitive information.

AI Can be Used to Bypass CAPTCHA

CAPTCHA is used by more than 30 million websites to prevent bots from accessing the website, especially malicious bots looking for website vulnerabilities and poorly protected databases. AI-enhanced robotic process automation bots can be trained to learn the source code for CAPTCHA challenges or use optical character recognition to solve the challenges.

CAPTCHA is effective, but can no longer be used to shore up the security of poorly configured websites as AI allows CAPTCHA challenges to be successfully navigated. Thereafter, they can exploit vulnerabilities and steal healthcare data from poorly protected databases, or bombard the server in a DDoS attack to render the website unavailable.

How to Better Prepare for Future Attacks on Healthcare Data

AI can be leveraged by malicious actors to increase the sophistication of their attacks and conduct them in far greater numbers. Legacy defenses and security awareness training will not be enough to prevent employees from interacting with email-borne threats and hackers from infiltrating information systems. Therefore, healthcare organizations and other businesses maintaining healthcare data need to take proactive steps to defend against the malicious use of AI-based systems.

Measures organizations can implement include advanced email filters that support first/infrequent contact safety, mailbox intelligence protection, and zero hour auto purge to retrospectively delete emails if they are weaponized after delivery. If not already implemented, data loss prevention solutions should be considered to protect against hackers using AI to steal healthcare data.

Other ways in which healthcare organizations can prepare for future attacks on healthcare data include supporting existing signature-based antivirus software with extended detection and response solutions, replacing conversational chatbots with rule-based chatbots, and deploying click fraud software that can distinguish between human interactions and bot-driven activity.

One area of preparedness all healthcare organizations should review is password complexity and security. Due to the AI resources available to hackers, it is recommended all passwords are a minimum of fourteen characters in length and contain a random combination of numbers, upper and lower case letters, and symbols. A password manager should be used as it can generate truly random strings of characters for passwords and store them securely in an encrypted password vault.

AI Will Make Cybersecurity More Difficult for the Unprepared

While there are many ways that AI can be used by hackers, AI tools are currently being used to a limited extent by malicious actors but we are already at a stage where it is no longer a case of if these and other novel techniques will be used, but when. Furthermore, because of the ease with which AI generative tools can be used to craft sophisticated phishing emails, write malicious code, and crack passwords, the threshold has been lowered for the skills required to launch attacks on healthcare data.

While many of the measures suggested to prepare for future attacks on healthcare data are likely to incur costs, the alternatives are disruptions to healthcare operations, delayed insurance authorizations, and a fall in the standard of healthcare being provided to patients – notwithstanding that the failure to implement safeguards to protect against these new threats could also result in enforcement action by the HHS’ Office for Civil Rights, Federal Trade Commission, and state Attorneys General.

Steve Alder, Editor-in-Chief, HIPAA Journal

The post Editorial: 7 Ways AI Can be Used by Hackers to Steal Healthcare Data appeared first on HIPAA Journal.

Due to a lack of reporting transparency, it is difficult to accurately determine the true scale of healthcare data breaches and why they happen. Nonetheless, security experts are in agreement that the adoption of artificial intelligence (AI) by cybercriminals will lead to an increase in healthcare data breaches.

To find out the scale of healthcare data breaches and why they happen, researchers tend to review the Department of Health and Human Services’ (HHS) Data Breach Portal – a database of data breaches affecting 500 or more individuals reported by healthcare providers, health plans, healthcare clearinghouses, and business associates subject to the requirements of the HIPAA Breach Notification Rule.

However, according to the most recent HHS report to Congress, the data breaches that appear in the portal are just the tip of the iceberg. In calendar year 2020, the HHS’ Office for Civil Rights received 609 notifications of data breaches affecting 500 or more individuals, but there were 63,571 reports submitted to OCR about data breaches affecting fewer than 500 individuals.

Furthermore, of the publicly available notifications listed in the Data Breach Portal for 2020, 268 were attributed to cyberattacks and ransomware (classified as “Hacking/IT incidents” on “Network Servers”). Yet, according to the Cybersecurity and Infrastructure Security Agency (CISA), more than 90% of all successful cyberattacks (including ransomware attacks) start with a phishing email.

Once you add the healthcare data breaches that were correctly reported as being attributable to phishing (171 in 2020 according to the OCR Data Breach Archive), this implies that more than 400 of 609 data breaches affecting 500 or more individuals had phishing as the initial access vector. Security experts’ concerns that AI will increase healthcare data breaches certainly appear to be justified, given the ease at which large language models can be leveraged for phishing and social engineering.

AI Tools Can be Used to Craft Flawless Phishing Emails

There are several reasons for concern about the use of AI by malicious actors. Members of the workforce who receive security awareness training can often spot a phishing email due to its brevity, grammatical mistakes, and other common red flags. If in doubt about the authenticity of a message, employees are instructed to contact the sender of the email using verified contact information to confirm the authenticity of the request. In order to take that step, employees must be able to identify indicators of phishing in the message. AI-generated phishing emails lack many of the red flags that employees are taught to look for and are written in perfect English (or another language), without tell-tale spelling and grammatical errors.

AI can also be leveraged to trawl through vast amounts of stolen data from multiple sources and organize personal information, which can be used to create highly targeted spear phishing emails.  Additionally, malicious actors can use AI to automate email conversations if a phishing email is queried, and even exploit voice cloning AI in case the email is queried by phone.

Phishing is effective because it exploits human weaknesses and with AI tools capable of writing flawless phishing emails, employees are more likely to be fooled. These emails are combined with multi-layered obfuscation techniques, increasing the chance of phishing emails evading email security gateways and spam filters. Additionally, an increasing number of phishing attacks have been identified as originating from white-listed, trusted domains that have been compromised in previous phishing attacks, thus ensuring the messages are delivered. AI technologies can also be used to create authentic-looking landing pages and weaponize them with polymorphic malware capable of evading anti-virus software. The malware code itself can even be generated by AI-based tools, and at a speed that far exceeds even the most accomplished malware coder.

Security Experts Confirm the Threat from AI is Not Hypothetical

The concerns of security experts are not hypothetical or anecdotal. In July this year, the HHS’ Health Sector Cybersecurity Coordination Center (HC3) published a guide on “Artificial Intelligence, Cybersecurity, and the Health Sector”. The guide (PDF) demonstrates how generative AI software such as ChatGPT can be used to design realistic phishing emails with the click of a mouse, and provides examples of how white hat hackers have used ChatGPT to develop polymorphic malware capable of evading security solutions and exfiltrating data via Microsoft Teams.

In July this year, FBI Director Christopher Wray warned delegates at the FBI Atlanta Cyber Threat Summit that cybercriminals are weaponizing AI and the resulting threat will only worsen as machine-learning models become increasingly sophisticated. During his keynote speech, Director Wray said, “We assess AI will enable threat actors to develop increasingly powerful, sophisticated, customizable, and scalable capabilities — and it won’t take them long to do it.”

Healthcare data breaches attributable to AI-enhanced phishing and malware are not the only concerns of security experts. AI can accelerate brute force password cracking, analyze systems to find vulnerabilities and unprotected databases, manipulate customer service “chatbots”, bypass CAPTCHA systems, and manage and direct DDoS attacks in real-time – adjusting tactics based on the target’s defenses. Indeed, there is a lot to be concerned about.

It is not only the increased sophistication and capabilities of AI-enhanced attacks that are causing concern but that AI has significantly lowered the bar for individuals looking to conduct cyberattacks and gain access to large volumes of sensitive healthcare data. For example, carefully researching a potential target and crafting a convincing spear phishing email was a time-consuming process with no guarantee of success, but using tools such as ChatGPT or other large language models makes the process quick and easy. So much so that spear phishing attacks are likely to be conducted in far greater numbers, to the point where they may become as common as “quantity over quality” attacks.

You can read more about the threat from AI in the second article in this series: 7 Ways AI Can be Used by Hackers to Steal Healthcare Data

How Healthcare Organizations Can Defend Against AI-Enhanced Attacks

While controls can be implemented to prevent malicious uses of tools such as ChatGPT, security researchers have demonstrated that they can easily be circumvented. Further, AI-based tools such as WormGPT, which lack the restrictions of ChatGPT, are being marketed to cybercriminals. Simply put, it is not possible to prevent malicious actors from leveraging AI to create flawless phishing emails, accelerate malware development, and assist with other aspects of the attack chain, so healthcare organizations need to be proactive and ensure their defenses are capable of detecting and blocking AI-enhanced attacks.

The increase in medical devices and expanded use of wireless technology on enterprise networks has seen the attack surface increase to the point where security teams struggle to adequately protect every system and device, let alone keep all software updated. Cyberattacks on healthcare organizations have increased even without the use of AI, and with AI tools helping threat actors to conduct more attacks, the situation is likely to get worse, and quickly. The only way that healthcare organizations can effectively combat the malicious use of AI is to use AI and machine learning tools themselves for defensive purposes.

Cybersecurity firms have been quick to respond to the threat from AI and have developed next-gen security solutions that incorporate AI and machine learning tools capable of detecting and blocking AI threats. Traditional cybersecurity solutions are reliant on signature-based detection methods, which are only effective against known threats. Cybersecurity solutions with machine learning capabilities are able to analyze behavior, identify patterns, and make data-driven decisions, allowing them to detect previously unknown threats. AI-based tools can also be used to direct incident response and automate actions to rapidly contain threats.

Rather than rely on signature-based antivirus solutions, next-gen intrusion prevention systems constantly monitor network activity and search for anomalous behavior indicative of a cyberattack in progress, generate alerts for the security team, and take action to mitigate the threat. AI-based solutions can scan for vulnerabilities, identify and prioritize risks, and guide security teams’ risk management efforts. Further, since AI and machine learning tools are capable of learning, they are able to maintain pace in a fast-evolving threat landscape and improve their capabilities over time.

One of the key ways that AI can be leveraged for defensive purposes is automation. With staffing an ongoing problem, especially in healthcare which has struggled more than other industries to attract and retain cybersecurity talent, AI can ease some of the strain by automating time-consuming but critical tasks, such as vulnerability scanning, log analysis, and threat detection. AI can also assist with prioritization to ensure that the most critical issues are dealt with first as well as incident response to limit the ability of threat actors that managed to preach perimeter defenses.

Combatting AI-based threats will require significant investments in cybersecurity. A recent survey of 550 CISOs by IANS Research and Artico Search indicates healthcare organizations have scaled back investment in cybersecurity. While cybersecurity budgets increased by 6% this year, that represents a 65% reduction in growth from last year, when budgets increased by an average of 17%. Without sufficient investment, combatting AI threats is likely to be a significant challenge.

Improving cybersecurity does not necessarily require investment in cutting-edge cybersecurity solutions. There are many low-cost measures that healthcare organizations can take to improve their security posture. Phishing attacks target employees, so it is important to invest in people. Increasing and improving security awareness training, testing workforce susceptibility to phishing emails with phishing simulations, and running penetration tests and vulnerability scans on information systems using open-source tools are all low-cost ways of significantly improving security. Doing little in response to the growing threat from AI is, however, not an option.

Any organization that fails to prepare for AI-enhanced attacks is more likely to appear as a statistic on the HHS Data Breach Report. Regardless of the reason given for the breach, if HHS’ Office for Civil Rights determines the organization has failed to “Protect against any reasonably anticipated threats or hazards to the security or integrity of ePHI” (as required by §164.306), the organization could face substantial civil monetary penalties, and state attorneys general are increasingly investigating organizations over data breaches.

AI-enhanced attacks are “reasonably anticipated threats” and because healthcare data is highly sought after, cybercriminals are weaponizing AI against healthcare organizations. Therefore, healthcare organizations need to prepare now because, even if cybercriminals have not yet targeted them, in the words of FBI Director Wray, “it’s not going to take them long to do it.”

Steve Alder, Editor-in-Chief, HIPAA Journal

The post Editorial: Why AI Will Increase Healthcare Data Breaches appeared first on HIPAA Journal.

The EU Digital Services Act is due to come into force for most “intermediary” service providers that offer a service to EU citizens from February 17, 2024. The Act will impact a number of US-based healthcare IT companies and may influence future federal and state legislation in the United States.

The Digital Services Act is a new EU law that updates the existing EU Electronic Commerce Directive. Among its objectives, the Act aims to address illegal and misleading online content, better protect Internet users from fraud, and provide more control over what personal data is collected and how it is used. The Act also includes new legal requirements for Very Large Online Platforms (VLOPs – i.e., Amazon and eBay), and Very Large Online Search Engines (VLOSEs – i.e., Bing and Google).

The Act applies to all conduit, caching, and hosting services accessible by EU citizens regardless of where the service provider is based (similar to the General Data Protection Regulation). Therefore, US-based social media companies, e-commerce platforms, collaboration tools, content sharing platforms, messaging apps, and advertising networks (among others) will have to comply with the EU Digital Services Act if they provide a service to or for EU citizens.

The Issue of Provider Liability

Chapter 2 of the EU Digital Services Act is similar to §230 of the Communications Decency Act inasmuch it provides immunity for online service providers with respect to third party content generated by its users. However, unlike §230, if a service provider becomes aware of illegal activity or illegal content (Article 6) or is ordered to act against such activity or content (Article 9) and fails to remove or disable access to the activity or content, they are in violation of the Act.

With regards to the scope of provider liability, there is a question about whether a website that hosts chatrooms and forums, or allows users to add public comments, is covered by the Act. Strictly speaking, such a website fulfils the definition of an online platform because users can interact with it. However, in the definitions section of the Act (Article 3), an online platform is defined as:

“a hosting service that, at the request of a recipient of the service, stores and disseminates information to the public, unless that activity is a minor and purely ancillary feature of another service or a minor functionality of the principal service and, for objective and technical reasons, cannot be used without that other service, and the integration of the feature or functionality into the other service is not a means to circumvent the applicability of this Regulation”.

Because it is unclear how EU regulators will interpret “minor” and “ancillary”, it is advisable for US-based websites that support user interaction to comply with Chapter 2 of the Act and Article 18 of Chapter 3 – which requires providers that suspect criminal activity to report their suspicions to EU law enforcement authorities. It may also be necessary to comply with Chapter 3, Article 23, which requires providers to suspend users who frequently post illegal or misleading information.

Other Relevant Articles in the EU Digital Services Act

The EU Digital Services Act has a scale of compliance obligations depending on the nature of each organization’s qualifying activities. VLOPS and VLOSEs have to comply with all applicable Articles, while organizations that only provide (for example) an online platform do not have to comply with the risk management, audit, and data access requirements. In the context of what the US healthcare IT industry can learn from the EU Digital Services Act, the following Articles are the most relevant:

Point of Contact

Similar to the requirements of HIPAA and the FTC Act, healthcare IT companies in the US that provide any form of intermediary service for EU citizens must appoint a “point of contact” similar to a Data Protection Officer under the General Data Protection Regulation. This is a requirement of the EU Digital Services Act even if the company does not qualify as a covered entity under GDPR because it does not collect, process, or store personal information relating to an EU citizen.

The “point of contact” must be contactable in a user-friendly manner (Article 12) and how the appointed individual can be contacted must be publicly available (i.e., not an automated service) so they can be contacted by users of the service and by regulatory authorities. Additionally, the point of contact must be located in the EU; so, if a company does not have a physical presence in the EU, it must appoint a “legal representative” (Article 13).

Transparency Reporting Obligations

The transparency reporting obligations of the EU Digital Services Act cover everything from how the service has moderated content and what algorithms have been used to moderate content, to what complaints have been received and what content has been removed from the service as a result. Providers of intermediary services that do not qualify as a small or micro enterprise will be required to produce a report at least annually (Article 15).

Complaint and Redress Mechanisms

Each organization is required to develop and publicize complaint and redress mechanisms (Article 17). These not only apply to handling complaints from users about illegal and misleading content but also complaints from users who have had content removed by a provider. Member states have the authority to produce their own guidelines on how to deal with malicious, unfounded, or repeated complaints, and this will likely involve the documentation of such (unactioned) complaints.

Restrictions on Deceptive Designs

Article 25 of the EU Digital Services Act prohibits the design or operation of online interfaces that deceive users or manipulate them into making a decision. Examples of such practices include giving more prominence to one option over another and repeatedly requesting that a user make a decision via a pop-up that interferes with the user experience. Additionally, the procedure for terminating a service or subscription must be just as easy as signing up for the service or subscription.

Profiling and Targeted Advertising

Several Articles have restrictions or requirements for advertising. Article 26 includes rules for ensuring users are aware an advertisement is an advertisement (or a commercial communication of any sort) and prohibits user profiling and targeted advertising using certain categories of personal data. Article 28 further extends the prohibition of profiling and targeted advertising to all websites and online platforms that are accessible to minors.

The Traceability of Traders

To mitigate the risk of EU citizens being scammed by anonymous vendors, any website or online platform that offers goods or services supplied by a third party trader must obtain the trader’s name, physical address, phone number, email address, and a copy of their registration documents before advertising their goods or services (Article 30). Additionally, third party traders will only be allowed to advertise goods or services that comply with EU laws.

How Might the EU DSA Impact the US Healthcare IT Industry

The EU DSA is designed to modernize the digital space, create a safer online environment, and reign in the influence of large search engines, e-commerce websites, and social media platforms. The fundamental principles of accountability, transparency, and user protection will impact the US healthcare IT industry inasmuch as US healthcare IT companies provide services to European healthcare systems in the following areas:

• Electronic Health Records Systems
• Telehealth Solutions
• Data Analytics
• Interoperability Solutions
• Medical Imaging Software
• Cybersecurity Services
• Cloud-Based Services
• Billing and Revenue Cycle Management
• Population Health Management

While many of these services may not be subject to the EU DSA because the service provider is not an “intermediary” between the healthcare system and the end user, any other services that qualify as “covered services” will have to comply with the regulations for data transparency and governance, algorithmic accountability, and vendor traceability. Additionally, companies will have to implement mechanisms for complaint handling and redress where required.

The penalties for violations of the EU DSA will be “proportionate to the nature and gravity of the infringement, yet dissuasive to ensure compliance”. Initially, the Digital Services Coordinator is likely to pursue a path similar to how the HHS Office for Civil Rights approaches HIPAA violations – technical assistance and corrective action plans. However, the Coordinator has the authority to fine companies up to 6% of their global turnover and suspend the service until it is compliant.

What the US Healthcare IT Industry Can Learn from EU DSA

EU data privacy legislation is often an influencing factor on federal and state legislation in the United States. California’s Consumer Privacy Act was the first of many state laws modeled on the EU’s General Data Protection Regulation, and the proposed American Data Protection and Privacy Act (ADPPA) further extends individuals’ rights and the data governance requirements of most state laws, plus provides for a conditional private right of action.

Some states have also borrowed from the EU Digital Services Act before the EU law becomes effective. The Indiana Data Privacy Law and the Montana Consumer Data Privacy Act (both passed this year) require covered organizations to conduct data impact assessments before using data for profiling or targeted advertising, while New York’s proposed Privacy Law gives Internet users the right to opt out of both profiling (for any reason) and targeted advertising.

Other Articles in the EU DSA have made appearances in federal legislation. The INFORM Consumers Act requires online marketplaces to collect, verify, and disclose (when required) the identities of certain vendors similar to the EU DSA’s Traceability of Traders Article, while the proposed American Innovation and Choice Online Act places similar restrictions on VLOPs and VLOSEs with regards to the order in which products or search results are displayed to users.

Possibly the most important thing the US healthcare IT industry can learn from EU DSA is the likelihood of §230 of the Communications Decency Act being amended or repealed and interactive online platforms becoming liable for user content posted on them. In 2020, the Department of Justice made four recommendations to Congress ranging from carving out exemptions for specific content to removing all protections for lawsuits brought by the federal government.

Although Congress has not yet acted on the recommendations, numerous legislative proposals (for example, the “Social Media NUDGE Act”) may make it necessary for healthcare IT companies to build content monitoring into interactive apps and – if necessary – develop complaint and redress mechanisms to explain removal decisions and resolve disputes. Due to the volume of legislation that proposes amendments to §230, this is likely to become a requirement sooner rather than later.

Why it is Important to Consider Future Changes Now

There is a great deal of legislative and regulatory activity in the healthcare sector at the minute. In addition to the proposed changes to HIPAA and the cyber incident reporting requirements of the 2022 Critical Infrastructure Act, healthcare IT companies may have to redesign apps and services to comply with the EU Digital Services Act as well as new domestic laws determining how personal health data is collected, retained, and used (i.e., “My Body, My Data Act”).

Because of the number of laws and regulations that may soon require priority attention, it is recommended compliance teams and engineering teams communicate about what changes may be required to existing apps and services, and how they can be planned for now in order to avoid future penalties for non-compliance. Any companies unsure of their compliance obligations under the EU Digital Services Act – or any domestic legislation – should seek professional compliance advice.

The post What the US Healthcare IT Industry Can Learn from the EU Digital Services Act appeared first on HIPAA Journal.

HIPAAJournal.com provides a great deal of data about hackers and medical records, but sometimes it is only possible to scratch the surface of healthcare data breach statistics. This article takes a deeper look at the available information to identify common causes of hacking/IT incidents.

Like most sources, HIPAAJournal.com compiles healthcare data breach statistics from the information available on HHS Office for Civil Rights’ Breach Report. While a valuable source of information to identify trends in data breaches, the Breach Report is limited in its scope because it only lists data breaches affecting five hundred or more individuals.

Additionally, when covered entities and business associates use the Breach Portal to submit a breach notification, they can only select one “Type” of breach (i.e., Hacking/IT Incident, Improper Disposal, Loss, Theft, or Unauthorized Access/Disclosure). Occasionally, the “Types” do not accurately reflect the cause of the breach and the closest option is selected.

Consequently, statistics produced from the Breach Report tell most of the story, but not all of it. In some cases, this can lead to misinterpretations of the data, which – in turn – can lead to security teams allocating resources to the “wrong” security measure. This article aims to help security teams make the best possible use of their resources.

Why Focus on Hackers and Medical Records?

The reason for focusing on hackers and medical records is that, on the surface, the number of reported Hacking/IT Incidents affecting more than five hundred individuals has increased significantly over the past decade. This has led to some startling headlines on Health IT websites, which could influence how security resources are allocated.

There are several reasons for the increased number of reported Hacking/IT Incidents other than an actual increase in Hacking/IT Incidents. These include that security teams and technologies have got better at detecting hacking incidents and that ransomware attacks are included in the statistics even if no data breach has occurred (this is discussed in greater detail later).

However, one of the most likely reasons for the large increase in the number of reported Hacking/IT Incidents affecting more than five hundred individuals is that databases have grown in size as healthcare providers adopt the cloud and combine PHI from individual on-premises databases to a centralized database in the cloud. The next section further supports this theory.

How the Smaller Data Breaches Stack Up

Although HHS does not publish an online database of reported data breaches affecting fewer than five hundred individuals, the breaches are summarized in HHS’ Annual Reports to Congress. At present, the Annual Reports for 2018 to 2021 are available online, and it is from these reports we have extracted the reported Hacking/IT Incidents affecting fewer than five hundred individuals.

While it is important not to take this small sample of data out of context, and notwithstanding that 2018 may have been an exceptional year for reported Hacking/IT Incidents affecting fewer than five hundred individuals (*), it is worth noting that there were more Hacking/IT Incidents reported in total in 2018 than in 2021, and also more in total in 2019 than there were in 2020.

(*) Unfortunately, the Annual Reports prior to 2018 are no longer accessible via the HHS website; and, as the 2021 Annual Report to Congress was only delivered in February 2023, it will be some time before it is possible to tell whether the total number of reported Hacking/IT Incidents increases, falls, or remains consistent with those reported between 2018 and 2021.

Hackers and Medical Records Held to Ransom

In the context of taking a deeper look at data about hackers and medical records, it is important not to ignore how medical records held to ransom are accounted for in the HHS’ Breach Report. Generally, ransomware attacks are considered to be disclosures not permitted by the Privacy Rule due to “unauthorized individuals taking possession or control of the information”.

Whether or not a ransomware attack is a notifiable event is a “fact-specific determination” according to HHS’ Ransomware Fact Sheet. However, unless a covered entity or business associate can demonstrate a low probability that PHI has been acquired or viewed in accordance with 45 CFR §164.402(2), (which is hard to prove in most ransomware attacks), the event is notifiable.

When reporting a ransomware attack, the Help section of the Breach Portal states, “Only select Hacking/IT Incident if ePHI was impermissibly accessed through a technical intrusion.” Nonetheless, even though there may be no evidence to suggest PHI has been acquired or viewed – but the possibility cannot be ruled out – ransomware attacks are most often entered as Hacking/IT Incidents.

How Many Hacking Events are Attributable to Ransomware Attacks?

When reviewing the Breach Report, visitors have two options – view the cases currently under investigation or view an archive of closed cases. The archive provides a description of what happened for most of the closed cases, and by analyzing the descriptions, it is possible to establish how many events reported as Hacking/IT Incidents are attributable to ransomware attacks.

To get an idea of how many reported hacking events are attributable to ransomware attacks, the last two hundred closed cases in which the event “Type” was entered as a Hacking/IT Incident were analyzed. This is the result of the analysis:

• 37.5% of Hacking/IT Incidents were attributable to unspecified cyberattacks
• 33.5% of Hacking/IT Incidents were attributable to ransomware attacks
• 29% of Hacking/IT Incidents were attributable to phishing emails

Unfortunately, the analysis is inconclusive because, while conducting the analysis, multiple mis-categorizations were identified – for example, ransomware attacks categorized as “Theft” and phishing emails categorized as “Unauthorized Disclosures”. Additionally, it is well chronicled that 91% of cyberattacks (including ransomware attacks) start with a phishing email.

Common Causes of Data Breaches in Healthcare

By further analyzing the archive database, it is possible to identify common causes of data breaches in healthcare that can help security teams better allocate resources. Therefore, it may not only be necessary to improve users’ resiliency to phishing emails, but also to better secure connected EMRs and implement measures to prevent the misconfiguration of cloud servers.

Returning specifically to hackers and medical records, it will soon be necessary for healthcare security teams to comply with CIRCIA (Cyber Incident Reporting for the Critical Infrastructure Act). The reporting requirements of CIRCIA mean that attempts to hack a database containing PHI will have to be reported to CISA regardless of whether the attempts are successful or not.

While the increased reporting requirements and the detail required will undoubtedly be burdensome, they should result in more accurate and complete data about hackers and medical record thefts – helping security teams better identify gaps in their security defenses and better allocate resources to address threats and vulnerabilities.

The post A Deeper Look at Data about Hackers and Medical Records appeared first on HIPAA Journal.

OCR Warns Covered Entities and Business Associates of Its Broad View of HIPAA’s Applicability to Cookies, Pixels, and Other Tracking Technologies

On December 1, 2022 the Office of Civil Rights (“OCR”) at the U.S. Department of Health and Human Services issued a nonbinding guidance Bulletin on the use of online tracking technologies by covered entities and business associates (collectively, “regulated entities”) under the Health Insurance Portability and Accountability Act (“HIPAA”). The position taken by OCR in the Bulletin is further evidence of a continuing U.S. regulatory trend towards tighter regulation of online tracking technologies. Although the Bulletin does not have the full force and effect of law, it does demonstrate OCR’s perspective. And the broad view taken by OCR in this bulletin is highly likely to result in an increase in OCR complaints, OCR enforcement actions, and class action filings based on regulated entities’ use of online tracking technologies.

In this article, we (1) briefly describe the underlying online tracking technologies that have drawn regulatory attention; (2) explain the application of HIPAA to these technologies as outlined by OCR; (3) describe the obligations that result from that application; and (4) provide recommendations on addressing these risks in light of this new guidance.

Tracking Technologies of Interest to OCR

In this Bulletin, OCR focused on information captured through commonly used tracking technologies, such as cookies, web beacons or tracking pixels, session replay scripts, and fingerprinting scripts and, in the mobile context, embedded tracking codes within apps that capture information provided by users and users’ mobile device-related information, such as a unique device ID or advertising ID. According to OCR, these tracking technologies are generally developed and provided by third parties (e.g., tracking technology vendors) that receive information directly from these technologies and continue to capture information about users after they leave the website that embedded the tracking technology.

Applicability of HIPAA to Tracking Technologies

OCR addressed the wide range of information collected through online tracking technologies on websites and mobile applications, including an individual’s medical record number, home or email address, date of appointments, IP address or geographic location, medical device IDs, and other unique identifying codes. OCR stated that such information collected on a regulated entity’s website or mobile app generally is protected health information (“PHI”) because it is “indicative that the individual has received or will receive health care services or benefits from the covered entity.” Significantly, OCR asserted this is true even absent an existing relationship between the individual and the covered entity and absent the collection of specific treatment or billing information, such as dates and types of health care services.

Online Tracking Technology for Websites

User-Authenticated Webpages. In the Bulletin, OCR asserted that tracking technologies on user-
authenticated webpages generally have access to PHI, such as IP address, medical record
number, home or email address, appointment dates, and may also have access to individual
diagnoses and treatment information, prescription information, and billing information.

Unauthenticated Webpages. Although OCR stated that tracking technologies on unauthenticated
webpages generally will not provide tracking technologies with access to PHI, OCR asserts that, in
some instances, tracking technologies on unauthenticated webpages may have access to PHI.
OCR asserted that, in such cases, HIPAA Rules will apply. The specific examples OCR provided of
unauthenticated webpages in which HIPAA Rules may apply included:

-Login pages of patient portal;

-Registration webpages for patient portal;

-Appointment availability webpages;

-Doctor search webpages; and

-Informational webpages on specific symptoms or health conditions, such as pregnancy or
miscarriage.

Online Tracking Technology for Mobile Applications

Apps Developed or Offered by Regulated Entities

OCR stated that mobile app vendors, tracking technology vendors and other third parties to whom information is disclosed from mobile applications developed or offered by regulated entities will receive access to PHI (1) because of the nature of the information collected through such apps (e.g., health information, billing information, tracking of health-related variables); and (2) because the downloading and use of the mobile app is indicative that the individual has or will receive health care services or benefits. Per OCR, regulated entities that develop or offer mobile applications must comply with the HIPAA rules for the PHI the mobile app uses and discloses.

Apps Developed or Offered by Third Parties

OCR specified that the HIPAA Rules do not protect the privacy and security of information that users voluntarily download or enter into mobile apps that are not developed or offered by or on behalf of regulated entities.

HIPAA Obligations for Regulated Entities Using Tracking Technologies

In the Bulletin, OCR stated that regulated entities are required to comply with HIPAA Rules when using tracking technologies that permit access to PHI by:

• Ensuring Disclosures of PHI to Tracking Technology Vendors are Permitted, Required, or
  Authorized, and Are Limited to the Minimum Necessary (Unless an Exception Applies). OCR
  asserted that regulated entities must ensure all disclosures of PHI to tracking technology vendors
  are specifically permitted by the Privacy Rule. OCR further stated that, unless an exception
  applies, PHI disclosed must be limited to the “minimum necessary.” OCR stated that merely
  informing individuals through a privacy notice of disclosures of PHI to tracking technology
  vendors will not make that disclosure permissible. To make such disclosures, OCR asserts that
  regulated entities must:

– Enter into a Business Associate Agreement (“BAA”) with All Tracking Technology Vendors and
confirm an Applicable Permission for the Disclosure. Per OCR, prior to disclosing PHI to a
tracking technology vendor, regulated entities must have a signed BAA in place and there
must be an applicable Privacy Rule permission for the disclosure. See 45 C.F.R. 164.502(a). It is
highly likely that some key tracking technology vendors will refuse to enter a BAA. See, e.g.,
Google Analytics: Best Practices to Avoid Sending PII: HIPAA Disclaimer (“you may not use
Google Analytics for any purpose or in any manner involving Protected Health Information”).
– Obtain the Individual’s HIPAA-Compliant Authorization before the Disclosure if There is No
Applicable Privacy Rule Permission or if the Vendor is Not a Business Associate. OCR also
asserted that if there is not an applicable Privacy Rule permission or if the vendor does not
meet the definition of a “business associate”, HIPAA-compliant authorizations will be required
prior to the disclosure of PHI. OCR specifically advised that website banners asking users to
accept or reject the use of tracking technologies will not constitute a valid HIPAA
authorization.

• Entering into BAAs with Tracking Technology Vendors that Meet the Definition of Business
  Associate. OCR further asserted that if a tracking technology vendor meets the definition of a
  “business associate” under HIPAA, the regulated entity must ensure that a HIPAA-compliant BAA
  is in place with the vendor. OCR advised that if a regulated entity does not want to create a
  business associate relationship with a vendor or if the vendor refuses to enter a BAA, then
  individual HIPAA-compliant authorizations will be required before any disclosures of PHI.
• Addressing Tracking Technology in Risk Analysis and Risk Management Processes. OCR
  emphasized the obligation for regulated entities to account for the use of online and mobile app
  tracking technologies in their risk analysis and risk management processes. See 45 C.F.R. 164.308.
•  Implementing Administrative, Physical, and Technical Safeguards. OCR also highlighted the
  requirement for regulated entities to implement appropriate administrative, physical, and
  technical safeguards to protect PHI and ePHI in the context of tracking technologies. See 45
  C.F.R. 306-316.
• Providing Breach Notification. Finally, OCR asserted that regulated entities are required to provide
  appropriate breach notification to affected individuals, the regulator, and the media of
  impermissible disclosures of PHI to a tracking technology vendor that compromise the security or
  privacy of PHI when there is no Privacy Rule requirement or permission to disclose and there is no
  BAA in place with the vendor. In such circumstances, OCR asserted that there is a presumption of
  breach of unsecured PHI unless the regulated entity can demonstrate there is low probability that
  PHI has been compromised. See 45 C.F.R. 164.402(2)

Recommended Action Items

In light of the regulatory and litigation risk arising from this Bulletin, we recommend that companies consider taking the following actions to reduce their risk of being the subject of complaints to OCR, OCR investigations, and/or class action litigation:

• Identify and evaluate current use of online tracking technologies in websites and mobile apps.
  Determine whether information disclosed through such online tracking technologies is likely to be
  deemed PHI based on the context of the collection.
• Analyze current practices against OCR guidance in the Bulletin, and conduct a risk analysis (taking
  into account both regulatory and litigation risks) in furtherance of determining whether to
  discontinue, in whole or in part, use of online tracking technologies, particularly for authorized
  webpages and mobile apps.

If decision is made to continue, in whole or in part, the use of online tracking technologies
involving the disclosure of PHI, we recommend considering the following actions:

– Analyze opportunities to reconfigure such technologies to limit PHI disclosures through
tracking technologies on unauthenticated webpages.
– Enter into compliant BAAs with online tracking technology companies and mobile app
companies, including but not limited to BAAs with entities meeting the “business associate”
definition.
– Obtain HIPAA-compliant authorizations before individuals are set up to use authenticated
webpages or mobile apps.
– Implement required administrative, physical, and technical safeguards required by the Security
Rule, in accordance with OCR guidance in the Bulletin.
– Confirm that ongoing HIPAA security risk assessments and management accounts for online
tracking technology disclosures.
– Inform employees involved in selecting, entering into agreements with, and obtaining services
from online tracking technology providers and/or mobile app providers, as well as employees
with privacy and security-focused vendor oversight responsibilities, of HIPAA compliance risks
and obligations arising from online tracking technologies.

• Evaluate obligations to provide breach notifications to individuals, regulators, and media in
  accordance with OCR guidance in the Bulletin.

Regulated entities should prioritize evaluating and updating their online tracking technology practices, as necessary, to address regulatory expectations for the use of such technologies set forth in OCR’s Bulletin. Taking prompt action will reduce the risk of entities becoming the target of complaints to OCR, an enforcement action, and/or class action litigation.

Co-authors: Eleazar Rundus, Associate Attorney at Fey LLC.  Will Davis, Associate Attorney at Fey LLC.

The post Cookies May be Bad for Your Health appeared first on HIPAA Journal.

In the healthcare industry, the term BAA compliance refers to a Business Associate complying with the terms of a Business Associate Agreement entered into with a Covered Entity. While, in theory, BAA compliance should be straightforward, this is not always the case – and sometimes, noncompliance is not the fault of the Business Associate.

The HIPAA Administrative Simplification Regulations apply to group health plans, healthcare clearinghouses, and healthcare providers that transmit health information electronically in connection with a transaction for which the Department of Health and Human Services (HHS) has adopted standards (i.e., transactions covered in 45 CFR Part 162).

Many healthcare providers that qualify as “Covered Entities” are unable to manage every activity or function in-house and often subcontract some activities to third-party persons or organizations. When these activities involve the creation, receipt, storage, or transmission of PHI, third-party persons or organizations are classified as Business Associates.

Covered Entities are required to protect the privacy of individually identifiable health information, ensure the confidentiality, integrity, and availability of electronic PHI, and notify individuals and HHS’ Office for Civil Rights in the event of a data breach – exposure or unauthorized access to PHI. When PHI is disclosed to a Business Associate, the Business Associate assumes some compliance requirements concerning the PHI they are provided with, collect, store, or transmit.

Business Associates’ Compliance Requirements

Any third party or organization acting as a Business Associate of a Covered Entity is automatically required to comply with the HIPAA Security and Breach Notification Rules. Other compliance requirements are determined by the nature of the service being provided by the Business Associate for or on behalf of the Covered Entity.

For example, if a Business Associate is providing billing or claims management services for a Covered Entity, the Business Associate is required to comply with the transaction, code set, and operating rules of Part 162. If the Business Associate is providing outsourced medical services, the Business Associate is required to comply with certain Privacy Rule standards.

When a Business Associate is required to comply with certain Privacy Rule standards, these should be noted in the Business Associate Agreement – along with any restrictions on uses and disclosures that would normally be allowed by the Privacy Rule but are limited due to the content of the Covered Entity’s Notice of Privacy Practices or because one or more individuals have exercised the right to request privacy protections for PHI under §164.522 of the Privacy Rule.

The HIPAA Business Associate Agreement (BAA)

The HIPAA Business Associate Agreement (BAA) is a contract between a Covered Entity and a Business Associate that establishes the permitted uses and disclosures of PHI by the Business Associate. The BAA must stipulate that uses and disclosures beyond those included in the BAA are not permitted and will result in the termination of the BAA. Other clauses in the BAA should cover:

• Making PHI available to individuals exercising their rights of access and amendment, and when requesting an accounting of disclosures.
• Disclosures required by state or federal law, including (if applicable) to report child abuse or comply with “duty to warn” regulations.
• Business Associate contracts with subcontractors when secondary services are required for the Business Associate to perform an activity.
• The reporting of disclosures of PHI not permitted by the BAA and other security incidents – in addition to reporting breaches of unsecured PHI.
• The term of the BAA (if applicable) and reasons why the BAA may be terminated before its recorded term – for example, a failure of BAA compliance, and the obligations of the Business associate when the contract is terminated or expires.
• Making internal practices and records available to the Secretary of the HHS for determining compliance with the HIPAA Rules.

In most cases, BAAs are prepared by Covered Entities according to the services subcontracted to the Business Associate, but there are times when a Covered Entity must agree to a Business Associate’s BAA before it can use the Business Associate’s services. One of the best examples of this scenario is Microsoft – which refuses to sign Covered Entities’ BAAs on the grounds that it offers “hyperscale, multi-tenanted services that are standardized for all customers”.

Why BAA Compliance is Not Always Straightforward

It would be reasonable to assume that, if a contract states a Business Associate must comply with specific requirements to benefit from the Covered Entity’s business, the Business Associate would comply with the BAA – but that is not always the case. Some Business Associates take shortcuts with BAA compliance “to get the job done”, exposing themselves to cyberattacks, breaches due to training failures, and theft of PHI by external actors and malicious insiders.

However, BAA compliance failures are not always the fault of the Business Associate. HHS guidance implies Covered Entities need only obtain “satisfactory assurances” that Business Associates will use PHI for the purposes for which the Business Associate is engaged before entering into a BAA. There is no legal requirement for a Covered Entity to conduct due diligence on a Business Associate to ensure that satisfactory assurances are backed up with policies, safeguards, and procedures.

Additionally, Covered Entities’ BAAs may not always be entirely complete. Some may omit limitations to uses and disclosures of PHI, fail to insist on adequate training, or not require Business Associates to provide copies of contracts with subcontractors for review. In such cases, Business Associates may violate HIPAA through no fault of their own, yet be exposed to sanctions from HHS’ Office for Civil Rights and State Attorneys General – potentially resulting in civil monetary penalties.

What Business Associates Need to Know about BAA Compliance

Since the publication of the HIPAA Final Omnibus Rule, Business Associates have been liable for HIPAA violations of their own making. Unfortunately, a lack of knowledge is not a defense against a civil monetary penalty and/or costly corrective action plan. Therefore, before entering into a BAA with a Covered Entity, Business Associates are advised to thoroughly check the content of the BAA; and, if in doubt about their compliance requirements, query the issues with the Covered Entity and seek professional compliance advice.

Steve Alder, Editor-in-Chief, HIPAA Journal

The post The Complicated Nature of BAA Compliance appeared first on HIPAA Journal.