Cyber Investigations in the Healthcare Sector
In February 2014, an advanced persistent threat (APT) actor based in China used a phishing scam to hack the computer of an employee at Anthem, Inc, one of the largest health insurance providers in the United States. Over the next year, the APT actor obtained access to at least 90 systems within the company's IT infrastructure, compromising the data of approximately 78.8 million patients nationwide. The ramifications of the breach – the largest of 2015 and still the largest healthcare sector data breach in US history – were costly, extensive and prolonged: a US$115 million class-action settlement with individuals whose protected health information (PHI) was compromised; a US$16 million settlement and corrective action plan imposed by the US Department of Health and Human Services (HHS) Office for Civil Rights (OCR), the federal agency tasked with enforcing the Health Insurance Portability and Accountability Act (HIPAA); and a US$39.5 million global settlement of data breach, identity theft and consumer protection claims with 44 state attorneys general. The Anthem breach starkly illustrates the layered liability exposure that a cybersecurity event can create for participants in the healthcare industry.
Healthcare is one of the most heavily regulated sectors of the US economy and the data-protection regulations that apply to healthcare entities at the state and federal levels are extensive. This chapter begins by exploring this complex regulatory framework and analyses key cybersecurity standards required by HIPAA, the primary federal statute governing the protection of PHI, and related authorities. The chapter then examines major cybersecurity threat vectors for the healthcare industry and concludes with a discussion of best practices to manage the risk of cyber intrusions.
Key cybersecurity standards for healthcare entities
The primary statutory and regulatory framework governing individually identifiable health information of US healthcare providers is the Health Insurance Portability and Accountability Act of 1996, the Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009, and their implementing regulations found at 45 CFR Parts 160 and 164 (collectively, HIPAA). The regulations implementing HIPAA are divided into three sections: (1) Security Standards for the Protection of Electronic Protected Health Information (the Security Rule); (2) Standards for Privacy of Individually Identifiable Health Information (the Privacy Rule); and (3) the Breach Notification Rule. While the focus of this chapter is electronic health information (EHI), it is important to note that HIPAA applies to all PHI, whether in paper or electronic format.
HIPAA applies to 'covered entities' – health plans, healthcare clearing houses, and healthcare providers that transmit health information in electronic form in connection with certain financial or administrative transactions outlined in the regulations. In 2009, as part of the HITECH Act, HIPAA's Privacy and Security Rules were extended to include direct liability for certain entities that contract with healthcare providers, which HIPAA defines as 'business associates', expanding OCR's enforcement jurisdiction and bolstering protections for providers that previously were only contractual in nature. Business associates are persons or entities, other than members of a covered entity's workforce, that perform certain functions or activities involving the use or disclosure of PHI for or on behalf of a covered entity. Such activities include, for example, revenue cycle management, legal representation and other professional consulting, health information technology services, utilisation management, and health benefits or health plan administration. The definitions of business associate and covered entity are not mutually exclusive: a covered entity can also be a business associate of another covered entity, and it is important for covered entities to recognise arrangements in which they are acting as a business associate.
For violations of HIPAA, OCR may impose civil monetary penalties from US$100 to more than US$50,000 per violation, not to exceed US$1,500,000 for identical violations in a calendar year. Factors determining the amount per violation include whether the covered entity or business associate did not know and, by exercising reasonable diligence, would not have known that it violated HIPAA; whether the violation was due to reasonable cause or wilful neglect; and whether the entity corrected the violation within 30 days of when it knew, or by exercising reasonable diligence, would have known that the violation occurred. Potential fines and settlements with OCR can be costly, and OCR's website is replete with examples of recent enforcement actions and multi-million-dollar settlements involving breaches related to failure to apply appropriate administrative, physical and technical safeguards in accordance with the Security Rule. HIPAA does not grant a private right of action to individuals affected by a violation, but the HITECH Act gave state attorneys general the authority to bring civil actions on behalf of state residents impacted by a HIPAA violation.
HIPAA's Security Rule
The adoption of technologies that enhance the mobility and efficiency of the healthcare workforce and give patients enhanced access to their medical records, such as electronic health records, electronic claims management and web-based applications, have increased security risks for covered entities, business associates and the patients they serve. HIPAA's Security Rule establishes the framework for health information security, outlining the security standards to be followed by covered entities and their business associates to safeguard EHI, protect against reasonably anticipated security threats and minimise the risk of security incidents and other impermissible uses or disclosures of EHI. Because the Security Rule aims to allow the adoption of new technologies that will improve the quality and efficiency of patient care, it does not dictate all security measures that covered entities and business associates are required to implement. Instead, the Security Rule requires that entities use any security measures that 'reasonably and appropriately implement the standards and implementation specifications'. In determining such measures, covered entities and business associates must consider:
- the entity's size, complexity and capabilities;
- the entity's technical infrastructure, hardware and software security capabilities;
- the costs of security measures; and
- the probability and criticality of potential risks to the entity's EHI.
Both the Privacy and Security Rules outline 'standards', which are high-level requirements, and 'implementation specifications', which are specific measures designed to ensure adherence to a standard. In contrast to the Privacy Rule, however, and in recognition of the Security Rule's flexibility, implementation specifications under the Security Rule are either 'required' or 'addressable'. 'Addressable' implementation specifications are not optional; rather, they permit the covered entity or business associate to determine whether the specification is a reasonable and appropriate safeguard in its environment, taking into consideration how that particular specification contributes to protecting EHI. If the specification is not reasonable and appropriate, the entity must document the reasons why and implement an equivalent alternative measure, if reasonable and appropriate.
The Security Rule outlines standards and implementation specifications in four broad categories: administrative safeguards, physical safeguards, technical safeguards and organisational requirements. Broadly speaking, administrative safeguards refer to eight standards that require an entity covered by HIPAA to manage the implementation and maintenance of security measures that protect EHI. Key implementation specifications include a risk analysis, designation of a security official, implementation of security measures to reduce EHI vulnerabilities, adoption of a workforce sanctions policy and a regular review of system activity. Entities covered by HIPAA also must implement policies and procedures that authorise access to EHI consistent with the Privacy Rule, address security incidents (including the identification and response to known or suspected security incidents) and outline emergency and disaster responses, and must implement a security awareness and training programme for workforce members.
Physical safeguards refer to policies and procedures that physically limit access to an entity's EHI and include facility access, workstation and device and media controls. Technical safeguards refer to the technology that protects and controls access to EHI, including: access, audit and integrity controls; person or entity authentication; and transmission security. Organisational requirements require business associates to comply with applicable Security Rule requirements (including reporting breaches and implementing policies and procedures), enter into Business Associate Agreements (BAAs), and ensure that any subcontractors that create, receive, maintain or transmit EHI also comply with applicable requirements and enter into appropriate written agreements.
The Privacy Rule
The Privacy Rule establishes standards governing when covered entities may use or disclose PHI. Except as required or permitted under the Privacy Rule, covered entities may not use or disclose PHI unless authorised to do so in writing by the individual who is the subject of the PHI (or the individual's personal representative). 'Authorisation' is a term of art under the Privacy Rule: it refers to an individual's written permission to use or disclose PHI in a manner not otherwise required or permitted by the Privacy Rule, such as for marketing purposes. An authorisation must contain certain core elements, including a description of the records to be disclosed and a statement notifying the individual that the information disclosed may be subject to re-disclosure by the recipient and no longer will be protected under the Privacy Rule.
There are two situations under which the Privacy Rule requires the disclosure of PHI:
- to the individual who is the subject of the PHI (or the individual's personal representative) upon the individual's request for access or an accounting of disclosures; and
- to HHS as part of a compliance investigation or enforcement action.
While the Privacy Rule can be restrictive, in practice, there are many situations where it permits the use or disclosure of PHI. Most notably, the Privacy Rule allows for the use or disclosure of PHI for treatment, payment, and healthcare operations purposes. For example, an individual's primary care physician may consult with a specialist about the treatment of a patient without obtaining the individual's permission to disclose his or her information to the specialist. Similarly, a physician may contact the individual's insurance carrier regarding the status of a claim to facilitate payment for services the physician has rendered to the individual. Additionally, a covered entity may use or disclose PHI to a business associate for operations purposes, such as utilisation review, quality assessment and improvement, auditing, business planning and development, and for legal or accounting services. Covered entities are not required to obtain an individual's authorisation for disclosure to a business associate of PHI necessary for the business associate to perform a service for the covered entity; however, covered entities and business associates are required to execute BAAs containing certain required provisions and assuring that the business associate will comply with Privacy and Security Rule requirements.
Breach Notification Rule
The Breach Notification Rule requires covered entities and business associates to provide notification following a breach of unencrypted PHI. A breach is defined as the acquisition, access, use, or disclosure of PHI in a manner not permitted by the Privacy Rule that compromises the security or privacy of the PHI, as determined by a risk assessment. If a breach has occurred, the entity will notify the affected individuals and, depending on the size of the breach, will notify OCR either at or near the time of discovery of the breach, or when the covered entity makes its annual report to OCR. The covered entity or business associate also may be required to notify the media and post a notice on the entity's website. For many entities, the desire to avoid negative coverage and the ensuing erosion of public and patient trust that can occur from a data breach are key motivators to building a strong HIPAA compliance programme.
The term 'breach' excludes:
- any unintentional acquisition, access or use of PHI by a workforce member or person acting under the authority of a covered entity or a business associate, if made in good faith and within the scope of authority and if it does not result in further impermissible use or disclosure;
- any inadvertent disclosure by a person authorised to access PHI at a covered entity or a business associate to another person authorised to access PHI at the same covered entity or business associate when the information received as a result of such disclosure is not further used or disclosed in a manner not permitted under the Privacy Rule; and
- a disclosure of PHI where a covered entity or business associate has a good-faith belief that an unauthorised person to whom the disclosure was made would not reasonably have been able to retain such information.
Any acquisition, access, use, or disclosure of PHI that does not qualify as an exception is presumed to be a breach, unless the covered entity or business can demonstrate that there is a low probability that the privacy or security of the PHI has been compromised by utilising a risk assessment based on at least the following factors:
- the nature and extent of the PHI involved, including the types of identifiers and the likelihood of re-identification;
- the unauthorised person who used the PHI or to whom the disclosure was made;
- whether the PHI was actually acquired or viewed; and
- the extent to which the risk to the PHI has been mitigated.
Other key considerations include: whether any sensitive financial information (e.g., account identifiers or Social Security Numbers) or sensitive medical diagnoses or conditions were disclosed; the relationship between the individual and the person who acquired or viewed the PHI; whether the unauthorised person had an independent obligation to maintain the confidentiality of the PHI; and whether the information was destroyed or returned.
Primary cybersecurity threat vectors for healthcare entities
A security incident, as defined by the Security Rule, is an attempted or successful access, use, disclosure, modification or destruction of information, or an interference with system operations in an information system. Entities covered by HIPAA are required to identify and respond to suspected or known security incidents; mitigate the harmful effects of security incidents; and document security incidents and their outcomes.
While the healthcare sector has long been a target of cybersecurity threat actors, the number of security incidents has increased substantially since 2020, driven largely by the effects of the covid-19 pandemic, which has exacerbated a pre-existing lack of adequate cybersecurity measures throughout the industry. Many small and mid-size healthcare entities simply do not have the resources to keep up with the security requirements necessitated by the valuable information they create or maintain. Additionally, the abundance of PHI available via digital platforms and its relatively high value on the dark web make healthcare providers attractive targets for malicious actors.
The top 10 healthcare data breaches reported to OCR over the past five years have affected approximately 80 million individuals. With respect to breaches reported to OCR over a two-year period from 2019 to 2020, a substantial majority (71.87 per cent) were due to hacking or IT-related incidents affecting an average of approximately 80,500 individuals per incident. Unauthorised access or disclosure accounted for approximately 19 per cent of breaches, and the remaining 10 per cent were attributed to improper disposal, misplacement and theft of PHI. Healthcare providers have been affected the most, accounting for approximately 79.18 per cent of breach incidents, while other targeted entities include business associates (11.11 per cent), health plans (9.42 per cent) and healthcare clearinghouses (0.28 per cent).
Ransomware attacks are perhaps the most formidable emerging cybersecurity threat for the healthcare industry, causing nearly half of all malware-related breaches targeting this sector. Ransomware attacks on healthcare entities in the United States alone cost approximately US$21 billion in 2020, a year that saw targeted ransomware attacks on the healthcare sector and a high number of related data breaches in part due to the easing of certain telehealth regulations by HHS in response to the covid-19 pandemic. In October 2020, the US Cybersecurity and Infrastructure Security Agency (CISA), Federal Bureau of Investigation (FBI), and HHS issued a joint advisory on ransomware warning of 'an increased and imminent cybercrime threat to US hospitals and healthcare providers.' While healthcare entities are often aware of the typical consequences of a ransomware attack such as reputational harm, administrative burden and financial costs, it is important to recognise that losses associated with a large-scale breach may be severe and lasting in terms of loss of data, implementation of additional security measures and other corrective actions, and erosion of patient and provider confidence. Moreover, a recent study found that data breach remediation efforts, particularly those related to ransomware attacks, can be associated with decreased patient care outcomes and negatively impacted timeliness of care.
In addition to the direct threat of infiltration to a healthcare system, covered entities should be aware of the risk of ransomware attacks on their business associates and how breaches at the vendor level can affect the covered entity's operations. For example, cloud computing provider Blackbaud, Inc, became aware of a large-scale ransomware attack in May 2020 that had been ongoing for approximately three months. According to information obtained from the cloud provider's public statements and required government notifications, a cybercriminal exfiltrated a subset of data from a self-hosted environment affecting millions of individuals across dozens of healthcare entities nationwide. Blackbaud indicated in a press release that it remedied the ongoing issue by paying the hacker's demanded ransom, conditioned on receipt of a certificate of destruction. While this is a common approach taken by ransomware victims, both the FBI and OCR have recommended against paying ransoms, and there is now increased risk associated with payment in light of recent guidance issued by the US Department of Treasury's Office of Foreign Assets Control (OFAC) stating that entities can run afoul of US sanctions laws if they make ransomware payments to certain cybercriminals who are sanctioned or otherwise have a sanctions nexus. The 2017 WannaCry attack, for example, the first to widely target vulnerabilities commonly found in medical devices, is believed to have been sponsored by the North Korean government.
Business email compromise and phishing
While ransomware attacks have increased in frequency and scale since the onset of the covid-19 pandemic, phishing attempts and targeted email compromise campaigns are likely the most common cybersecurity attacks on the healthcare industry. Healthcare entities should ensure employees are routinely trained to be aware of the threat of phishing and typical techniques used in third-party emails that attempt to obtain sensitive information, like employee account compromise, high-level executive fraud or impersonation, and bogus invoice schemes.
For example, spear phishing attempts in the healthcare sector often take timely topics and use targeted messaging to infiltrate an unsuspecting recipient's system. Beginning in 2020, business email compromise schemes frequently utilised information about covid-19, particularly within the healthcare industry. HHS has recently issued notifications regarding emails from hackers posing as the Centers for Disease Control and Prevention and claiming to provide information on covid-19 safety measures or a link to an 'incident management system', or posing as company employees providing a link to a new 'disease management policy'. At the height of the covid-19 pandemic, hackers impersonated suppliers to persuade in-house purchasing department employees to initiate wire transfers for personal protective equipment (PPE). Agent Tesla, a remote access trojan capable of providing attackers with full computer or network access via accessing credentials, sensitive information, key strokes, screen activity and form-grabbing, launched a number of covid-19-related phishing campaigns specifically targeting the healthcare sector, including those with malware-containing attachments such as 'COVID 19 NEW ORDER FACE MASKS' or 'COVID-19 Supplier Notice'.
Insider threats play a disproportionately large role in the healthcare space, and OCR recently observed that 69 per cent of data breaches involving health sector entities had some nexus to an insider acting intentionally or inadvertently. OCR recommends that the best way to guard against insider threats is to detect and prevent leakage of data through certain security protocols and processes. In terms of security processes, organisations should be aware of where data is stored, who is permitted to access specific types of data within the organisation, and how such authorised users are permitted to interact with the data. OCR recommends that organisations implement safeguards, detection software and audits to promptly identify unauthorised access, and to be especially mindful of these processes in high-risk situations, such as when an employee is involuntarily terminated.
Advanced persistent threats
Long-term cybersecurity attacks, often originating from hostile, state-sponsored foreign actors, are known as advanced persistent threats (APT). OCR has observed that the most concerning aspect of APTs is the ability of the threat actor to remain undetected by constantly modifying tactics that allow the APT to persist within an entity's IT system. APTs are routinely engaged in cybersecurity attacks on healthcare entities in the United States and abroad and frequently involve zero-day exploits. OCR recommends implementing certain safeguards, such as encryption and access controls to mitigate the harm caused by APTs. The HHS Cybersecurity Program has recommended additional tactics that organisations may implement to mitigate the potential harm caused by APTs: security monitoring, understanding APT tactics, increased identification of APTs, updating networks and VPNs, and maintaining up-to-date IT resources to prevent vulnerabilities.
Internet of Medical Things
Internet of Medical Things (IoMT) devices are able to collect, analyse, and transmit healthcare data, saving the healthcare industry billions of dollars annually due their ability to facilitate remote patient monitoring. The increase in IoMT is due, in part, to the increased number of connected medical devices, with approximately 120 million connected IoMT devices in the United States alone, all of which are potentially vulnerable to cyberattack. Like the risk posed by insider threats, the IoMT is subject to human error, resulting in inadvertent breaches of valuable information. To reduce the human factor, experts recommend the removal of hard-coded passwords to mitigate the risks of cyberattacks and subsequent breaches, in particular, those tied to a privileged account with universal access and permissions.
Best practices for managing cyber intrusions
The threat of cyber intrusions in healthcare is varied, complex, and has the potential to trigger substantial liability on the part of providers under the myriad of laws and regulations that may be implicated by a breach. Medical records and other PHI are highly valued bundles of information that command high prices on the dark web, thereby further encouraging cybercriminals to target healthcare providers. As such, being prepared for – and effectively responding to and managing – a security incident or breach of EHI is essential, particularly in light of the demanding regulatory requirements that apply to cybersecurity in the healthcare industry.
Risk assessments and security audits
The threshold step in preventing and mitigating security incidents and PHI-related breaches requires conducting a risk analysis that identifies and implements safeguards that carry out Security Rule standards and implementation specifications. The risk analysis should be 'an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate'. According to HHS, a risk analysis is 'foundational' to an entity's compliance with the Security Rule and the protection of EHI. Providers and their business associates should conduct an initial risk analysis and thereafter periodically repeat risk analyses as technology, amount or type of EHI, or other circumstances change, and when threats are detected.
OCR issues annual guidance on the Security Rule and has consistently explained that the risk analysis is not a 'one size fits all' undertaking and does not guarantee compliance with the Security Rule. Instead, OCR maintains that each risk analysis must be tailored to the 'characteristics of the organization and its environment'. Accordingly, covered entities and business associates should regularly review their size and complexity, the volume of their EHI and how such EHI is used, and their technical capabilities and available resources. Because these factors can change rapidly, particularly as technology develops and healthcare delivery models evolve, entities subject to HIPAA's Security Rule should assure that IT resources are current and commensurate with the amount and content of their EHI and the ways in which they use EHI.
OCR suggests that the following non-exhaustive list of questions can help guide an organisation's risk analysis:
- Has the organisation identified all the EHI that it creates, receives, maintains, or transmits?
- What are the external sources of EHI? For example, do vendors or consultants create, receive, maintain, or transmit EHI?
- What are the human, natural, and environmental threats to information systems that contain EHI?
OCR guidance also delineates specific areas that regulated entities should consider as a part of a comprehensive HIPAA-compliant risk analysis:
- Assess current security measures. Organizations should assess and document the security measures an entity uses to safeguard EHI, whether security measures required by the Security Rule are in place, and if current security measures are configured and used properly.
- Determine the likelihood of threat occurrence. The Security Rule requires organisations to take into account the probability of potential risks to EHI. The results of this assessment, combined with the initial list of threats, will influence the determination of which threats the Security Rule requires protection against because they are 'reasonably anticipated'.
- Determine the potential impact of threat occurrence. The Security Rule requires consideration of the 'criticality', or impact, of potential risks to confidentiality, integrity and availability of EHI.
- Determine the level of risk. Organisations should assign risk levels for all threat and vulnerability combinations identified during the risk analysis.
Ultimately, covered entities and business associates should carefully consider the threat environment in which they operate and tailor the frequency of the risk assessment accordingly. For example, a provider that is a hospital system operating in multiple locations and providing services to a large number of patients – and any business associates of such provider – should strongly consider an annual or more frequent risk assessment to ensure that their systems and processes are secure. Regardless of an entity's size and sophistication, however, a risk assessment may also be needed if the entity introduces new technologies to its operations; acquires other entities or facilities; or becomes aware of a specific type of breach experienced by a similarly situated entity.
While the Security Rule does not require a specific format for documenting an entity's risk analysis, it does require the risk analysis be documented, and providers should take care to do so.
Security incident and breach response
To respond effectively to a security incident and a potential breach of EHI, covered entities and business associates should have clear security incident procedures and response and reporting processes in place before the incident occurs. The security incident response plan should outline steps to take when a security incident occurs or is suspected. An entity's workforce should be adequately trained regarding how to identify a security incident, including understanding early indications of a ransomware attack and common business email compromise and phishing schemes, and how and to whom to report a security incident or a breach of EHI. Entities should have a data back-up plan that creates and maintains retrievable exact copies of EHI; a disaster recovery plan that includes procedures to restore loss of data; and an emergency mode operation plan that includes procedures to enable continuation of critical business processes and protection of the security of EHI while operating during an emergency. Entities should periodically test and revise contingency and emergency response plans, assess the criticality of specific applications and data in support of other contingency plan components, and should periodically re-evaluate policies and procedures to confirm that they continue to meet Privacy and Security Rule requirements.
When covered entities or business associates become aware of a potential security incident, it is critical to respond in an organised, focused and prompt manner. The entity should have a designated team of response experts – whether inside or outside the entity – that is tasked with receiving reports of security incidents, responding promptly and investigating such reports. This response team should be able to identify, contain and ultimately eliminate the source of the incident and restore the entity's IT systems to a secure state. The response team should, among other things, identify:
- the genesis of the suspected incident;
- the type and nature of the incident;
- the duration of the incident and whether it is ongoing;
- the extent of the incident, including affected data types and systems;
- whether a breach of EHI occurred and, if so, the identities of affected individuals (which may include workforce members and patients); and
- the necessary steps to stop the incident (if ongoing) and re-secure the affected information systems.
In the event of a ransomware attack, the response team also should advise the entity, along with legal counsel, on whether and how the compromised data may be retrieved.
As soon as the incident or breach is discovered, the entity should consult legal counsel to determine whether the incident must be reported, to whom, to what extent, and within what time frame. Even if an investigation is ongoing, immediate consideration of these matters is essential, as the Breach Notification Rule requires notice to affected individuals 'without unreasonable delay', and in no event more than 60 days from the date of discovery. Moreover, given the host of state laws that may be applicable in addition to HIPAA, determining whether the incident is reportable and to which agencies, and whether individual and media notices are required, is a critical but complex analysis. Legal counsel, therefore, must become intimately familiar with the incident and its impacts to effectively assess the entity's reporting obligations and to help develop an appropriate timeline for reporting.
Heightened vigilance and responsiveness in a post-covid world
The covid-19 pandemic has heightened the need for covered entities and business associates to comprehensively conduct risk assessments and promptly respond to suspected breaches. As the United States raced to develop and deploy effective covid-19 vaccines and tens of millions of Americans received treatment and vaccinations in 2020 and 2021, healthcare providers were inundated with PHI. Hackers and other cybercriminals were aware of this, making healthcare providers increased targets for breaches.
Of particular concern surrounding the covid-19 pandemic and cybersecurity is the fact that the pandemic was not and is not an isolated public health crisis, but one that will last for years. As such, hackers and cybercriminals may have been more inclined during the pandemic to breach providers' systems and to lie in wait to collect the myriad of PHI that continues to be collected throughout the pandemic. Such a breach tactic is not without precedent in healthcare. For example, in January 2021, HHS announced a US$5.1 million settlement with Excellus Health Plan (Excellus), a health services corporation that provides health insurance coverage to citizens of New York State. In September 2015, Excellus reported that a breach lasting from December 2013 to May 2015 resulted in the impermissible disclosure of 9.3 million individuals' PHI. According to OCR, the hackers roamed undetected in Excellus's systems for over a year harvesting PHI.
The Excellus settlement serves to underscore the increased need for vigilance in the covid-19 and post-covid-19 world. In particular, due to the heightened potential for long-term attacks during the pandemic like the one demonstrated in the Excellus matter, entities should consider engaging in routine risk assessments to identify potential security vulnerabilities and breaches as early as possible.
1 David C Rybicki, Gina L Bertolini and John H Lawrence are partners at K&L Gates LLP.
2 As a general rule, HIPAA preempts state laws pertaining to the privacy and security of health information, except where state laws provide greater privacy protections than those contained in the HIPAA Privacy Rules. In addition, many state laws mandate security incident or breach notification provisions in addition to those outlined in HIPAA's Privacy and Security Rules. Accordingly, because HIPAA may not be the only regulatory framework that healthcare sector entities must observe in relation to data privacy and security, they should be mindful of other state and federal laws that apply to certain sensitive data, such as substance use disorders, genetic information, mental health, and other sensitive diagnoses.
3 45 CFR § 160.103.
4 The HITECH Act was enacted as Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (ARRA), Pub. L. 111-5, 42 U.S.C. § 17934. HITECH applies to certain of HIPAA's privacy and security provisions and creates liability for business associates under HIPAA's Privacy and Security Rules. Prior to this statute and HHS's 2013 HIPAA Final Rule, 78 Fed. Reg. 5566 (25 January 2013), et seq., business associate liability was limited to contractual remedies available under a mandatory Business Associate Agreement (BAA) with a covered entity. Although the 2013 Final Rule identified specific provisions of HIPAA that apply to business associates, BAAs are still mandatory under HIPAA. The HITECH Act also established breach notification obligations through implementation of the Breach Notification Rule and expanded penalties for violations of the Privacy and Security Rules.
5 45 CFR § 160.401, et seq.
6 See, e.g., HHS.gov, Health Insurer Pays $5.1 Million to Settle Data Breach Affecting Over 9.3 Million People, 15 January 2021, https://www.hhs.gov/about/news/2021/01/15/health-insurer-pays-5-1-million-settle-data-breach.html.
7 45 CFR § 164.306(a).
8 id. § 164.306(b)(1).
9 id. § 164.306(b)(2).
10 id. § 164.306(d)(3).
11 id. § 164.308.
12 id. § 164.308(a)(1)(ii), (a)(2), (b)(8).
13 id. § 164.308(a)(4), (a)(5)(ii), (a)(6), (a)(7)(i).
14 id. § 164.310(a)(2), (b)(2), (d)(1)–(d)(2).
15 id. § 164.312.
16 id. § 164.314.
17 id. § 164.508(c)(2)(iii).
18 id. § 164.502(a)(2).
19 id. § 164.502(a)(1). The term 'healthcare operations' refers to certain administrative, financial, legal, and quality improvement activities necessary to support the covered entity's treatment and payment functions. Id. § 164.501.
20 id. § 164.501.
21 id. § 164.502(e)(2); see id. § 164.508(b)(3).
22 id. § 164.404.
23 id. § 164.402.
24 id. §§ 164.404, 164.408.
25 id. §§ 164.406.
26 id. § 164.402(1).
27 id. § 164.402(2).
28 Bitglass, Healthcare Breach Report 2021: Hacking and IT Incidents on the Rise, 2021, available at https://pages.bitglass.com/rs/418-ZAL-815/images/CDFY21Q1HealthcareBreachReport2021.pdf?aliId=eyJpIjoiOE54NGRRTkhCZDY3aUxGMiIsInQiOiJ0RTZ1QVZXbnFPUGRhZXhVbmhy
29 See US Dep't of Health & Human Servs. Office of Civ. Rights Breach Portal, https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf [hereinafter, OCR Breach Portal].
30 See OCR Breach Portal.
31 See id.
32 See id.
33 Tenable, The Tenable Research 2020 Threat Landscape Retrospective, 14 January 2021, www.tenable.com/blog/tldr-the-tenable-research-2020-threat-landscape-retrospective.
34 Comparitech, Ransomware Attacks on US Healthcare Organizations Cost $20.8bn in 2020, 10 March 2021, www.comparitech.com/blog/information-security/ransomware-attacks-hospitals-data/.
35 See SecurityScorecard & Darkowl, Listening to Patient Data Security: Healthcare Industry and Telehealth Cybersecurity Risks at 7-17 (2020), available at https://securityscorecard.com/resources/healthcare-industry-telehealth-cybersecurity-risks-report.
36 Cybersecurity & Infrastructure Security Agency et al., Alert (AA20-302A): Ransomware Activity Targeting the Healthcare and Public Health Sector, 28 October 2020, https://us-cert.cisa.gov/ncas/alerts/aa20-302a.
37 Sung J Choi, et al., Data breach remediation efforts and their implications for hospital quality, Health Services Research, Sept. 10, 2019.
38 Blackbaud Newsroom, Learn more about the Ransomware attack we recently stopped, 16 July 2020, www.blackbaud.com/newsroom/article/2020/07/16/learn-more-about-the-ransomware-attack-we-recently-stopped.
39 Federal Bureau of Investigation, Ransomware, www.fbi.gov/scams-and-safety/common-scams-and-crimes/ransomware; Cyber Extortion, US Dep't of Health and Human Services, Office for Civil Rights, January 2018, www.hhs.gov/sites/default/files/cybersecurity-newsletter-january-2018.pdf.
40 US Dep't of Treasury, Advisory on Potential Sanctions Risks for Facilitating Ransomware Payments, October 2020, https://home.treasury.gov/system/files/126/ofac_ransomware_advisory_10012020_1.pdf.
41 AHA Center for Health Innovation, Ransomware Attacks on Hospitals Have Changed, 15 May 2020, www.aha.org/center/cybersecurity-and-risk-advisory-services/ransomware-attacks-hospitals-have-changed.
42 HHS Cybersecurity Program, Business Email Compromise in the Health Sector, 9 July 2020, www.hhs.gov/sites/default/files/business-email-compromise-in-the-health-sector.pdf [hereinafter Business Email Compromise in the Health Sector].
43 Coronavirus Theme E-mail Phishing, Health Sector Cybersecurity Coordination Center (HC3), 3 February 2020, www.hhs.gov/sites/default/files/coronavirus-themed-email-phishing.pdf.
44 See Business Email Compromise in the Health Sector.
45 Health Sector Cybersecurity Coordination Center (HC3), Remote Access Trojan 'Agent Tesla' Targets Organizations with COVID-themed Phishing Attacks, 16 June 2020, www.hhs.gov/sites/default/files/remote-access-trojan-agent-tesla-targets-organizations-covid-themed-phishing-attacks.pdf.
46 See HHS.gov, Summer 2019 OCR Cybersecurity Newsletter, 29 August 2019, www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity-newsletter-summer-2019/index.html.
47 See id.
48 See id.
49 See id.
50 See id.
51 See id.
52 See TechTarget IoT Agenda, IoMT: A pulse on the internet of medical things, 8 August 2020, https://internetofthingsagenda.techtarget.com/blog/IoT-Agenda/IoMT-A-pulse-on-the-internet-of-medical-things.
53 See HealthTech, What Makes IoMT Devices So Difficult to Secure? 25 February 2020, https://healthtechmagazine.net/article/2020/02/what-makes-iomt-devices-so-difficult-secure-perfcon.
54 See id.
55 HHS.gov, Guidance on Risk Analysis, 22 July 2019, www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html [hereinafter, HHS Guidance on Risk Analysis].
56 45 CFR § 164.308(a)(1)(ii)(A).
57 HHS Guidance on Risk Analysis.
61 See 45 CFR §§ 164.306(b)(1), 164.308(a)(1)(ii)(A), and 164.316(b)(1).
62 id. § 164.306(b)(2)(iv).
64 See id. §§ 164.306(a)(2), 164.308(a)(1)(ii)(A), & 164.316(b)(1).
65 See id. § 164.316(b)(1).
66 OCR recommends that entities periodically conduct test restorations to verify the integrity of back-up data and, because some ransomware variants remove or otherwise disrupt online back-ups, consider maintaining offline backups. See FACT SHEET: Ransomware and HIPAA, available at www.hhs.gov/sites/default/files/RansomwareFactSheet.pdf.
67 The presence of ransomware (or any malware) is a security incident under HIPAA that may result in an impermissible disclosure of EHI in violation of the Privacy Rule and, depending on the facts and circumstances, may constitute a breach, as defined by the Privacy Rule.
68 HHS.gov, Health Insurer Pays $5.1 Million to Settle Data Breach Affecting Over 9.3 Million People, 15 January 2021, www.hhs.gov/about/news/2021/01/15/health-insurer-pays-5-1-million-settle-data-breach.html.