Upcoming Webinars

Site Updates

Disclaimer

The analysis of any legal or medical billing is dependent on numerous specific facts — including the factual situations present related to the patients, the practice, the professionals and the medical services and advice. Additionally, laws and regulations and insurance and payer policies are subject to change. The information that has been accurate previously can be particularly dependent on changes in time or circumstances. The information contained in this web site is intended as general information only. It is not intended to serve as medical, health, legal or financial advice or as a substitute for professional advice of a medical coding professional, healthcare consultant, physician or medical professional, legal counsel, accountant or financial advisor. If you have a question about a specific matter, you should contact a professional advisor directly. CPT copyright American Medical Association. All rights reserved. CPT is a registered trademark of the American Medical Association.

Menu
Log in


Log in

HIPAA Cybersecurity Updates

  • 25 Oct 2022 1:22 PM | Zachary Edgar (Administrator)

    HIPAA Security Rule Security Incident Procedures

    Every October, in recognition of National Cybersecurity Awareness Month, the federal government and its partners work to educate stakeholders on cybersecurity awareness and how best to protect the privacy and security of confidential data. Within the health care industry, the HIPAA Security Rule1 applies to covered entitiesand their business associates (“regulated entities”) and electronic protected health information (ePHI). Because ePHI identifies individuals and includes information relating to an individual’s health, treatment, or payment information, it is a valuable target for cyber-criminals.

    Cybersecurity incidents and data breaches continue to increase across all industries. A 2022 cybersecurity firm report noted a 42% increase in cyber-attacks for the first half of 2022 compared to 2021, and a 69% increase in cyber-attacks targeting the health care sector. The number of data breaches occurring in the health care sector also continue to rise. Breaches of unsecured protected health information (PHI), including ePHI, reported to the HHS Office for Civil Rights (OCR) affecting 500 or more individuals increased from 663 in 2020 to 714 in 2021. Seventy-four percent (74%) of the breaches reported to OCR in 2021 involved hacking/IT incidents. In the health care sector, hacking is now the greatest threat to the privacy and security of PHI. A timely response to a cybersecurity incident is one of the best ways to prevent, mitigate, and recover from cyberattacks.

    The HIPAA Security Rule requires regulated entities to “implement policies and procedures to address security incidents.”  This means regulated entities need to have a plan in place and documented for responding to security incidents (suspected or known) that includes:

    • Identifying security incidents;
    • Responding to security incidents;
    • Mitigating harmful effects of security incidents; and
    • Documenting security incidents and their outcomes.

    Security incidents will almost inevitably occur during the lifetime of a regulated entity. Having a plan established and documented is essential to being able to detect security incidents quickly in order to respond to and recover from security incidents effectively.

    Forming a Security Incident Response Team

    In preparing their security incident response process, regulated entities should consider forming a security incident response team that is organized and trained to effectively respond to security incidents.

    There are many options to consider when it comes to forming a security incident response team. In Special Publication 800-61 Computer Security Incident Handling Guide - PDF, the National Institute of Standards and Technology (NIST) provides several areas to consider when forming a security incident response team, including:

    • Selecting a team structure and staffing (e.g., use a centralized or distributed model, staff with full-time employees or partially outsource, ensure team members have appropriate expertise – organizational and technical)
    • Establishing relationships and lines of communication between the security incident response team and other groups (both internal and external)
    • Identifying internal groups that may need to participate in incident handling (e.g., management, information technology support, legal, public affairs and communications, human resources, business continuity/disaster recovery, physical security, facilities management)
    • Identifying points of contact at external groups that may be helpful to include in the event of an incident (e.g., network service providers, software and hardware vendors, local and federal law enforcement, incident handling teams of business partners and customers)
    • Determining what services the security incident response team should provide (e.g., intrusion detection, advisory distribution, education and awareness, information sharing)

    Once formed, the security incident response team should conduct regular testing of security incident procedures. This could involve conducting tests involving different types of potential security incident scenarios, for example, a malicious insider exfiltrating sensitive information, a cyber-criminal’s infiltration and deployment of ransomware, or a distributed denial of service (DDoS) attack that interrupts system operations. Security incident procedures should be updated with lessons learned from testing as well as from actual security incidents to improve the team’s response and effectiveness.

    Within the HIPAA Security Rule regulation itself, there are many helpful steps that regulated entities must take to protect against cyber threats. 

    Identifying Security Incidents

    The HIPAA Security Rule defines a security incident as “the attempted or successful unauthorized access, use exit, disclosure exit, modification, or destruction of information or interference with system operations in an information system.”

    Having audit logs in place and regularly reviewing such logs are actions that regulated entities are required to take and greatly improve their ability to identify security incidents early. The HIPAA Security Rule audit controls standard requires that regulated entities, “implement hardware, software, and/or procedural mechanisms to record and examine access and other activity in information systems that contain or use electronic protected health information.” For example, log filesmay be able to help identify when and how a cyber-criminal entered an information system and what activities occurred. The HIPAA Security Rule information system activity review implementation specification also requires regulated entities to "implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports."

    By recording information system events, alerts, user actions, and other activities in appropriate logs and conducting regular reviews of such logs, regulated entities will have mechanisms and procedures in place to record and review information system activity and be able to identify and respond to security incidents quickly.

    Responding to Security Incidents

    When responding to a security incident, a regulated entity should contain the security incident and any threat it may pose to ePHI and take appropriate action(s) to ensure the confidentiality, integrity, and availability of its ePHI. Failing to do so could have a wide range of negative repercussions, including identity theft, financial loss, or negative consequences to the reputation or safety of the individual.  Important steps to ensure that the threat is neutralized include:

    • ·       Determining the nature and extent of the damage caused by the security incident;
    • ·       Identifying and removing any malicious code and components that the security incident may have left behind; and
    • ·       Mitigating any vulnerabilities that may have permitted the security incident to occur.

    Collecting and preserving data relevant to investigating the security incident, such as log files, registry keys, and other artifacts, should also be part of security incident response activities.

    To be better prepared to respond to security incidents, regulated entities should consider including the following as part of their security incident procedures:

    • Designating appropriate personnel (qualified internal resources and/or external third parties) to be members of the security incident response team;
    • A communication plan and contact information for notifying all members of the security incident response team, and others as required (e.g., management) when a security incident occurs;
    • Processes to identify and determine the scope of security incidents;
    • Instructions for managing the security incident;
    • Creating and maintaining a list of assets (computer systems and data) to prioritize when responding to a security incident;
    • Conducting a forensic analysis to identify the extent and magnitude of the security incident;
    • Reporting the security incident to appropriate internal and external entities (e.g., the regulated entity’s IT and legal departments, local FBI Cyber Taskforce Field Office, federal and state regulatory authorities, and other individuals or entities as required);
    • Processes for collecting and maintaining evidence of the security incident (e.g., log files, registry keys, and other artifacts) to determine what was accessed during the security incident;
    • Processes for conducting regular tests of the security incident response process.

    While each security incident has its own set of facts that require a well-tailored response, regulated entities should develop a process for security incidents that commonly occur. For example, a regulated entity might have a specific process for responding to a ransomware attack and other processes for responding to insider malicious activity, cyber-attacks from hackers, and phishing attacks. Specific processes addressing common types of security incidents can improve workforce members’ understanding of what to do and the regulated entity’s speed in responding to these security incidents.

    Mitigating Harmful Effects of a Security Incident

    After the security incident has been neutralized and any malware removed, the next steps should include mitigating the harmful effects of the security incident including recovery and restoration of systems and data to return to normal operations. A critical component of an effective recovery from a security incident is preparation. The HIPAA Security Rule requires that regulated entities establish a contingency plan. The cornerstones of any data centric contingency plan must include robust data backup and recovery processes.  Data backup and disaster recovery plans are required implementation specifications of the HIPAA Security Rule’s contingency standard.

    Frequent backups and verification of the integrity of the backed-up data are crucial to being able to recover data that may have been deleted or had its integrity compromised as a result of a security incident. Backup logs should be reviewed regularly, and test restorations of backups conducted periodically to ensure the integrity of backups and provide confidence in the regulated entity’s ability to restore its data. Because some malware, including some ransomware variants, are known to delete or otherwise disrupt online backups, regulated entities should consider maintaining at least some of their backups offline and unavailable from their networks.

    When backing up data, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) recommends following the “3-2-1” backup strategy:

    • Keep 3 copies of important data – 1 primary copy and 2 backup copies;
    • Keep backups on 2 different media types (e.g., local disk, hosted cloud, removable media);
    • Keep at least 1 of your backup copies offsite.

    Depending on the nature of the security incident and damage caused, the recovery process may involve one or more of the following processes recommended by CISA in its Eradicate & Recover procedures for cybersecurity incidents:

    • Reimage affected systems from clean backups;
    • Rebuild systems from scratch (i.e., install operating system and application software from trusted media or vendor sources);
    • Rebuild hardware (especially if rootkit malware was found or suspected);
    • Replace compromised files with known good versions;
    • Install current updates and patches;
    • Reset passwords and implement multi-factor authentication.

    Documenting the Security Incident

    Once a security incident has ended, systems and data have been restored, and operations have returned to normal, regulated entities should document their response and analysis into a record of the security incident.  This record can be used to synthesize lessons learned to improve future response activities and may be helpful for regulatory purposes if applicable. The HIPAA Security Rule requires regulated entities to document security incidents and their outcomes. A regulated entity’s security incident procedures should include a section on documenting security incidents and what information to include in the documentation (e.g., discovery of the security incident; systems and data affected; response and mitigation activities; recovery outcomes; root cause analysis; forensic data collected).

    Understanding your Breach Reporting Obligations

    When considering their security incident procedures and how to respond to security incidents, regulated entities need to be mindful of their obligation to report breaches of unsecured PHI. The Breach Notification Rule requires covered entities to report breaches affecting 500 or more individuals to the affected individuals, to OCR, and (in certain cases) to the media without unreasonable delay and no later than 60 calendar days from the discovery of the breach. 

    Covered entities are required to report breaches affecting less than 500 individuals to the affected individuals without unreasonable delay and no than 60 calendar days from the discovery of the breach and to OCR no later than 60 days after the end of the calendar year in which the breach was discovered. It is important for covered entities to note that the “the time period [for reporting] begins when the incident is first known, not when the investigation of the incident is complete, even if it is initially unclear whether the incident constitutes a breach as defined in the rule.”  Further, 60 days is the outer limit for notification and, “in some cases, it may be an ‘unreasonable delay’ to wait until the 60th day to provide notification.”

    Recent Resolution of OCR Investigation

    In July 2022, OCR announced the resolution of an investigation of Oklahoma State University – Center for Health Sciences concerning a hacker gaining unauthorized access to a web server that contained ePHI.  The hacker installed malware that resulted in the disclosure of the ePHI of 279,865 individuals, including their names, Medicaid numbers, healthcare provider names, dates of service, dates of birth, addresses, and treatment information.  OSU-CHS initially reported that the breach occurred on November 7, 2017, but later reported that the ePHI was first impermissibly disclosed on March 9, 2016.

    OCR’s investigation found potential violations of the HIPAA Rules including impermissible uses and disclosures of PHI; failure to conduct an accurate and thorough risk analysis; failure to perform an evaluation, failures to implement audit controls, security incident response and reporting, and failure to provide timely breach notification to affected individuals and HHS.  OCR successfully resolved this investigation with a monetary settlement of $875,000, and a resolution agreement and corrective action plan that includes two years of OCR monitoring.

    The policies and procedures regulated entities create to prepare for and respond to security incidents can pay dividends in the long run with faster recovery times and reduced compromises of ePHI. A well thought-out, well-tested security incident response plan is integral to ensuring the confidentiality, integrity, and availability of a regulated entity’s ePHI.

    Reference

    U.S. Department of Health & Human Services

    Office for Civil Rights (OCR)

    Fall 2022 OCR Cybersecurity Newsletter


  • 17 Mar 2022 1:16 PM | Zachary Edgar (Administrator)

    Defending Against Common Cyber-Attacks

    Throughout 2020 and 2021, hackers have targeted the health care industry seeking unauthorized access to valuable electronic protected health information (ePHI).  The number of breaches of unsecured ePHI reported to the U.S Department of Health and Human Service’s Office for Civil Rights (OCR) affecting 500 or more individuals due to hacking or IT incidents increased 45% from 2019 to 2020.  Further, the number of breaches due to hacking or IT incidents accounted for 66% of all breaches affecting 500 or more individuals reported to OCR in 2020.

    Although some attacks may be sophisticated and exploit previously unknown vulnerabilities (i.e., zero-day attack), most cyber-attacks could be prevented or substantially mitigated if HIPAA covered entities and business associates (“regulated entities”) implemented HIPAA Security Rule requirements to address the most common types of attacks, such as phishing emails, exploitation of known vulnerabilities, and weak authentication protocols.  If an attack is successful, the attacker often will encrypt a regulated entity’s ePHI to hold it for ransom, or exfiltrate the data for future purposes including identify theft or blackmail.  Cyber-attacks are especially critical in the health care sector as attacks on ePHI can disrupt the provision of health care services to patients.  This newsletter explores preventative steps regulated entities can take to protect against some of the more common, and often successful, cyber-attack techniques.

    Phishing

    One of the most common attack vectors is phishing.  Phishing is a type of cyber-attack used to trick individuals into divulging sensitive information via electronic communication, such as email, by impersonating a trustworthy source.  A recent report noted that 42% of ransomware attacks in Q2 2021 involved phishing.  All regulated entities’ workforce members should understand they have an important role in protecting the ePHI their organization holds from cyber-attacks.  Part of that role involves being able to detect and take appropriate action if one encounters suspicious email.  To ensure workforce members can take appropriate action, regulated entities should train their workforce members to recognize phishing attacks and implement a protocol on what to do when such attacks or suspected attacks occur (e.g., report suspicious emails to appropriate IT personnel).

    The Security Rule requires regulated entities to implement a security awareness and training program for all workforce members.  A regulated entity’s training program should be an ongoing, evolving process and be flexible enough to educate workforce members on new and current cybersecurity threats (e.g., ransomware, phishing) and how to respond.  Management personnel should also participate, as senior executives may have greater access to ePHI and are often targeted in phishing email attacks (e.g., whaling).

    Regulated entities should follow up on security training with periodic security reminders.  The Security Rule includes an addressable provision for such reminders.  An example of a security reminder is sending simulated phishing emails to workforce members to gauge the effectiveness of their security awareness and training program and offer additional, targeted training where necessary.  An educated workforce can be an effective first line of defense and an integral part of a regulated entity’s strategy to defend, mitigate, and prevent cyber-attacks.  Unfortunately, security training can fail to be effective if it is viewed by workforce members as a burdensome, “check-the-box” exercise consisting of little more than self-paced slide presentations.  Regulated entities should develop innovative ways to keep the security trainings interesting and keep workforce members engaged in understanding their roles in protecting ePHI.

    In addition to education, regulated entities can mitigate the risk of phishing attacks by implementing anti-phishing technologies.  Anti-phishing technologies can take several approaches.  One approach examines and verifies that received emails do not originate from known malicious sites.  If an email is suspected of being a threat, it can be blocked and appropriate personnel notified.  Other approaches can involve scanning web links or attachments included in emails for potential threats and removing them if a threat is detected.  Newer techniques can leverage machine learning or behavioral analysis to detect potential threats and block them as appropriate.  Many available technology solutions use a combination of these approaches. 

    Regulated entities are required to ensure the integrity of ePHI by implementing “policies and procedures to protect ePHI from improper alteration or destruction.”  In addition, the Security Rule requires regulated entities to assess and reduce risks and vulnerabilities to the availability of ePHI (as well as its confidentiality and integrity), which is defined as “the property that data or information is accessible and useable upon demand by an authorized person.”  Anti-phishing technologies can impede or deny the introduction of malware that may attempt to improperly alter, destroy, or block authorized access to ePHI (e.g., ransomware), and thus can be a helpful tool to preserve the integrity and availability of ePHI.

    Combining an engaged, educated workforce with technical solutions gives regulated entities the best opportunity to reduce or prevent phishing attacks.

    Exploiting Known Vulnerabilities

    Hackers can penetrate a regulated entity’s network and gain access to ePHI by exploiting known vulnerabilities.  A known vulnerability is a vulnerability whose existence is publicly known. The National Institute of Standards and Technology (NIST) maintains the National Vulnerability Database (NVD), which provides information about known vulnerabilities.  Exploitable vulnerabilities can exist in many parts of a regulated entity’s information technology infrastructure (e.g., server, desktop, and mobile device operating systems; application, database, and web software; router, firewall, and other device firmware).  Often, known vulnerabilities can be mitigated by applying vendor patches or upgrading to a newer version.  If a patch or upgrade is unavailable, vendors often suggest actions to take to mitigate a newly discovered vulnerability.  Such actions could include modifications of configuration files or disabling of affected services.  Regulated entities should pay careful attention to cybersecurity alerts describing newly discovered vulnerabilities.  These alerts (several sources of which are enumerated below) often include information on mitigation activities and patching.

    Although older applications or devices may no longer be supported with patches for new vulnerabilities, regulated entities should still take appropriate action if a newly discovered vulnerability affects an older application or device.  Regulated entities should upgrade or replace obsolete, unsupported applications and devices (legacy systems).  However, if an obsolete, unsupported system cannot be upgraded or replaced, additional safeguards should be implemented or existing safeguards enhanced to mitigate known vulnerabilities until upgrade or replacement can occur (e.g., increase access restrictions, remove or restrict network access, disable unnecessary features or services).

    Regulated entities are required to implement a security management process to prevent, detect, contain, and correct security violations.  This process includes conducting a risk analysis to assess potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI and implementing security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.  The HIPAA Security Rule requires the risk analysis to be accurate and thorough, and thus it should include processes that identify potential technical and non-technical vulnerabilities.  Technical vulnerabilities may include “holes, flaws or weaknesses in the development of information systems; or incorrectly implemented and/or configured information systems.”

    Regulated entities can identify technical vulnerabilities to include in their risk analysis in a number of ways including:

    • Subscribing to Cybersecurity and Infrastructure Security Agency (CISA) alerts and bulletins;
    • Subscribing to alerts from the HHS Health Sector Cybersecurity Coordination Center (HC3);
    • Participating in an information sharing and analysis center (ISAC) or information sharing and analysis organization (ISAO);
    • Implementing a vulnerability management program that includes using a vulnerability scanner to detect vulnerabilities such as obsolete software and missing patches; and
    • Periodically conducting penetration tests to identify weaknesses that could be exploited by an attacker.

    Regulated entities should not rely on only one of the above techniques, but rather should consider a combination of approaches to properly identify technical vulnerabilities within their enterprise.  Once identified, assessed, and prioritized, appropriate measures need to be implemented to mitigate these vulnerabilities (e.g., apply patches, harden systems, retire equipment).

    Weak Cybersecurity Practices

    A regulated entity that has weak cybersecurity practices makes itself an attractive soft target.  Weak authentication requirements are frequent targets of successful cyber-attacks (over 80% of breaches due to hacking involved compromised or brute-forced credentials).  Weak password rules and single factor authentication are among the practices that can contribute to successful attacks.  Once inside an organization, weak access controls can further contribute to an attacker’s ability to compromise systems by accessing privileged accounts, moving to multiple computer systems, deploying malicious software, and exfiltrating sensitive data.

    Regulated entities are required to verify that persons or entities seeking access to ePHI are who they claim to be by implementing authentication processes.  A regulated entity’s risk analysis should guide its implementation of appropriate authentication solutions to reduce the risk of unauthorized access to ePHI.  For example, authenticating users that access a regulated entity’s systems remotely (e.g., working from home) may present a higher level of risk to a regulated entity’s ePHI than users logging into their desktop computer at work.  To appropriately reduce the higher level of risk of remote access, a regulated entity may consider implementing stronger authentication solutions, such as multi-factor authentication.

    Implementing access controls that restrict access to ePHI to only those requiring such access is also a requirement of the HIPAA Security Rule.  Here, too, the risk analysis should guide the implementation of appropriate access controls.  For example, a regulated entity may determine that because its privileged accounts (e.g., administrator, root) have access that supersedes other access controls (e.g., role- or user-based access) – and thus can access ePHI, the privileged accounts present a higher risk of unauthorized access to ePHI than non-privileged accounts.  Not only could privileged accounts supersede access restrictions, they could also delete ePHI or even alter or delete hardware or software configurations, rendering devices inoperable.  To reduce the risk of unauthorized access to privileged accounts, the regulated entity could decide that a privileged access management (PAM) system is reasonable and appropriate to implement.  A PAM system is a solution to secure, manage, control, and audit access to and use of privileged accounts and/or functions for an organization’s infrastructure.  A PAM solution gives organizations control and insight into how its privileged accounts are used within its environment and thus can help detect and prevent the misuse of privileged accounts.

    Regulated entities should periodically examine the strength and effectiveness of their cybersecurity practices and increase or add security controls to reduce risk as appropriate.  Regulated entities are required to periodically review and modify implemented security measures to ensure such measures continue to protect ePHI.  Further, regulated entities are required to conduct periodic technical and non-technical evaluations of implemented security safeguards in response to environmental or operational changes affecting the security of ePHI to ensure continued protection of ePHI and compliance with the Security Rule.  Examples of environmental or operational changes could include: the implementation of new technology, identification of new threats to ePHI, and organizational changes such as a merger or acquisition.

    Conclusion

    Although malicious attacks targeting the health care sector continue to increase, many of these attacks can be prevented or mitigated by fully implementing the Security Rule’s requirements.  Unfortunately, many regulated entities continue to underappreciate the risks and vulnerabilities of their actions or inaction (e.g., increased risk of remote access, unpatched or unsupported systems, not fully engaging workforce in cyber defense).  The standards and implementation specifications of the HIPAA Security Rule provide a baseline for protecting ePHI.  This document cites only a small sample of Security Rule requirements that can assist organizations in combatting cyber-attacks.  The Security Rule in its entirety provides a foundation for helping regulated entities ensure the confidentiality, integrity, and availability of their ePHI.  

    Reference

    U.S. Department of Health & Human Services

    Office for Civil Rights (OCR)

    Winter 2022 OCR Cybersecurity Newsletter

  • 29 Oct 2021 1:14 PM | Zachary Edgar (Administrator)

    OCR Cybersecurity Newsletter: Securing Your Legacy [System Security]

    October is Cyber Security Awareness Month and a great time for organizations to revisit the protections they have in place for their legacy systems.  Health care organizations rely on many technical systems to deliver their services.  The HIPAA Security Rule1 requires covered entities and their business associates to implement safeguards that reasonably and appropriately secure the electronic protected health information (ePHI) that these organizations create, receive, maintain, or transmit.  As health care entities’ technological footprint grows, the number of systems these organizations need to identify, assess, and maintain grows as well.  Many health care organizations rely on legacy systems, which is a term for an information system with one or more components that have been supplanted by newer technology and for which the manufacturer is no longer offering support.  But despite their common use, the unique security considerations applicable to legacy systems in an organization’s IT environment are often overlooked.

    Ideally, all organizations would only use information systems that are fully patched and up to date. However, in reality, health care organizations must balance competing priorities and obligations.  There are many reasons why a health care organization may elect to keep using a legacy system, such as:  

    • The organization may not be able to replace the legacy system without sacrificing availability of data, disrupting critical services, or compromising data integrity.  For health care providers, this can apply to medical devices, electronic health records, and other systems offering critical services.
    • The organization is reluctant to tinker with technology that appears to be working, or to deploy a new and unfamiliar system that may reduce efficiency or lead to increased user errors.
    • The organization is reluctant to replace a system that is well-tailored to its business model, or with which it has a high degree of competence.
    • The organization’s other systems depend on the legacy system or are incompatible with newer systems.
    • The organization is unable to dedicate the time, funds, or human resources needed to retire and replace the legacy system. 

    While many factors may contribute to an organization’s decision to continue to use a legacy system, it is important that the organization include security in its considerations, especially when the legacy system could be used to access, store, create, maintain, receive, or transmit ePHI.

    Managing the Security Risk of Legacy Systems

    Legacy systems’ lack of vendor support makes them particularly vulnerable to cyberattacks.  The HIPAA Security Rule requires covered entities and their business associates to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI throughout their environment, including ePHI used by legacy systems.  An accurate and up-to-date asset inventory is a useful first step because it can help organizations understand where critical processes, data, and legacy systems reside within their organization.  After assessing the potential risks and vulnerabilities to their ePHI, covered entities and business associates must implement security measures to reduce those risks and vulnerabilities to a reasonable and appropriate level as part of their risk management.  For legacy systems, this means identifying the potential risks and vulnerabilities to ePHI posed by those systems, the security measures the organization will take to reduce those potential risks and vulnerabilities, and the proposed timeline, including (if possible) the legacy system’s ultimate retirement date.

    Organizations often elect one or more of the following strategies to mitigate a legacy system’s security risk:

    • Upgrade to a supported version or system.
    • Contract with the vendor or a third party for extended system support or migrate the system to a supported cloud-based solution.
    • Remove or segregate the legacy system from the internet or from the organization’s network.
    • Maintain the legacy system, but strengthen existing controls or implement compensating controls.

    If an organization elects to maintain a legacy system and strengthen its existing controls, or implement compensating controls, those controls should be tailored to the potential risks and vulnerabilities identified with the legacy system. Such controls may include:

    • Enhancing system activity reviews and audit logging to detect unauthorized activity, with special attention paid to security configurations, authentication events, and access to ePHI.
    • Restricting access to the legacy system to a reduced number of users.
    • Strengthening authentication requirements and access controls.
    • Restricting the legacy system from performing functions or operations that are not strictly necessary (e.g., by removing or disabling unnecessary software and services).
    • Ensuring that the legacy system is backed-up – especially if strengthened or compensating controls impact prior backup solutions.
    • Developing contingency plans that contemplate a higher likelihood of failure, especially if the legacy system is providing a critical service.
    • Implementing aggressive firewall rules.
    • Implementing supported anti-malware solutions.

    In addition to implementing safeguards required by the HIPAA Security Rule, covered entities and business associates are also required to review and modify their security measures to ensure the continued protection of their ePHI.  When a system is nearing legacy status (or is already a legacy system) organizations should assess the specific security risks associated with those systems.  If an organization elects to maintain a legacy system, it should review and modify its security measures to ensure the continued protection of its ePHI.  Finally, organizations should consider when the burdens of maintaining a legacy system will outweigh its benefits and plan for the legacy system’s eventual removal and replacement.

    Reference

    U.S. Department of Health & Human Services

    Office for Civil Rights (OCR)

    Fall 2021 OCR Cybersecurity Newsletter

  • 14 Jul 2021 1:12 PM | Zachary Edgar (Administrator)

    Controlling Access to ePHI: For Whose Eyes Only?

    A recent report of security incidents and data breaches found that 61% of analyzed data breaches in the healthcare sector were perpetrated by external threat actors and 39% by insiders. Without appropriate authorization policies and procedures and access controls, hackers, workforce members, or anyone with an Internet connection may have impermissible access to the health data, including protected health information (PHI), that HIPAA regulated entities hold.  News stories and OCR investigations abound of hackers infiltrating information systems, workforce members impermissibly accessing patients’ health information, and electronic PHI (ePHI) being left on unsecured servers.  

    Information Access Management and Access Control are two HIPAA Security Rule standards that govern access to ePHI.  These standards include several implementation specifications that are either required or addressable.  HIPAA regulated entities must implement required implementation specifications. Addressable implementation specifications require HIPAA regulated entities to assess whether an implementation specification is a reasonable and appropriate safeguard in its environment, and if so to implement it.  If a particular implementation specification is not reasonable and appropriate, entities must document why, and implement equivalent alternative measures if reasonable and appropriate.  

    Information Access Management is an administrative safeguard for ePHI and Access Control is a technical safeguard for ePHI. Although their roles in securing ePHI are distinct, together, they ensure that organizations implement policies and procedures and technical controls that limit access to ePHI to only authorized persons or software programs that have been granted access rights. 

    Information Access Management

    The Information Access Management standard requires HIPAA covered entities and business associates to “implement policies and procedures for authorizing access to [ePHI] that are consistent with the applicable requirements of [the HIPAA Privacy Rule].”  This standard has three implementation specifications, two of which have general applicability to covered entities and business associates (Access Authorization and Access Establishment and Modification) and the other which is specific to health care clearinghouses (Isolating Health Care Clearinghouse Functions). While the Access Authorization and Access Establishment and Modification implementation specifications are similar, the former focuses on the policies for granting access to ePHI, whereas the latter focuses on the procedural aspects about how such access is established, documented, reviewed, and modified.

    Access Authorization concerns the implementation of policies and procedures that govern how covered entities and business associates authorize or grant access to ePHI within their organization. This may include how access to each information system containing ePHI is requested, authorized, and granted, who is responsible for authorizing access requests, and the criteria for granting access.  These policies typically govern the parameters for which individuals in particular workforce roles may be granted access to particular systems, applications, and data. Those parameters would reflect what information access is necessary for a workforce member to do their job.  For example, a billing clerk role may not need access to medical images on a Pictures Archiving and Communication System (PACS) server in order to carry out their billing responsibilities.

    Access Establishment and Modification policies describe how to establish, document, review, and modify a user’s access to workstations, transactions, programs, or processes. For example, a workforce member being promoted or given some change in responsibility may require increased access to certain systems and decreased access to others. Another example is that a covered organization could change its system access requirements to permit remote access to systems containing ePHI during a pandemic. Policies and procedures should cover situations such as these to ensure that each workforce member’s access continues to be appropriate for their role.

    Access Control

    The Access Control standard is a technical safeguard that requires covered entities and business associates to implement access controls for electronic information systems to allow access to ePHI only to those approved in accordance with the organization’s Information Access Management process. The flexible, scalable, and technology-neutral nature of the Security Rule permits organizations to consider various access control mechanisms to prevent unauthorized access to ePHI.  Such access controls could include role-based access, user-based access, attribute-based access, or any other access control mechanisms the organization deems appropriate. Further, access controls need not be limited to computer systems. Firewalls, network segmentation, and network access control (NAC) solutions can also be effective means of limiting access to electronic information systems containing ePHI. Properly implemented, network-based solutions can limit the ability of a hacker to gain access to an organization’s network or impede the ability of a hacker already in the network from accessing other information systems – especially systems containing sensitive data.

    The Access Control standard includes four implementation specifications for limiting access to only authorized users and software programs. The first, Unique User Identification, is a required implementation specification and is a key security requirement for any system, but particularly those containing ePHI. While the use of shared or generic usernames and passwords may seem to provide some short-term convenience, it severely degrades the integrity of a system because it removes accountability from individual users and makes it much easier for the system to become compromised. If information is improperly entered, altered, or deleted, whether intentionally or not, it can be very difficult to identify the person responsible (e.g., for training or sanctions) or determine which users may have been the victim of a phishing attack that introduced ransomware into the organization. Additionally, because shared usernames and passwords can become widely known, it may be difficult to know whether the person responsible was an authorized user. A former employee or contractor, a current employee not authorized for access, a friend or family member of an employee, or an outside hacker could be a source of unauthorized access. The inability to identify and track a user’s identity due to the use of shared user IDs can also impede necessary investigations when the shared user ID is used for unauthorized or even criminal activity. For example, a malicious insider could take advantage of known shared user IDs to hide their activities when collecting personal medical and financial information to use for identity theft. In such as case, an organization’s implemented audit controls would document the actions of the shared user ID, thus potentially limiting the organization’s ability to properly identify and track the malicious insider.

    The second implementation specification, Emergency Access Procedure, is also a required implementation specification. This implementation specification is applicable in situations in which normal procedures for obtaining ePHI may not be available or may be severely limited, such as during power failures or the loss of Internet connectivity. Access controls are still necessary during an emergency, but may be very different from normal operations. For example, due to the recent COVID-19 public health emergency, many organizations quickly implemented mass telework policies. How workforce members can securely access ePHI during periods of increased teleworking should be part of an organization’s Emergency Access Procedures. Appropriate procedures should be established beforehand for how to access needed ePHI during an emergency.

    The third implementation specification, Automatic Logoff, is an addressable implementation specification. Users sometimes inadvertently leave workstations unattended for various reasons.  In an emergency setting, a user may not have time to manually log out of a system.  Implementing a mechanism to automatically terminate an electronic session after a period of inactivity reduces the risk of unauthorized access when a user forgets or is unable to terminate their session.  Failure to implement automatic logoff not only increases the risk of unauthorized access and potential alteration or destruction of ePHI, it also impedes an organization’s ability to properly investigate such unauthorized access because it would appear to originate from an authorized user.

    The final implementation specification is Encryption and Decryption, which is also an addressable implementation specification. This technical safeguard can reduce the risks and costs of unauthorized access to ePHI.  For example, if a hacker gains access to unsecured ePHI on a network server or if a device containing unsecured ePHI is stolen, a breach of PHI will be presumed and reportable under the Breach Notification Rule (unless the presumption can be rebutted in accordance with the breach risk assessment described in 45 C.F.R. § 164.402(2)). The Breach Notification Rule applies to unsecured PHI which is PHI “that is not rendered unusable, unreadable, or indecipherable to unauthorized persons through the use of a technology or methodology specified by the Secretary in the guidance issued under [the HITECH Act].”  OCR’s Guidance to Render Unsecured Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals, which provides guidance for securing PHI, states that ePHI that is “at-rest” (i.e., stored in an information system or electronic media) is considered secured if it is encrypted in a manner consistent with NIST Special Publication 800-111 (Guide to Storage Encryption Technologies for End User Devices) (SP 800-111).

    EPHI encrypted in a manner consistent with SP 800-111 is not considered unsecured PHI and therefore is not subject to the Breach Notification Rule. Encrypting ePHI in this manner is an excellent example of how implementing an effective encryption solution may not only fulfill an organization’s encryption obligation under the Access Control standard, but also provides a means to leverage the Breach Notification Rule’s safe-harbor provision.

    As the use of mobile computing devices (e.g., laptops, smartphones, tablets) becomes more and more pervasive, the risks to sensitive data stored on such devices also increases. Many mobile devices include encryption capabilities to protect sensitive data. Once enabled, a device’s encryption solution can protect stored sensitive data, including ePHI, from unauthorized access in the event the device is lost or stolen.

    Reference

    U.S. Department of Health & Human Services

    Office for Civil Rights (OCR)

    Summer 2021 OCR Cybersecurity Newsletter

  • 25 Aug 2020 1:10 PM | Zachary Edgar (Administrator)

    Making a List and Checking it Twice: HIPAA and IT Asset Inventories

    The HIPAA Security Rule requires covered entities and business associates to ensure the confidentiality, integrity, and availability of all electronic protected health information (ePHI) that it creates, receives, maintains, or transmits. Conducting a risk analysis, which is an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of the ePHI held by an organization, is not only a Security Rule requirement, but also is fundamental to identifying and implementing safeguards that comply with and carry out the Security Rule standards and implementation specifications. However, despite this long-standing HIPAA requirement, OCR investigations frequently find that organizations lack sufficient understanding of where all of the ePHI entrusted to their care is located. Although the Security Rule does not require it, creating and maintaining an up-to-date, information technology (IT)  asset inventory could be a useful tool in assisting in the development of a comprehensive, enterprise-wide risk analysis, to help organizations understand all of the places that ePHI may be stored within their environment, and improve their HIPAA Security Rule compliance.

    Creating an IT Asset Inventory

    Generally, an enterprise-wide IT asset inventory is a comprehensive listing of an organization’s IT assets with corresponding descriptive information, such as data regarding identification of the asset (e.g., vendor, asset type, asset name/number), version of the asset (e.g., application or OS version), and asset assignment (e.g., person accountable for the asset, location of the asset). The HHS Security Risk Assessment Tool includes inventory capabilities that allow for manual entry or bulk loading of asset information with respect to ePHI. Larger, more complex organizations may choose dedicated IT Asset Management (ITAM) solutions that include automated discovery and update processes for asset and inventory management. HIPAA covered entities and business associates using the NIST Cybersecurity Framework (NCF) should be able to leverage the inventory components of the NCF’s Asset Management (ID.AM) category, which includes inventorying hardware (ID.AM-1), inventorying software (ID.AM-2), and mapping communication and data flows (ID.AM-3), to assist in creating and maintaining an IT asset inventory that can be used in and with their Security Rule risk analysis process with respect to ePHI.

    When creating an IT asset inventory, organizations can include:

    • Hardware assets that comprise physical elements, including electronic devices and media, which make up an organization’s networks and systems. This can include mobile devices, servers, peripherals, workstations, removable media, firewalls, and routers.
    • Software assets that are programs and applications that run on an organization’s electronic devices. Well-known software assets include anti-malware tools, operating systems, databases, email, administrative and financial records systems, and electronic medical/health record systems. Though lesser known, there are other programs important to IT operations and security such as backup solutions, virtual machine managers/hypervisors, and other administrative tools that should be included in an organization’s inventory.
    • Data assets that include ePHI that an organization creates, receives, maintains, or transmits on its network, electronic devices, and media. How ePHI is used and flows through an organization is important to consider as an organization conducts its risk analysis.

    How an IT Asset Inventory Can Help Improve an Organization’s Risk Analysis

    HIPAA covered entities and business associates are required to conduct an accurate and thorough assessment of the risks to the ePHI it maintains. Identifying, assessing, and managing risk can be difficult, especially in organizations that have a large, complex technology footprint. Understanding one’s environment – particularly how ePHI is created and enters an organization, how ePHI flows through an organization, and how ePHI leaves an organization – is crucial to understanding the risks ePHI is exposed to throughout one’s organization.

    When creating or maintaining an IT asset inventory that can aid in identifying risks to ePHI, it may be beneficial to consider other IT assets that may not store or process ePHI.  An entity’s risk analysis obligation is to “conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentially, integrity, and availability of ePHI held by the covered entity or business associate.” Assets within an organization that do not directly store or process ePHI may still present a method for intrusion into the IT system, that could lead to risks to the confidentiality, integrity, and availability of an organization’s ePHI. For example, consider an Internet of Things (IoT) or a smart, connected device that provides access to facilities for maintenance personnel for control and monitoring of an organization’s heating, ventilation, and air conditioning (HVAC). Although it does not store or process ePHI, such a device can present serious risks to sensitive patient data in an organization’s network. Unpatched IoT devices with known vulnerabilities, such as weak or unchanged default passwords installed in a network without firewalls, network segmentation, or other techniques to deny or impede an intruder’s lateral movement, can provide an intruder with a foothold into an organization’s IT network. The intruder may then leverage this foothold to conduct reconnaissance and further penetrate an organization’s network and potentially compromise ePHI.

    Real world examples of IoT devices used for malicious activities include incidents reported by Microsoft in which malicious actors were able to compromise a VOIP phone, printer, and video decoder to gain access to corporate networks. The hackers were able to exploit unchanged default passwords and unpatched security vulnerabilities to compromise these devices. Once inside the network, the hackers were able to conduct reconnaissance and access other devices on the corporate network in search of additional privileges and high-value data.

    An IT asset inventory that includes IoT devices can strengthen an organization’s risk analysis by raising awareness of the potential risks such devices may pose to ePHI. The lack of an inventory, or an inventory lacking sufficient information, can lead to gaps in an organization’s recognition and mitigation of risks to the organization’s ePHI.  Having a complete understanding of one’s environment is key to minimizing these gaps and may help ensure that a risk analysis is accurate and thorough, as required by the Security Rule.

    Ongoing Process and Benefits

    An IT asset inventory can aid in an organization’s overall cybersecurity posture and HIPAA compliance in other ways, too. For example, HIPAA covered entities and business associates must “implement policies and procedures that govern the receipt and removal of hardware and electronic media that contain [ePHI] into and out of a facility, and the movement of these items within the facility.” This includes servers, workstations, mobile devices, laptops, and any other hardware or media that contains ePHI. Receipt, removal, and movements of such devices can be tracked as part of an organization’s inventory process. This has become more important as organizations’ networks and enterprises grow increasingly large and complex – especially, considering the proliferation and use of mobile devices and removable media by the workforce. If reasonable and appropriate, organizations also may consider adding location and owner or assignment information to an IT asset inventory to assist in an organization’s ability to “maintain a record of the movements of hardware and electronic media and any person responsible”.

    Further, by comparing its inventory of known IT assets against the results of network scanning discovery and mapping processes, an organization can identify unknown or “rogue” devices or applications operating on its network. Once identified, these previously unknown devices can be added to the inventory and the risks they may pose to ePHI identified, assessed, and mitigated. An inventory can also be integral to an organization’s vulnerability management program. New software bugs and vulnerabilities are identified on a regular basis. Subsequently, software updates and patches are regularly issued to fix these bugs and mitigate these vulnerabilities. An enterprise-wide IT asset inventory can help an organization identify and track affected devices to facilitate and verify timely application of updates and patches.

    Reference

    U.S. Department of Health & Human Services

    Office for Civil Rights (OCR)

    Summer 2020 OCR Cybersecurity Newsletter

  • 2 Dec 2019 12:40 PM | Zachary Edgar (Administrator)

    Update on Preventing, Mitigating and Responding to Ransomware

    Ransomware is a type of malicious software (or malware) that attempts to deny access to a user’s data, usually by encrypting the data with a key known only to the attacker who deployed the ransomware.  In order for a victim to obtain this key, a ransom payment, which is usually made in cryptocurrency, is required. These types of attacks pose a serious threat to HIPAA covered entities, business associates, and the electronic protected health information (ePHI) that they hold.

    This newsletter will supplement the materials OCR has previously published on how the HIPAA Security Rule can help prevent, mitigate and recover from ransomware attacks by providing insight into new developments and trends that have been observed regarding ransomware attacks and how organizations can improve their security posture in response to this threat. 

    Evolution of Ransomware Attacks

    Prior to 2018, most ransomware attacks involved mass, indiscriminate infection of as many devices and across as many systems as possible.  These infections often spread automatically through dedicated connections between networks and spam phishing emails.  These attacks led to worldwide events caused by ransomware variants of Petya, WannaCry, CryptoLocker, and others.  The May 2017 WannaCry attack alone was estimated to have affected over 200,000 computer systems in over 150 countries with monetary damages estimated into the hundreds of millions to billions of dollars. This attack was reported to have caused the United Kingdom’s National Health Services to cancel thousands of medical appointments and divert patients to alternate facilities. The wide net cast by these ransomware attacks affected individuals and organizations of all sizes, including many covered entities and business associates.

    The FBI estimates that ransomware infects more than 100,000 computers a day around the world and ransom payments approach $1 billion annually; unfortunately, these numbers are only expected to rise in the future.  Ransom payments, however, do not account for all of the costs associated with a ransomware attack.  Unrecoverable data, lost productivity, damage to reputation, damaged equipment, forensic investigations, remediation expenses, and legal bills are some of the additional costs that can be expected when responding to a ransomware attack.  The actual cost of a ransomware attack may be several times more than just the ransom paid.  In 2017, the U.S. Department of Justice called the use of ransomware a global phenomenon and a new business model for cybercrime.

    In response to this new cyberthreat, organizations and governments began adapting.  Anti-malware vendors updated their products to help customers identify, prevent, and contain infections.  Cybersecurity researchers and scientists studied ransomware code and, in some cases, were able to reverse engineer decryption keys to help ransomware victims recover data without paying the ransom. Organizations prioritized incident response and data backups in order to mitigate the damage caused by ransomware attacks.  However, as organizations adapted, ransomware developers evolved.

    In 2017 and 2018, a new threat rapidly emerged:  the targeted ransomware attack. A targeted ransomware attack is loosely defined as a ransomware attack that is adapted to a specific organization or industry. In such incidents, ransomware can be customized and deployed based on the size and sophistication of a potential victim, the sensitivity of data, and the malware code can be adjusted to be more effective in certain situations, for example, by exploiting specific vulnerabilities present in targeted systems.  The ransom demands for this type of attack are often set according to the victim’s perceived ability to pay.  Cybercriminals soon found that customizing their attacks to specific, “quality” targets led to an increase in the amount of ransom payments.  Organizations commonly targeted by this type of attack have sensitive data, high data availability requirements, low tolerance for system downtime, and the resources to pay a ransom.  Many healthcare organizations fit this profile, and have become targets.

    The targeted attack’s tailored approach is what makes it so effective and dangerous and is what sets it apart from the previous type of mass-produced ransomware attack.  Prior to initiating an attack, a malicious actor usually gains unauthorized access to a victim’s information system for the purpose of performing reconnaissance to identify critical services, find sensitive data, and locate backups.  After this is done, the ransomware is deployed in a manner that produces maximum effect, infecting as many devices and as much data as possible and encrypting backup files so that recovery is difficult, if not impossible.  In such a case, an unprepared victim may be forced to make an unpleasant choice: refuse to pay the ransom and lose all of the affected data or pay and hope it can make a full recovery (assuming the attacker provides the decryption keys necessary to decrypt the affected data after receiving payment).

    Prevention, Mitigation, and Recovery

    Although threat actors have employed new means for identifying victims, their overall methods of gaining unauthorized access to systems and deploying ransomware remain generally the same.  Phishing emails and vulnerability exploitation (e.g., exploiting unpatched operating system or application vulnerabilities) continue to be the most common attack vectors.

    Entities should be mindful that ransomware attacks often occur after prior instances of unauthorized access and malware infection.  A threat actor sometimes needs to have access and privileges on a victim’s information system in order to initiate the infection.  Further, certain types of ransomware have been observed to “piggyback” into a system, using other malware as a tool for deployment.  Proper implementation of several HIPAA Security Rule provisions can help covered entities and business associates prevent, mitigate, and recover from ransomware attacks, including:

    Risk Analysis (45 C.F.R. §164.308(a)(1)(ii)(A)) and Risk Management (45 C.F.R. §164.308(a)(1)(ii)(B)). Covered entities and business associates are required to conduct a thorough and accurate assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of their ePHI, and implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.  Identifying and addressing technical vulnerabilities within information systems and information technology infrastructure is crucial to preventing ransomware attacks.  Successful ransomware deployment often depends on exploitation of technical vulnerabilities such as outdated software, unsecured ports, and poor access management/provisioning.  Implementing effective security tools including anti-malware software and intrusion detection/prevention solutions can also help prevent, detect, and contain attacks.  Identifying and reducing these potential risks and vulnerabilities is key to making an organization a less inviting target.

    Information System Activity Review (45 C.F.R. §164.308(a)(1)(ii)(D)). If ransomware is able to overcome an organization’s first level of defenses and enter the organization’s network and information systems, effective system monitoring and review will be critical to detecting and containing the attack.  Identifying anomalous activity, especially such activity executed with elevated privileges, can be crucial to identifying an attack in progress.  Covered entities and business associates are required to regularly review records of information system activity.  Such records can include audit logs, access reports, and security incident tracking reports.  Some organizations may benefit from tools to assist with log collection and review processes.  Security Information and Event Management solutions can assist an organization with its activity review process by aggregating and helping to analyze logs and reports from many different information systems.

    Security Awareness and Training (45 C.F.R. §164.308(a)(5)). Information system users remain one of the weakest links in an organization’s security posture.  Social engineering, including phishing attacks, is one of the most successful techniques used by threat actors to compromise system security.  A training program should make users aware of the potential threats they face and inform them on how to properly respond to them.  This is especially true for phishing emails that solicit login credentials.  Additionally, user training on how to report potential security incidents can greatly assist in an organization’s response process by expediting escalation and notification to proper individuals. 

    Security Incident Procedures (45 C.F.R. §164.308(a)(6)). An organization’s incident response procedures can greatly limit the damage caused by a ransomware attack.  Organizations may consider addressing ransomware attacks specifically within its response policies and procedures as mitigation actions may vary between different types of incidents.  Quick isolation and removal of infected devices from the network and deployment of anti-malware tools can help to stop the spread of ransomware and to reduce the harmful effects of such ransomware.  Response procedures should be written with sufficient details and be disseminated to proper workforce members so that they can be implemented and executed effectively.  Further, organizations may consider testing their security incident procedures from time to time to ensure they remain effective.  Familiarity with the execution of security incident procedures should reduce an organization’s reaction time and increase its effectiveness when responding to an actual security incident or breach.  Identifying and responding to suspected security incidents is key to mitigating potential harm following an intrusion.

    Contingency Plan (45 C.F.R. §164.308(a)(7)). An effective and robust contingency plan is essential to recover from a ransomware attack.  Proper implementation of this provision will allow an organization to continue to operate critical services during an emergency and recover ePHI.  Because patient health and safety may be impacted, tolerance of system downtime is low and ePHI availability requirements are high.  A covered entity or business associate must backup ePHI and ensure that it is accessible and recoverable in the event of a ransomware attack.  Organizations should keep in mind that threat actors have recently been actively targeting backup systems and backup data to prevent recovery.  Maintaining recoverable, secure, and up-to-date backups is one of the most important safeguards against ransomware attacks.

    The foregoing measures (and associated Security Rule provisions) are not an exhaustive list of measures to prevent and recover from a ransomware attack. Covered entities and business associates may also want to consider these additional Security Rule provisions:

    • Implementing effective access controls (see 45 C.F.R. § 164.312(a)(1) (access control)) to stop or impede an attacker’s movements and access to sensitive data; e.g., by segmenting networks to limit unauthorized access and communications.  Further, because attacks frequently seek elevated privileges (e.g., administrator access), entities may consider solutions that limit the scope of administrator access, as well as solutions requiring stronger authentication mechanisms when granting elevated privileges or access to administrator accounts.
    • Ensuring that security measures remain effective as technology changes and new threats and vulnerabilities are discovered (see 45 C.F.R. § 164.306(e) (maintenance)); e.g., by updating or patching software and devices to mitigate known vulnerabilities.

    The emergence of targeted attacks shows that threat actors are adapting to steps taken by organizations to combat the risk of ransomware infections.  So far, these adaptations have proved to be successful, which suggests that ransomware attacks will continue to remain a serious threat to covered entities, business associates, and ePHI for the foreseeable future.  However, advances in malware detection and containment tools can assist entities in identifying intrusions into their IT system and initiating defenses before their data is encrypted.  Further, the implementation of the robust security measures required by HIPAA can prevent or greatly reduce the impact of ransomware attacks.

    Should an Entity Pay the Ransom?

    The FBI does not recommend paying the ransom demanded by the initiator of the ransomware attack, as payment does not guarantee that an entity’s data will be returned, and payment could provide encouragement for further ransomware attacks.  The FBI has noted that there have been instances where the decryption key was not provided after the ransom was paid, or the data was corrupted when it was returned.  The FBI recommends always reporting ransomware incidents to law enforcement, to prevent future attacks and to enable a criminal investigation to be initiated.

    Reference

    U.S. Department of Health & Human Services

    Office for Civil Rights (OCR)

    Fall 2019 OCR Cybersecurity Newsletter
  • 29 Aug 2019 12:54 PM | Zachary Edgar (Administrator)

    Managing Malicious Insider Threats

    Individuals throughout an organization have the ability to expose their organization to a wide range of security threats simply because they are considered trustworthy or have access to sensitive data like health information. These individuals can be customer service representatives, IT staff, managers, and senior executives. Malicious insiders can succeed in harming an organization by intentionally leaking or destroying sensitive information. Examples of insider misuse of health information include accessing the medical records of celebrities for financial gain and using patient information to commit fraud and identify theft. The exfiltration of sensitive information stored within an organization's IT systems can be accomplished by malicious insiders in several ways such as transmitting information in encrypted messages, copying information to a mobile or storage device (e.g., cell phone, USB drive), or unauthorized physical removal or theft of equipment. Transmitted or copied data could be further hidden using subtle means such as by embedding data within other data to hide it (i.e., steganography).

    The harm can take various forms, including loss of data, damage to the organization's reputation, civil liability exposure, and potential federal and state regulatory enforcement actions. In addition to organizational harm, individuals affected by a data breach could be at risk for identity theft, fraud, or even blackmail.

    The 2019 edition of Verizon's Data Breach Investigations Report (DBIR)3 found that trusted insiders were responsible for 59% of all security incidents and breaches (both malicious and inadvertent) analyzed in the report. The report also indicated that the primary motivation for incidents and breaches perpetrated by insiders was financial gain. In 2017, the HHS Office for Civil Rights (OCR) reached a resolution agreement to settle potential HIPAA violations with an entity whose employees' inappropriate access of health information "led to federal charges relating to selling protected health information (PHI) and filing fraudulent tax returns."

    Detecting and preventing data leakage initiated by malicious authorized users is a significant challenge facing security professionals today. Identifying potential malicious activity as soon as possible is key to preventing or mitigating the impact of such activity. To identify potential suspicious activity, organizations should consider an insider's interactions with information systems, including:

    The where, who, what, and how of safeguarding critical data.

    An organization should understand where its data is located, the format in which it resides, and where its data flows throughout its enterprise. This knowledge is crucial to conducting an accurate and thorough assessment of the risks to the confidentiality, integrity, and availability of an organization's critical data. Once these risks are understood, policies and procedures can be developed or updated and security measures implemented to reduce these risks to a reasonable and appropriate level.

    An organization should establish who is permitted to interact with its data and what data those users are permitted to access in determining appropriate access controls. Access controls can take many forms. For example, physical access controls as simple as doors that need keys for opening can limit an unauthorized person's ability to enter sensitive facilities or locations; network access controls can limit access to networks or specific devices on a network; role based access controls can limit access to certain devices, applications, administrator accounts, or data stores to only a defined group of users. Organizations should leverage their risk analysis when establishing and implementing access controls.

    Another important consideration is how an organization's users will interact with data. Do the duties of the user's job require the capability to write, download or modify data or is read-only access sufficient? Do users need to access data from laptops, smart phones, or mobile storage devices (such as thumb drives)? Such devices are more difficult to safeguard and control, especially if they are "personal" devices owned by the user. An organization should consider limiting unnecessary mobile device use and implementing security controls to prevent copying sensitive data to unauthorized external devices. If users are given access to mobile or storage devices, the organization must implement appropriate security controls to safeguard the data when using such devices.

    Real-time visibility and situational awareness

    The migration to cloud computing, increased use of mobile devices, and the adoption of Internet of Things (IoT) technology can greatly reduce an organization's ability to detect anomalous user behavior or indicators of misuse by either a trusted employee or third party vendor who has access to critical systems and data. To minimize this risk, an organization may employ safeguards that detect suspicious user activities, such as traffic to an unauthorized website or downloading data to an external device (e.g., thumb drive). Maintaining audit controls (e.g., system event logs, application audit logs) and regularly reviewing audit logs, access reports, and security incident tracking reports are important security measures, required by the Security Rule, that can assist in detecting and identifying suspicious activity or unusual patterns of data access.

    Security is a Dynamic Process

    Good security practices entail continuous awareness, assessment, and action in the face of changing circumstances. The information users can and should be allowed to access may change over time; organizations should recognize this in their policies and procedures and in their implementation of those policies and procedures. For example, if a user is promoted, demoted, or transfers to a different department, a user's need to access data may change. In such situations, the user's data access privileges should be re-evaluated and modified to match the new role, if needed. Organizations should be particularly sensitive to the risk of insider threats in cases of involuntary separation. Organizations should have policies and procedures in place to terminate physical and electronic access to data, before any user leaves the organization's employ. Such actions should include disabling all of the user's computer and application accounts (including access to remote and administrative accounts if applicable), changing or disabling facility access codes known to the user, and retrieving organization property including keys, mobile devices, electronic media, and other records, etc.

    The healthcare sector is a tempting target for malicious insiders who seek to disclose or steal an organization's sensitive information. However, by recognizing the risks and implementing appropriate safeguards, organizations can manage this risk and comply with the law.

    Reference

    U.S. Department of Health & Human Services

    Office for Civil Rights (OCR)

    Summer 2019 OCR Cybersecurity Newsletter
  • 9 Apr 2019 12:49 PM | Zachary Edgar (Administrator)

    Advanced Persistent Threats and Zero Day Vulnerabilities

    An advanced persistent threat (APT) is a long-term cybersecurity attack that continuously attempts to find and exploit vulnerabilities in a target’s information systems to steal information or disrupt the target’s operations.   Although individual APT attacks need not be technologically sophisticated, the persistent nature of the attack, as well as the attacker’s ability to change tactics to avoid detection, make APTs a formidable threat.

    APTs are a serious threat to any information technology (IT) system, but especially those that are part of the health care field.  Healthcare services are part of a multibillion dollar industry that utilizes data to develop new drugs and treatments.  Medical research information, experimental treatment testing results, and even genetic data are valuable targets for theft because of their value in driving innovation.  Further, health information is used by healthcare providers and insurers to provide and pay for healthcare services for individuals.  If compromised, health information can be used for identify theft that could lead to financial fraud including theft of health insurance coverage benefits.  Also, because an individual’s health information can contain details concerning the most private and personal aspects of one’s life, the compromise of one’s health information could also lead to an ability to blackmail an individual based on their sensitive health information. Any security incident impacting the confidentiality, integrity, or availability of protected health information (PHI), can directly affect the health and safety of citizens.  APTs have already been implicated in several cyberattacks on the healthcare sector in the U.S. and around the world. 

    Zero Day Exploits

    One of the most dangerous tools in a hacker’s arsenal is the “zero day” exploit or attack which takes advantage of a previously unknown hardware, firmware, or software vulnerability.  Hackers may discover zero day exploits by their own research or probing or may take advantage of the lag between when an exploit is discovered and when a relevant patch or anti-virus update is made available to the public.

    These exploits are especially dangerous because their novel nature makes them more difficult to detect and contain than standard hacking attacks.  The possibility of such an attack emphasizes the importance of an organization’s overall security management process which includes monitoring of anti-virus or cybersecurity software for detection of suspicious files or activity.  Though hackers may exploit zero day vulnerabilities to gain unauthorized access to an organization’s computer system, appropriate safeguards, including encryption and access controls, may mitigate or even prevent unauthorized access to, or loss of, protected information.  Once zero day vulnerabilities are made public, this information becomes accessible to both good and bad actors alike which means entities should have measures in place to be aware of new patches and for assessing the need to apply them.  In the event a timely patch is not available, or cannot be immediately implemented (such as when testing is needed to ensure that the patch works with components of an entity’s information systems), an entity  may consider adopting other protective measures such as additional access controls or network access limitations to mitigate the impact of the zero day vulnerability until a patch is available.

    A Dangerous Combination

    APTs and zero day threats are dangerous enough by themselves. An APT using a zero day exploit can threaten computers and data all over the world. One such example is the EternalBlue exploit.  EternalBlue targeted vulnerabilities in several of Microsoft’s Windows operating systems. Soon after the EternalBlue exploit became publically known, the WannaCry ransomware was released and began spreading, eventually infecting hundreds of thousands of computers around the world. The damages due to WannaCry infections are estimated to be in the billions of dollars. Analysis of WannaCry found that it used EternalBlue to spread and infect other systems. One of the organizations most impacted was the United Kingdom’s National Health Service (NHS) which had up to 70,000 devices infected, forcing healthcare providers to turn away patients and shut down certain services. Several HIPAA covered entities and business associates in the United States were also affected by this cyberattack.

    What Can HIPAA Covered Entities and Business Associates Do?

    There are many security measures that organizations can proactively implement to help mitigate or prevent the damage that an APT or zero day attack may cause. The HIPAA Security Rule requires security measures that can be helpful in preventing, detecting and responding to cyberattacks such as those perpetrated by APTs or hackers leveraging zero day exploits.

    The HIPAA Security Rule includes the following security measures that can reduce the impact of an APT or zero day attack:

    • Conducting risk analyses to identify  risks and vulnerabilities (See 45 CFR § 164.308(a)(1)(ii)(A));
    • Implementing a risk management process to mitigate identified risks and vulnerabilities (See 45 CFR § 164.308(a)(1)(ii)(B));
    • Regularly reviewing audit and system activity logs to identify abnormal or suspicious activity (See 45 CFR § 164.308(a)(1)(ii)(D));
    • Implementing procedures to identify and respond to security incidents (See 45 CFR § 164.308(a)(6));
    • Establishing and periodically testing contingency plans including data backup and disaster recovery plans to ensure data is backed up and recoverable (See 45 CFR § 164.308(a)(7));
    • Implementing access controls to limit access to ePHI (See 45 CFR § 164.312(a));
    • Encrypting ePHI, as appropriate, for data-at-rest and data-in-motion (See 45 CFR §§ 164.312(a)(2)(iv), (e)(2)(ii)); and
    • Implementing a security awareness and training program, including periodic security reminders and education and awareness of implemented procedures concerning malicious software protection, for all workforce members (See 45 CFR § 164.308(a)(5)).

    Reference

    U.S. Department of Health & Human Services

    Office for Civil Rights (OCR)

    Spring 2019 OCR Cybersecurity Newsletter

About Us

Therapy Comply is a healthcare compliance firm that seeks to bring high quality web-based compliance guidance and one-on-one consulting services to small and medium size physical, occupational, and speech therapy practices.

Learn More 

Join Us

Join today as either a monthly or a yearly member and enjoy full access to the site and a significant discount to our live and recorded webinars.  Members also have access to compliance and billing support.

Join Today 

Find Us


Powered by Wild Apricot Membership Software