8C ­ Identification and Authentication 

Table of Contents 
Document  1 
Comments and Attachments  6 
Stakeholders & Metadata  7 
Document 
8C ­ Identification and Authentication  
  

  

  

8C ­ Identification and Authentication  
Rally Health Information Security Standard 
Current Version Publish Date: 02/28/2020 
Version: 1.1 
Effective Date: 03/02/2020 
Last Review Date: 03/02/2020 
Original Effective Date: 01/12/2009 
Owner: Security and Compliance 
Description: Employees, contractors, and non­user IDs must be positively authenticated and authorized prior to being granted access to Rally 
Health information technology systems that contain Confidential Information and/or Protected Information. For environments, which are in scope for 
Payment Card Industry (PCI), please refer to 13D, PCI Security Standard, for additional requirements. 
Employee Applicability: All Employees 
Standard Type: Information Security 
Business Applicability: Enterprise Wide 
Country: All Rally Health Countries, United States 
Contractor Applicability: All Rally Health Contractors 
State/Territory: All Rally Health States/ Territories 
  

8C.1 Identification and Authentication 
8C.1.01 Establishing an Identity  
Any individuals or systems that access Protected or Confidential Information owned or managed by Rally Health must have their identity validated 
and access authorized by the appropriate manager or delegate prior to accessing requested resources. The acceptability, validation, and 
verification of identity evidence must meet the requirements of the type of resource access requested. Each individual or system that is granted 
access must be approved by the appropriate management, individual, or team. 

8C.1.02 User Identification and Authentication  
Information systems must uniquely identify and authenticate each individual and system seeking access, unless utilizing the 8C.1.10 Shared 
Identifiers provisions of this standard. 

8C.1.03 Multi‐Factor Authentication Definition and Approval  
Multi‐factor authentication (MFA) is an element of layered security controls to reduce risk associated with high‐risk online activities. MFA must 
have at least two (2) of the three (3) following factors: 
• Something the user knows, e.g., a passcode or PIN; 
• Something the user has, e.g., a smart card, hard token, or registered device; and 
• Something the user is, e.g., a biometric characteristic, such as a fingerprint or voice imprint. All MFA patterns must be approved by Security prior 
to implementation. 

8C.1.04 Risk‐Based Authentication (RBA) Definition  
Risk‐Based Authentication (RBA) solutions evaluate the relative risk that the person attempting to authenticate is who they claim to be. Based on 
the risk evaluation, RBA determines whether to accept the credentials presented or challenges/steps up the authentication requirements. Each 
RBA solution must be approved by Security prior to implementation. RBA as the sole authentication pattern is not approved for privileged account 
authentication. Multi‐Factor Authentication (MFA) is required for privileged authentication. 

8C.1.05 Multi‐Factor With Risk‐Based Authentication Required  
All individuals that access Rally Health‐owned or managed Protected or Confidential information must utilize a user ID and password for the first 
factor, and a Rally Health‐approved pattern for the second factor. The approved patterns are defined in the table below. After initial registration, a 
registered or remembered device may be used as the second factor. This includes privileged and non‐privileged accounts. Risk‐based 
authentication (RBA) must be utilized in conjunction with multi‐ factor authentication (MFA) for non‐privileged account authentication. Compliance 
is required for newly‐developed applications and systems being implemented on or after May 1, 2019 (5/1/2019), and for all applications by April 
1, 2020 (4/1/2020). MFA is not required for accessing Public Data, unless it resides on the Rally Health core network. All Rally Health core network 
access must utilize MFA with RBA. 
User Population  Location of Data Accessed  Factor One  Factor Two  Authentication Solution 

3/25/2020 Page 1
 Duo Hard/Soft/On­Demand 
Core 
Employee  Token 
DMZ  User ID and Password 
Contingent Worker  Smart Card    
Cloud  (contingent upon MFA) 
Contract Vendor/Partner  Yubikey 
Vendor Hosted 
Registered Device 
Healthsafe ID 
Consumer Member  Any       
Rally ID 
Fulfillment of MFA tokens must be done via the relevant Rally Health Access Administration team. All MFA token processes must disable users 
with 90 days of inactivity, and tokens must be unassigned from users upon 365 days of inactivity. Certificates issued in support of MFA tokens 
must expire within 36 months of the original issuance. 

8C.1.06 Replay Resistant Mechanisms  
Information systems must implement replay‐resistant authentication mechanisms for access to privileged and non‐privileged accounts, e.g., time 
sync or challenge‐response one‐time authentication. 

8C.1.07 User Identification (ID) Assignment  
The process to assign user identifiers (e.g., IDs, user IDs) to information systems must contain the following components: 
l Assignment is granted according to a documented business function and a business need‐to‐know. 
l Assignment is authorized by Rally Health management and/or the information owner, or an assigned delegate. 
l There is a separation of duties between the request and approval, e.g., managers must not approve their own access. 
l The ID identifies the individual. 
l The ID is assigned to the intended individual. 
l The reuse of IDs is prohibited. 
l The process of assignment of IDs to individual systems must be documented. 

8C.1.08 Use of Commonly Known Identifiers (IDs) for Rally Health User IDs is Prohibited  
Commonly known account identifiers (IDs), e.g. Social Security number, National ID, etc., must not be used to identify an individual as Rally Health 
user IDs. 

8C.1.09 Dynamic Identifier Management  
Information systems must synchronize with the relevant provisioning system(s) on at least a daily basis. Automated synchronization is to be 
implemented unless technically infeasible, in which case manual synchronization is permitted. Appropriate controls must be in place to ensure 
synchronization failures are detected and remediated promptly, and remediation shall not exceed ten (10) business days. 
  
For more information, see 3A.4.02.01 Removal of Access Upon Termination. 

8C.1.10 Shared Identifiers  
User identities (IDs) must not be utilized by anyone except the individual to whom the ID has been issued. Employees and contractors are 
responsible for all activity performed with their personal user IDs. The use of shared IDs is prohibited except when required by technology 
considerations for performing system administration activities (e.g., database System Administrator, a.k.a. SA, Root or other SA accounts). In 
such cases, use of shared IDs and associated credentials must be managed using password management technologies approved by Security. 
Approved systems must: 
l Only permit the shared ID to be used on a given system by one person at a time, 
l Positively identify the specific individual using the Shared ID during that time, and 
l Maintain a log of that access, thereby preserving accountability and non‐repudiation. 

8C.1.11 Secrets 
A secret is a digital credential (username/password, SSH Key, OTP, etc.) that provides evidence to satisfy verification of an identity claim in order 
to access resources. Secrets must be managed to ensure no credentials are exposed to unauthorized individuals or unintentionally/unknowingly 
leaked. Systems must utilize secrets management no later April 1, 2020. 

8C.1.12 Dynamic Credential Binding  
Each user identity (ID) must have an assigned owner. Binding of IDs and authenticators is required. 

8C.1.13 Identification and Authentication Audit Logging and Monitoring  
Identity and authentication information must be logged in accordance with 6A Logging and Monitoring and 6C Security Event Logs. All 
identification events must be consumable and made consistent with the RallyHealth's Identity Logging and Resolution capabilities. 

8C.2 Service and Privileged Accounts 
8C.2.01 Controls for Non‐User Identities (IDs)  
A non‐user identity (ID) is an account not associated with a particular user. Non‐user IDs include, but are not limited to default operating system 
accounts, application proxy IDs, system monitoring IDs, and service accounts. A service account is a non‐user ID that an application, system, or 
service uses to interface with other technologies. 
  
Interactive use is when a user logs in to a system or tool to perform work. Non‐interactive use is when a service or a system interacts with another 
service or system without human interaction. Non‐user IDs must not be used for interactive log‐on purposes without a documented risk 
decision. Non‐user IDs must be documented and reviewed by the application or system owner. 
  

3/25/2020 Page 2
For use of shared Non‐user IDs, please reference 8C.1.07 User ID Assignment. 

8C.2.02 Controls for Service Accounts  
To request a service account, users must provide a detailed business justification of the service account. All new service accounts must only be 
created to run a single service. 
Service Accounts must adhere to the principle of least privilege. 

8C.2.03 Designated Privileged Security Groups  
Designated privileged security groups must be the only group with local administrative privileges on a server with the following exceptions: 
l Accounts that applications are dependent upon, 
l Cannot be removed from the server, or 
l Central Information Technology (IT) support organizations. 
There shall not be any primary, secondary, or non‐user IDs directly attached to the local admin, except for third‐party applications that do not 
support Directory Services and/or Active Directory (AD) authentication. Designated privileged security groups must not contain any primary 
Microsoft Identities (MSIDs). Designated privileged security groups must not be nested or contain any nested groups, with the exception of global 
groups nested inside of domain local groups in the Cloud Integration Hub (CIH) service domains. All nested privileged groups require a risk 
decision. All designated privileged security groups will follow the privileged security group naming conventions. If a designated privileged security 
group violates any of the above criteria, all local administrative privileges will promptly be removed. 

8C.2.04 Default Accounts  
Default, system, and non‐user accounts should be deleted, disabled, or renamed when technically feasible. If they are required, at minimum, the 
default passwords must be changed prior to being connected to a Rally Health‐owned network. 
  
See 8C.1.10, Shared Identifiers, for more information. 
  

8C.3 Common Identity Web Single Sign On (SSO) 
8C.3.01 Use of Approved Single Sign‐On Solution  
Web single sign‐on (SSO) functionality with a common user identity (ID) can be done only with Rally Health Information Technology (IT)‐approved 
solutions (i.e., Okta). 

8C.3.02 Approved Federation Protocol  
Federated Web single sign‐on (SSO) must use a Rally Health Information Technology (IT)‐approved protocol (e.g. SAML, a.k.a.: Security Access 
Markup Language). 

8C.3.03 Approved Protocol Implementation  
Only supporting Rally Health information technology (IT) organization‐approved implementations of an approved Federation protocol may be used. 

8C.3.04 Approved Common Identity Web Single Sign‐On Solutions Control Standard Statement 
Okta is the approved solution for common identity (ID) web single sign‐on. Okta provides common ID web single sign‐on functionality using a 
browser cookie to identify an authenticated user session. This functionality in Okta is approved for use for both internal and external web 
applications. 
  

8C.4 Password‐Based Authentication 
8C.4.01 Password‐Based Authentication  
The following requirements must be in place if the authentication system is password‐based: 
1. Where technically feasible, the password authentication system must maintain a list of commonly‐used, expected, or compromised 
passwords, and updates made to the list on a periodic basis, and when organizational passwords have been compromised. 
2. Passwords for the purpose of user/system authentication when validating matching credentials for system(s) or individual(s) access must 
be stored using an Security     ‐approved encryption or hashing protocol, and must not be stored in unapproved storage tools (e.g, 
spreadsheets, electronic notepads, text tools, or other unapproved third party password storage solution.) 
3. Passwords must be encrypted or hashed during transmission over internal and external networks. 
4. Initial passwords must be changed automatically after first use, if technically feasible. If systems do not allow for automatic changing of initial 
passwords, they must be changed manually. Initial passwords must be generated in a manner that ensures multiple users do not receive the 
same initial password, nor are passwords assigned or generated through a pattern, (e.g. incremental passwords). 
5. Any default credentials included in products must be changed prior to information system installation or software deployment. 
6. Initialization (boot) settings must be password‐protected. 
7. A new password must be immediately selected upon account recovery. 
8. Information systems must store and prevent reuse of the ID's 10 previous passwords; 
9. Where technically feasible, allow the selection of long passwords and passphrases, including spaces and all printable characters. At a 
minimum: 
1. Complexity: Passwords must use at least three (3) of these four (4) elements: 
1. Uppercase characters 
2. Lowercase characters 
3. Numeric (0‐9), or 
4. Non‐alpha numeric characters (e.g., ?, %, *, $, etc.); 
Consumer applications with compensatory controls of logging and monitoring of failed login attempts and inactive account 

3/25/2020 Page 3
 lockout must have at least two (2) of these elements. 
2. Length: At least 8 characters. 
10. Expiration: We follow modern best practices, based on NIST­800­63. For internal systems, passwords must be strong, as described 
above, checked against a database of compromised passwords, and changed if they are found to have been compromised. Compromise 
checks should occur at password set up or password reset, preventing users from selecting a compromised password at on­set and 
periodically, at least every 90 days. All systems for which such compromise check is not feasible, passwords must be changed at the 
following intervals via automatic or manual expiration.
1. User identities (IDs) ­ 90 days 
2. Non­user IDs ­ 365 days, with up to a 30­day extension to enable consistent operational timing each year. 
11. Where technically feasible, automated tools must use strong password authenticators. 
12. One‐time passwords must meet the following requirements: 
1. Numeric: At least 6‐8 numeric digits, or 
2. Alpha‐Numeric: At least six characters. 

8C.4.02 Protection of Authenticators  
Authenticator information (e.g., passwords, PIN, etc.) are considered restricted Protected Identifiable Information and must be protected as such. 
Passwords, private keys, PINs, or the combination of authenticators that allow unauthorized access (such as user ID and password) must not be 
shared with anyone, written, stored in unapproved electronic storage tools (e.g., spreadsheets, electronic notepads, text tools, or other unapproved 
third‐party password storage solution), or displayed in an accessible location unless in compliance with 8C.1.10, Shared Identifiers. 
  
Only Security approved password storage tools or electronic vaults are approved for non‐privileged (e.g. standard user) access. 

8C.4.03 Transmitting Passwords and User IDs  
Passwords must be encrypted during transmission over internal and external networks. Passwords in conjunction with their associated user 
identities (IDs) (i.e. User ID/password pairs) must not be transmitted in the same transmission over any network (internal or external). If passwords 
need to be transmitted in conjunction with associated user IDs in the same transmission over external networks, or where required by law or 
regulation, the entire transmission must be encrypted. If passwords need to be transmitted in conjunction with associated user IDs in the same 
transmission over internal networks, the entire transmission must be encrypted where technically feasible. 

8C.4.04 Unencrypted Embedded Static Authenticators Prohibited  
Unencrypted static authenticators (e.g., passwords, private key, etc.) must not be coded into or stored within applications, access scripts, stored 
function scripts, login scripts, voice over Internet protocol (VOIP) communications programs, browsers, or any executable program or file. This 
includes 'save password' or 'auto‐logon' functions. 

8C.4.05 Multiple Information System Accounts  
Individuals must not re‐use passwords on multiple accounts. It is especially important not to use a common password both for access to Rally 
Health information assets and to non‐Rally Health information assets. 

8C.4.06 Authenticator Feedback  
Information systems must, by default, obscure feedback of authentication information during the authentication process to protect the information 
from possible exploitation/use by unauthorized individuals. This includes masking, suppression, or otherwise obscuring in such a method that 
unauthorized individuals are unable to observe and/or subsequently recover them. Information systems may permit end users to un‐mask such 
information if the user elects. 

8C.4.07 Password and PIN Resets: Re‐Authenticating Users  
An individual user is the only individual who can direct to have their account passwords changed. The user must enter the old password when 
changing to a new password where technically possible. New passwords cannot be changed more than once in a 24‐hour period. 
  
It is the responsibility of the access control authority, whether it is the Information Owner, Resource Administrator, or Service Desk, to verify the 
identity of the user requesting the password reset, prior to the password reset being performed. 
  

8C.5 End‐Point Multi‐Factor Authentication 
8C.5.01 UnitedHealth Group‐Issued End‐Point Multi‐Factor Authentication  
All Optum Technology (OT)‐issued laptops or workstations must require a UnitedHealth Group‐issued second factor, (factor two) to gain access 
to the device. 
For categories of users who are not required to satisfy this requirement, see the Factor Two Guideline. 
  
UnitedHealth Group‐issued factor two enforcement may only be disabled for the duration of the maintenance window to perform specific, 
approved maintenance tasks. 
Factor two should be removed when a workstation or laptop is unattended. Users must not modify the dimensions or structure of the second factor. 
  
Users must physically protect their second factor and avoid improper handling such as but not limited to excessive bending or twisting and extreme 
temperatures. 
  
Factor two must not be modified or labeled with company information (e.g. stickers, logos, etc. Factor two must not be modified or labeled to 
indicate purpose and/or functionality. 
Users must not attempt to modify or bypass factor two controls, disrupt the tokenization method, or extract the private key. Damaged, lost, stolen, 
misplaced, or forgotten second factors must be immediately reported to the helpdesk. Only the user assigned to the second factor may request 

3/25/2020 Page 4
assistance from the helpdesk with second factor issues. 
  

8C.6 Biometric Based Authentication 
8C.6.01 Biometric Based Authentication  
If the information system utilizes biometric‐based authentication, the following requirements must be in place: 
l Biometric data must be protected to ensure it is unreadable and unusable if stolen. 
l An opt‐in must be presented to users to use biometric data for authentication, and users must have the ability to opt‐ out at any time. Upon 
opting out, the biometric data must be purged. 
l Biometric data can be locally stored or centrally stored, such as on a server or a database. Biometric data stored locally for authentication 
must not be shared with the backend system/servers. 
l Biometric data used for authentication purposes is considered Personally Identifiable Information (PII). If biometric data used in the context 
of healthcare and treatment, it is considered Protected Health Information (PHI), 
l Biometric authentication solutions must provide live detection capabilities to prevent presentation attacks. Local regulations may affect the 
use of biometrics for authentication. Consult with Legal and Privacy to identify any additional requirements regarding biometric 
authentication. 

8C.7 Public and Private Key‐Based Authentication 
8C.7.01 Public‐Key‐Based Authentication  
The following requirements must be in place if the authentication system is public key‐based: 
l Enforces authorized access to the corresponding private key, and 
l Maps the authenticated identity to the account of the individual. 
When public key infrastructure (PKI) is used: 
l Validate certifications by constructing and verifying a certification path to an accepted trust anchor, including checking certificate status 
information; 
l Validate that the identity in the digital certificate matches the identity of the private key holder for applications or infrastructure, and 
l Implement a local cache of revocation data to support path discovery and validation in case of inability to access revocation information via 
the network. 

8C.7.02 Private Key‐Based Authentication  
The private key must be protected by a password or PIN when stored locally. Private key stores must lockout after no more than 10 consecutive, 
unsuccessful attempts. 

3/25/2020 Page 5
 
Comments and Attachments 
8C ­ Identification and Authentication  
  
Attachments: 

3/25/2020 Page 6
 
Stakeholders & Metadata 
8C ­ Identification and Authentication  
  
Subject Matter Expert:  Main, Marcia 
Responsible Team:  Security 
Document Version:  
  
Reference Number:  
8C 
UHG Reference Number:  
  
  
Effective Date:  1/1/2019 
Last Review Date:  3/3/2020 
Document Type:  Standard 
Parent:    
Related Compliance Docs:    

Title  Reference Number 
No records to display 
  
  

3/25/2020 Page 7