Cybersecurity Practice #3: Identity and Access Management (medium/large)

Identity and access management (IAM) is a program that encompasses the processes, people, technologies, and practices relating to granting, revoking, and managing user access. Given the complexities associated with health care environments, IAM models are critical for limiting the security vulnerabilities that can expose organizations. A common phrase used to describe these programs is “enabling the right individuals to access the right resources at the right time.”

Most access authentication methods rely on usernames and passwords, a model proven by the success of phishing and hacking attacks to be weak. Establishing IAM controls requires a distinct and dedicated program to accommodate its high level of complexity and numerous points of integration. You can find a toolkit for establishing an IAM program on the EDUCAUSE website.¹⁴

This section will focus on the critical elements of an IAM program required to manage threats relevant to the HPH sector.

Sub-Practices for Medium-Sized Organizations

As defined in NIST Special Publication 800-63-3, “Digital identity is the unique representation of a subject engaged in an online transaction.”¹⁵ A common principle to follow is “One person, one identity, multiple contexts/” In health care, a person can have the context of a patient, payor, or even employee of the health system. For clinical staff, one person can have one identity, but that person’s ability to practice specialties will depend on context, including the country, practice area, or hospitals where the person has a business or employee relationship.

Within the United States, each citizen is provided with a unique SSN. Similarly, a person who joins an organization should be given a unique identifier. That unique identifier should not be used as a secret authenticator, the way a person’s SSN is often used/ The unique identifier is not the authenticator.

Establish each person’s identity through onboarding systems of record. The most common of these systems is the ERP or HR system. When onboarding new employees in the organization, HR business processes identify and establish the new employee in the organization. Onboarding involves many processes, such as background checks, employment verification, and preparation for payroll.

They provide solid identity proofing that you can use to verify the employee’s identity in the future. They trigger for generating the employee’s new digital identity. These identity-proofing practices respond to the need to understand a person’s relationship and context within the organization. Therefore, it is imperative that IAM programs and functions align with HR practices and business processes in general.

Identities maintain a series of attributes that describe common user elements. The series of attributes comes from the system of record, whether that is an HR system, contingent workforce system, medical staffing office, or other system in the organization’s ecosystem/ Examples of common elements include a person’s name, location, telephone number, e-mail address, job title/job code, and specialization/practice data.

The system of record transmits attributes to the IAM system, enriching the identity data and facilitating the flow of information to systems for login, access management, and other cybersecurity- and business-related functions. In addition to common descriptive attributes, there may be other system- defined attributes (e.g., roles or affiliations used to describe populations of individuals, such as clinician, staff, staff nurse, visitor, student). Organizations can leverage both types of attributes for future authorization components. For example, you can use attributes to authorize eligibility for various systems (using a technique called attribute-based access control [ABAC]).

Users defined under proper identity management processes will include more than your employees. These processes should account for volunteers, locums, contractors, students, visiting scholars, visiting nurses, physician groups staff, billing vendors, visiting residents, organ procurement organizations, special statuses (such as emeritus professors), and third-party vendors that require access to provide services to your organization. Each of these identity types must have an approved channel to serve as the system of record, where the identity proofing activities will occur.

You can store all this identity information in a single repository, enabling its consumption for other purposes. IAM systems, in principle, are an aggregate of system of record data. IAM systems should be a system of last resort when none exists (e.g., contingent workforce if HR/business does not have a solution). At a minimum, follow these basic principles:

• Enumerate all authorized sources of identity within the organization. These sources are often referred to as the systems of record. Examples include HR systems, vendor management systems, contingent workforce systems, medical staffing offices or practice offices, and student information systems.
• Ensure that all users receive a unique identity and identifier. Smaller organizations without multiple constituents may consider using the employee ID number from the system of record. Larger organizations with many constituents should establish a unique identifier for each user and reconcile. Do not use SSNs as unique identifiers! An individual with multiple contexts should have one user record with one unique identifier that ties to all contexts.
• Maintain the integrity and uniqueness of digital identities. Never reuse identities for different people. People come and go throughout the life of an organization. Maintain their records perpetually.
• Proper identity management enables the automation of functions such as system access and authentication. Enumerate and establish attributes, which are critical to provide context to the identity and required for access and authentication controls. For complex and large organizations, this is an important principle to ensure the consistent application of attributes, which in turn enables automated authentication and authorization, for example through automated provisioning and deprovisioning.
• Store identity information in a database or directory capable of registering identity information and associated attributes. Such databases aggregate systems of record data. Consider specialized tools for organizations with multiple constituent types.
• Use a single namespace to establish user accounts within the organization. Tie these user accounts back to the identity so that you can always trace individuals to their digital identities.

After you establish digital identities and user accounts, you must provision users with access to information systems prior to using them. It is important to ensure that provisioning processes follow organizational policies and principles, especially in the healthcare environment.

HIPAA describes key principle of minimum necessary, which states that organizations should take reasonable steps to limit uses, disclosures, or requests of PHI to the minimum required to accomplish the intended purpose. This same principle applies to reducing the attack surface of potentially compromised user accounts. By limiting access, you can limit the scope of a ransomware outbreak or data attack.

Follow these principles for provisioning:

• Identify common systems that all users will need to access and the most basic access rights required for each of those systems. These common systems are referred to as birthright entitlements.
• Define birthright entitlements in organizational policies, procedures, or standards. There should be documentation that describes the access rights that all users receive.
• Establish procedures and workflows that ensure consistent provisioning of birthright entitlements. Consider employing specialized tools to automate this process for accuracy and reliability. Do not automate bad or unknown workflows.
• Establish procedures and workflows that enable provisioning of required access in addition to birthright entitlements, such as access to auxiliary or ancillary systems. Pay special attention to cloud-based systems. Consider leveraging federated access management tools that automatically provision access in the cloud.
• Consider a two-part process that allows users to request access but requires a second individual to approve the request prior to granting access. A common approach is to designate an employee’s supervisor as the approving party.

Leverage IT ticketing systems by building the provisioning workflow into the ticketing system. This establishes consistency in the approval processes, automates the requesting and granting of approval, and documents the granting of access. It is important to ensure that access provisioning processes are auditable.

In addition to establishing a robust process to grant access to users, it is equally important to establish a process to remove access at the right time. Failure to remove access promptly after an employee’s relationship with the organization terminates may result in unauthorized or malicious access to systems.

Follow these principles for deprovisioning:

• Establish procedures to terminate access to user accounts. Execute these procedures promptly at the time of termination. Consider leveraging tools that automate this process after receiving notification of termination from the system of record. The system of record is usually the HR system, although other systems may trigger access termination.
• Ensure that your termination process, whether manual or automated, includes session termination steps to prevent active sessions (e.g., e-mail logins on mobile phones) from remaining active after the employee leaves the organization.
• Establish an “urgent termination” process outside of the normal termination procedures. Use urgent termination in cases of sensitive termination, such as an involuntary termination.
• Ensure that termination procedures include both critical business systems and ancillary or auxiliary systems. Pay special attention to cloud-based systems that are accessible outside of the organization’s standard network. These assets will remain accessible to the user if the deprovisioning process is not completed. Consider using federated access management tools to deprovision access to cloud-based systems automatically.
• Build automatic timeouts for nonuse in critical systems. These timeouts can catch edge cases where deprovisioning procedures are not executed, ultimately reducing the exposure to unauthorized access.

Removal of access should occur when users terminate their relationships with the organization and when users transfer to new functions in the organization. For example, if a patient care services (PCS) manager transfers to the nursing department, access granted when the user was a PCS manager should be removed prior to granting access required by the user as a nurse. This helps to prevent users from accumulating unnecessary access rights.

User accounts must engage in authentication to properly assert the user’s identity in the digital ecosystem. The most common and, unfortunately, the weakest method for authentication relies on password credentials. Nevertheless, password-based authentication systems will continue to exist for the foreseeable future, and organizations should develop solid password authentication practices.

• Centralized authentication: Use central authentication systems, such as Lightweight Directory Access Protocol directories or Active Directory, to the greatest extent possible. Tying authentication mechanisms back to these central systems enables enterprise management of credentials. You can manage the access rights of your user base from a single location. This is incredibly important when access needs to be deprovisioned in a timely and automated manner.

Passwords are the most common credential used to authenticate users. The strength and management of passwords are paramount. Strong passwords combat brute force or password guessing attacks. Assuming you can limit the exposure to brute force and guessing attacks, NIST recommends the following techniques as part of NIST Special Publication 800-63:¹⁶

1. Limit the rate at which authentication attempts can occur. Spacing out each password attempt by a second or two severely limits the ability of automated systems to brute force the password.
2. Ensure the use of cryptographically strong hashing and salting for password storage.
3. Use passphrases in place of passwords. Require a minimum of 8 characters and permit up to 64 characters, as well all printable ASCII characters and spaces.
4. Implement dictionary-based password checking and compromised password blacklists. Prohibit users from establishing risky passwords, such as those used in previous breaches, repetitive or sequential characters, or context-specific words (such as a name of a service, username, or derivatives thereof).

• Privileged account management: Centralized authentication should be used for both general user access and privileged administrative accounts. You must additionally separate privileged administrative accounts from general user accounts. For example, provision an IT administrator at least two accounts: one account for use completing day-to-day activities and a separate administrative account with access only to systems required by the IT administration function. This second step is critical; the use of privileged accounts during normal day-to-day business may expose these accounts to malware attacks, giving an attacker elevated access to the organization’s environment. Limit this exposure as much as possible. Consider the following controls for managing your privileged accounts:
  • Ensure that the passwords set for service accounts are large and complex (at least 32 characters, preferably 64).
  • Rotate these passwords on a frequency you define, but certainly if the password is ever compromised.
  • Escrow privileged systems credentials, making them unique for each system or device.
  • Link privileged access to problem, change, or service tickets in the organization’s ticketing system.
  • Require the use of a jump server when elevating privileges. Ensure full recording and auditing of the jump server.
  • Require brokered access to a privileged account that registers which user is using the privileged account and records all actions taken.
  • Require MFA for all privileged accounts used interactively.
  • Conduct regular reviews of privileged access.
  • Limit actions that privileged accounts can take by using access control lists. Check for the use of sensitive commands and alert the IT or Information Security departments if there is misuse.
• For further details on how to securely configure privileged access, consider the following resources:
  • For Windows, see Microsoft’s article “Implementing Least-Privilege Administrative Models/”¹⁷
  • For Linux, see Redhat’s article “Controlling Root !c cess/”¹⁸
• Local application authentication: There may be cases where applications do not support a centralized authentication model. Although there are increasingly fewer onsite systems that cannot bind to centralized authentication systems, these systems are still prevalent in the health care environment. As organizations migrate applications to the cloud, it is easy to accidentally instantiate a cloud-based service that lacks robust authentication and focuses on local user accounts.

Whenever you use systems with local authentication, you must maintain solid access control procedures to manage user accounts. This requires designating a responsible IT owner who will manage and regularly review these accounts. Failure to do this allows users access to systems for longer than necessary and is especially risky when an employee leaves the organization and continues to have access to these systems. Consider the following extra controls:

• Designate an IT owner for each legacy/cloud-based system.
• Establish a distribution list in your organization which includes your IT owners as members. Submit terminations out to these IT owners as they occur.
• Ensure that IT owners comply with standard operating procedures for the onboarding, review and, most importantly, termination of users.
• Regularly audit compliance with these manual processes. Ensure compliance with regular account review and termination procedures.

MFA systems require the use of several authentication methods to verify a user’s identity. According to the common description, MFA systems use at least two of the following: something you know, something you have, and something you are. Users must correctly address at least two of these three categories before the system will verify their identities and allow access.

The most common MFA techniques use of passwords and one-time codes that are delivered to the user out-of-band from the authentication technique. For example, most banks have MFA capabilities, which require the customer to enter a password (something you know) followed by a verification code that is texted to the customer’s smart phone (something you have).

MFA should be implemented on remote-access technologies to limit the exposure of password credentials that could be compromised through phishing or malware attacks. MFA is an incredibly impactful method at limiting an attacker’s ability to compromise the organization’s environment. Consider implementing MFA on the following types of technologies:

• VPNs: These allow remote network access to your environment. VPNs should be configured to limit user access based on role-based access control (RBAC) or ABAC rules and to enable MFA.
• Virtual desktop environments: These are environments where virtual terminal sessions can be exposed to remote access, allowing your employees to work remotely. Although highly useful for workforce flexibility, virtual desktop environments systems can be compromised easily if they lack MFA authentication.
• Remote e-mail access: If your organization permits remote e-mail access, MFA should be enabled to limit the risk of compromised credential access in the e-mail system. It is common for health care environments to store PHI with these systems, and this exposure could result in a breach of sensitive information, especially if MFA is not used.

Sub-Practices for Large Organizations

Federated identity management enables identity information to be shared between organizations in a trusted manner. This allows identities from home institutions (e.g., individual clinics) to be used across a greater ecosystem (e.g., the entire health network). In health care organizations, it is common for providers, payors, and other affiliates to work together in an integrated manner. In complex, large environments, multiple organizations operate jointly, with different HR practices inside each organization.

Rather than creating identities in each organization involved in such a joint operation, federated identity management tools and processes allow the identity assertions of the home institutions to be used throughout the federation.

Consider the following example: a clinician is part of a practice group that is credentialed within a regional hospital. From the hospital’s perspective, this clinician is not an employee but must be credentialed with access to the electronic medical record (EMR). From the practice group’s perspective, this clinician has been onboarded through standard HR background checks and processes. If the practice group and the hospital were operating within a federation, the clinician’s “home” identity could be established from the practice group and asserted to the hospital as part of the clearance processes. If the clinician’s relationship with the practice group were to change, this identity information would be revoked within the hospital based upon assertions from the federation. These processes would be completely automated.

The same model can be leveraged when working with third-party vendors that provide workforce support or staff-augmentation capabilities. In this case, the third party is the “home institution” that requires access to resources in the organization. To monitor the activities of each of those workforce members would involve a highly complicated and largely manual process unlikely to be effective. A federation can solve this problem.

In complex environments such as large integrated delivery networks, federations are almost a requirement to properly manage the temporal aspects of the identities within.

After authentication has occurred, the mechanism to obtain specific access to an information resource, such as an application system, is referred to as authorization. Authorization processes check the level of access that has been granted to a user credential and ensures that the credential can access only preauthorized areas. Consider the analogy of traveling at the airport. When you pass through the security lines, your identity is authenticated using your ID card or passport, and you are then authorized to access the terminals based on a ticket for a flight. You are not permitted to access any other flight than the one authorized on your ticket.

Authorization limitations are required by the HIPAA privacy rule under the minimum necessary principle. In addition to HIPAA compliance, minimum necessary is a leading practice to limit malicious use of credentials. In most cases, when hackers break into systems, they are trying to access the “keys to the kingdom,” or privileged access credentials that permit access to the most sensitive resources. Do not risk unauthorized access by granting more access than necessary to your users!

Consider the following techniques to limit authorization to only those components required by the user:

It can be difficult to provision granular authorization models based on users’ roles. In healthcare, two individuals might have the same job title and role, yet completely different tasks within the organization. Relying solely on a person’s role to grant access could thus limit the ability for users to fulfill other authorized responsibilities.

• ABAC: Attribute-based authentication models consider the attributes associated with a user’s identity, the attributes of the information system being accessed, and the context associated with the access request. In this model, a user may, for example, be granted an attribute that enables the user to access a specialized function within an information system, but only during business hours or only while onsite. When the user requests access, ABAC systems check the actual context against the access requirements to determine whether access should be granted.²⁰

This highly effective model limits access based on user-specific rules established in the ABAC systems that define access parameters. As an example, a request is made to grant all nurses with access to all patients on a specific floor in a specific hospital to support flexible care requirements. You might be concerned that this access is excessive, since a nurse might not be part of a care team for a particular patient. To minimize this impact, you can leverage ABAC, limiting access to times when the nurse is physically present at a specific hospital and ensuring that access is granted only after the nurse has been authenticated using both a password and MFA. The ABAC access credentials cannot be used to grant remote access to the same patients or to grant access anywhere else within the health care system. In this model, even a hacker with access to the password and the MFA answer would be unable to access patients using those credentials.

When a user joins the organization the onboarding processes generate a lot of access request activities. Once access is established for a user, it can be a challenge to determine, at a given future time, whether that access continues to be required. Consider an employee who has worked for an organization for many years, serving in multiple capacities, and has been placed on special projects and worked throughout the organization. Over time, this employee might accumulate more access than was ever intended.

Conducting a manual review of each employee’s access to each of an organization’s critical application systems would be nearly impossible. Fortunately, specialized tools are available that enable an organization’s leadership to review system access in an automated, self-service capacity. These tools are generally referred to as access governance tools. Below are the relevant components:

• Tooling: Specialized tools bind to identity management systems and connect to critical business systems to understand the access in place for all users in these systems. These tools require the ability to connect with and parse through specific aspects of the applications in question, such as EMR systems, revenue cycle systems, imaging systems, lab systems, and more.
• Access rules: Within access governance tools, specialized rules can be defined based on roles or user attributes. For example, a financial system must define the role differences between accounts payable and accounts receivable. No employee should be capable of access with both roles. Otherwise, a fraudulent purchase order could be generated and the invoice paid by the same person, resulting in a fraud loss to the organization. Understanding the characteristics and requirements of these critical roles enables you to create automated alerts that control user access.

In addition to the standard segregation of duties checks, some specialized tools compare access profiles of certain users in a role to identify outliers. For example, these tools can assess the usual pattern of access granted to nurses across multiple systems. This pattern can then be set as a baseline of access, and the tool can compare each user against that baseline. If a specific nurse is determined to have excessive access, the user can be reviewed for appropriate adjustments.

Federated single sign on (SSO) is an effective method to authenticate users against centralized credential repositories. SSO techniques abstract authentication principles away from the general Microsoft- or Linux-based methods into a generalized standard that can be implemented across platforms. SSO involves securely conducting a general authentication process and passing additional identity attribute information to the specific authorization processes in the resources being accessed. It also has the benefit of requiring only one login while an active SSO session is enabled, eliminating annoying password prompts.

Several federated SSO standards exist, including OpenID, Security Assertion Markup Language, OAuth, and Active Directory Federation Services. When implementing cloud-based systems, such as software-as-a-service systems, the use of SSO should be a security requirement.

A health care-specific SSO model leverages a second authentication factor at clinical workstations for easy access within a health care provider space. These systems can be configured to require a user to authenticate once per day or per shift at a clinical workstation, after accessing the larger clinical setting, using a password and key card. Subsequent authentications are conducted by tapping the key card to provide secure, easy access to the clinical workstations. These systems provide MFA within the clinical environment while easing the password authentication processes.

Threats Mitigated

1. Ransomware attacks
2. Insider, accidental or intentional data loss
3. Attacks against connected medical devices that can affect patient Safety

Suggested Metrics

• Number of alerts generated for excessive access to common systems. For example, “allow any” permissions to core applications, SharePoint, file systems, etc.
• Number of users with privileged access, trended over time. The primary goal is to establish a baseline of the normal number of privileged accounts and monitor variances from the baseline.
• Number of automated terminations, trended over time. The goal is to establish a baseline for normal terminations and monitor variances from that baseline. A decrease in the number of terminations can indicate that the automated systems are not terminating access properly.
• Number of elevated privileged access requests, trended over time. The goal is to establish a baseline to determine how much privileged access is granted over a one-week period and monitor variances from that baseline.

14. David Sherry et al/, “Toolkit for Developing and Identity and Access Management (IAM) Program,” EDUCAUSE, last modified May 7, 2013, https://library.educause.edu/resources/2013/5/toolkit-for- developing-an-identity-and-access-management-iam-program.

15. Paul A. Grassi, Michael E. Garcia, and James L. Fenton, Digital Identity Guidelines (NIST Special Publication 800-63, June 2017, Gaithersburg, MD), https://pages.nist.gov/800-63-3/sp800-63-3.html.

16. Paul A. Grassi et al., Digital Identity Guidelines: Authentication and Lifecycle Management (NIST Special Publication 800-63B, June 2017, Gaithersburg, MD), https://pages.nist.gov/800-63-3/sp800- 63b.html#appA.

17. Bill Mathers et al/, “Implementing Least-Privilege Administrative Models,” Microsoft Windows IT Pro Center, last modified May 31, 2017, https://docs.microsoft.com/en-us/windows-server/identity/ad- ds/plan/security-best-practices/implementing-least-privilege-administrative-models.

18. “Controlling Root Access,” Redhat Customer Portal, accessed September 24, 2018, https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec- controlling_root_access.