One month after one of the largest cyber-attacks and exposure of electronic Personal Health Information (ePHI) in 2022, Senator Mark Warner of Virginia released a paper detailing researched cybersecurity issues across the health industry and proposed policy options to mitigate them. The paper, entitled Cybersecurity is Patient Security, covers several gaps in current public and private sector efforts and goes as far to pose the question: what incentives or penalties should be enacted for compliance or non-compliance with federal regulations? A similar cybersecurity assessment and penalization policy to what Senator Warner is alluding to is slated to go in effect in 2023 for organizations providing goods and services to the Department of Defense (DoD). Driven by the success of this rollout, it is fathomable that the U.S. Department of Health and Human Services will seek to protect patient data with similar rigor.
We can peer somewhat into the future of the Health Insurance Portability and Accountability Act (HIPAA) and overall healthcare data security policy by following the trend in heightened attacks against healthcare providers and proposals for new Federal policy, but there are also key signs for healthcare providers and Electronic Health Records (EHR) system vendors when reviewing the possible changes to National Institute of Standards and Technology (NIST) Special Publication 800-66 (NIST 800-66).
NIST 800-66r2 Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide, is “designed to help the industry maintain the confidentiality, integrity and availability of electronic protected health information, or ePHI.”1 There are two subjects emphasized and woven throughout the newly published NIST 800-66r2 Draft. The first is risk analysis and management, and the second is access management. Interestingly, an entire risk management section is injected into the document, and both topics have more net new content than others throughout the draft. It is for this reason I’d like to highlight some of the new guidance, implications for these additions, and potential capabilities within Microsoft 365 and Azure that can address it.
Access Control within HIPAA
Before diving into NIST 800-66, the implementation guidance for HIPAA compliance, it is important to make a pitstop in the HIPAA Security Rule itself. Many of the “implication specifications” found in HIPAA documentation can overlap, and it would be dramatic to state one specification is more foundational or important than any other. Yet I’d like to center this blog about access on a single specification, though others may be evoked.
164.308 Administrative safeguards. a.1.ii.D Information system activity review (Required). Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.
Review of records can look different organization by organization, system by system within an organization, and activity by activity within a system. Yet, there is a clear distinction that can be made about the types of activities which expose or could expose ePHI, and it is incumbent upon the healthcare provider to limit those and monitor them. Reevaluating HIPAA compliance is vital at this moment as the industry has moved to various virtual forms of care and customer service, and healthcare organizations are in the progress of migrating legacy EHR systems to cloud infrastructure. These trends are not new or novel; however, the access management considerations are.
In Senator Warner’s previously mentioned paper, he cites a “need to access information and deliver care quickly” and the need “has to be balanced with and often conflicts with the need for ideal cybersecurity protection.”2 Often access control and management are areas where IT and cybersecurity management teams, alike, are challenged with discerning HIPAA in a way that addresses the requirements but does not hinder staff efficiencies. As a result, these leaders and their teams need greater visibility into activities across a healthcare provider’s EHR system and applications in the cloud, email, chat communications, and various endpoints to understand potential risk and user behavior.
Some organizations are looking to stream the various events and threat signals coming from these sources into a consolidated view within their Security Information and Event Management (SIEM) solution, such as Microsoft Sentinel. Healthcare providers for decades have operated and based most business decisions upon a wealth of data analysis, but cybersecurity analysis has yet to reach a similar level of maturation. Integrating audit logs from many of the leading EHR systems into Sentinel can aid in reviewing risky activities.
Risky Activity Scenarios for Sentinel Workbooks:
By no means is this list exhaustive, but these are the types of activities that are intended to be reviewed in alignment with the HIPAA specialization 164.308 Administrative safeguards. a.1.ii.D.
There are also “Technical safeguards” addressing how the healthcare organization should “allow access only to those persons or software programs that have been granted access rights”.3 Many of the changes to NIST 800-66 in the latest draft take into account the proactive technical safeguards and the reactive access activity review processes required for ePHI. Let’s now discuss the changes to NIST 800-66 and how activity review drives the future of HIPAA compliance and access control.
Changes from NIST 800-66r1 to NIST 800-66r2: Access Control and Information Access Management
NIST is the agency responsible for multiple cybersecurity publications aimed at guiding various industries in protecting sensitive information. Since the initial publishing of NIST 800-66r1 in 2008, NIST went through a thorough research process to identify gaps relating to modern attack vectors, consider new security technologies and best practices, review over 400 comments from industry during pre-draft review, and conduct mapping exercises to the more recently revised NIST 800-53 and NIST Cybersecurity Framework (CSF). The resulting draft NIST 800-66r2 contains additions and modifications reflective of this research process. Below are four brand new additions to NIST 800-66 sections 5.1.4 Information Access Management and 5.3.1 Access Control, and possible takeaways.
Addition 1: “Decide and document how access to ePHI will be granted for privileged functions.”
Privileged functions in this case can be tied to security functions, as defined by NIST 800-53. Security functions can include but are not limited to establishing system accounts, configuring access authorizations (i.e., permissions, privileges), configuring settings for intrusion detection and events to be audited, establishing key management, and managing access control lists. Considering ePHI can traverse information systems and originate from multiple systems as well, the functions within each system are in the scope of this new key activity description. For example, privileged functions are managed and controlled differently for Microsoft 365, Azure, EHR systems hosted on premises or in Azure, other third-party applications, and so on.
One of the more powerful tools to grant access to privileged functions within multi-cloud environments, where you may be hosting your EHR system, is Microsoft Entra Permissions Management (EPM). EPM allows healthcare organizations to provide complete visibility into every action of every identity on any resource (compute, memory, and storage) in their multi-cloud estate. Additionally, EPM provides just-in-time access to privileged functions in an on-demand fashion. Similarly Privileged Identity Management (PIM) within Azure Active Directory (AAD) can also require approvals to activate privileged functions, prompt the user for justification when requesting a particular function, and notify another individual in the organization when just-in-time access is activated. Moreover, this momentary access can be templatized in a manner that is automated and documented for NIST 800-66 compliance when using EPM and/or PIM.
Other technologies to consider within scope of this key activity are Microsoft Defender for Cloud (MDC) solutions, such as Microsoft Defender for SQL. MDC can produce vulnerability assessments that include suggestions related to baseline permission configurations, especially privileged server-level functions. Organizations use this information to document and decide where adjustments need to be made, as well as identify where misconfiguration for new resources is taking place.
Addition 2: “Consider whether multiple access control methods are needed to protect ePHI according to results of the risk assessment.”
Methods in this case are defined as “identity-based, role-based, location-based, or a combination” according to the draft of NIST 800-66r2. AAD Conditional Access policies can achieve this diversity in methods and go beyond to include device type (manufacturer, personal vs corporate-owned, OS, etc) and risk level of the user and each sign-in attempt. User-risk and sign in-risk are dynamically assigned (Low, Medium, High) based upon analysis of hundreds of signals in real-time and calculations. Below is a graphical representation of these various access control methods to protect ePHI on the far right of the image.
As with many of the new NIST 800-66r2 descriptions, a “risk assessment” is vital to determining which methods or combinations are appropriate for each user, groups of users, and systems. Fortunately, Conditional Access policies can be created through Microsoft Graph API and be tested first in report-only mode to discern the user impact. Microsoft’s Identity Protection capabilities as a part of AAD P2 to review and assess risky users, sign-in attempts, and other risk detections of multiple types:
This information can also be streamed to Sentinel for comprehensive risk assessment beyond access and identity risk detections.
Addition 3: “Modify personnel access to ePHI, as needed, based on review activities.”
Thankfully for Azure and multi-cloud deployments, we now have Microsoft Entra Permissions Management mentioned previously to understand what users are over permissioned based on usage analytics and can remove the unused or excessive permissions across each cloud instance within the same portal. Review activities can be conducted at an enterprise perspective or more granularly at a user or resource level to see what tasks were performed within a given time period. Additionally, alerts can be created based upon certain activities to inform administrators of potential need to modify access.
ePHI also can land in Microsoft 365 via Teams, OneDrive, SharePoint, or a managed Windows device. Personnel access to ePHI can be far different than a resource in Azure due to the varied information shared on Teams and other workloads. For example, not all emails contain ePHI, but some might. A wholistic ePHI access solution in Microsoft 365 will first start with properly configured identities and Multifactor Authentication (MFA) in Azure Active Directory (AAD), but the actual labeling and governance of ePHI access will be created and modified in Microsoft Purview.
A Sensitivity Label can be created within Microsoft Purview to be applied to files containing ePHI across Microsoft 365 workloads. Once that label is applied, the file can be encrypted to control who accesses the ePHI within the organization.
After the healthcare organization turns on Azure Rights Management and begins labeling ePHI throughout the organization, various reporting can be reviewed to discover what users are applying labels, removing labels, and accessing or sharing labeled files. Through this reporting, administrators can determine what users need to be removed or added to a label policy, as well as monitor where users are possibly oversharing with inappropriate parties internal or external to the organization.
Addition 4: “Consider implementing a user recertification process to ensure that least privilege is enforced.”
Recertification can be interpreted somewhat differently or include multiple measures to enact depending upon system type, users and activities, and policy. For non-privileged accounts accessing standard business applications, such as email/messaging and an EHR system, a rolling monthly review of access may be sufficient. Administrators and others with privileged access accounts may need automated and continuous review to inform their access. Another group to mention is terminated employees, which are treated differently than active users in scope of recertification.
Healthcare organizations should also explore with their respective EHR vendor how they may ingest audit logs from the EHR system appropriately into a SIEM, such as Sentinel, and/or integrate with AAD to gain greater visibility into access and usage within the EHR. In addition, Permissions within the Microsoft Purview portal should be assessed on a regular basis to view permissions to Information Protection solutions and others. For example, it may be important to review what admins or users in Microsoft 365 can edit or delete policies related to ePHI labeling, encryption, and data loss prevention.
If a HIPAA violation occurs in the woods and no one is around, does it make a sound?
The age-old philosophical question has an answer. Yes. The message to industry, based upon the latest changes to NIST 800-66, is emphasizing the need to gain greater visibility (or listening) into the ePHI access activities across the organization, and develop appropriate access management solutions to address the present risks. Currently a virtual healthcare service can be provided by a doctor or clinician in the literal woods (barring an adequate internet connection) who is accessing applications hosted outside of the physical location of the healthcare organization (i.e. hosted in cloud infrastructure). This scenario among many others can generate a fair amount of access information that teams can review, analyze, and act upon if necessary.
Yet well-known hurdles exist with staffing cybersecurity and compliance/privacy professionals to review the risk alerts or conduct risk assessments. Therefore, it will likely be imperative for many healthcare providers and institutions handling ePHI to adopt technical solutions that integrate all threat signals into a single pane of glass via SIEM integration and automate the review process. In the next installment of this blog, we will continue the conversation around risk review and response while exploring some of the changes impacting incident response and data integrity within NIST 800-66.
BONUS Content: This podcast does an interesting and humorous review of the NIST 800-66r2 update.
Resources and References
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.