NIST 800-63 For Unix/Linux Servers
When it comes to controlling logins and privileges on Unix/Linux servers, Centrify’s philosophy is aligned with modern NIST recommendations, as opposed to traditional vendors whose solutions are centered around a password vault. Centrify believes users should login directly as themselves and elevate privileges granularly as needed and authorized. We also have a vault solution for shared account password management (SAPM), however we believe this should only be used for break-glass scenarios and other limited use cases when there is no other choice except to use a privileged account’s vaulted password. The reason Centrify believes users should login directly as themselves, using their Active Directory account or a personal admin account without default privileges, is because it provides a higher level of authentication assurance according to NIST, and provides better accountability through host-based user authentication, privilege management and host-based session auditing.
The use of a password vault to provide login services on a target computer, where the authentication was performed by replaying a password, is classified as AAL1 (Authentication Assurance Level 1) according to NIST 800-63b. Additionally, even if a password vault were to provide SSH Public Key based authentication, it would still result in authentication at AAL1 since this is considered single-factor cryptographic software based authentication. Furthermore, if we add multi-factor authentication (MFA) in front of the password vault, so that users must MFA before getting the shared account password, it results in AAL2 for access to the vault but only AAL1 authentication as far as the host is concerned. Remember that attackers are trying to attack the hosts to get sensitive information -- this is why it is important to focus on the authentication assurance level at the host versus at the password vault, even though that is very important as well. For this reason, password vaults should only be used for truly break-glass situations.
The Centrify solution for Unix/Linux servers provides what NIST calls Federated Authentication for IT Staff access to servers, where authentication is performed using Kerberos after the user authenticates to Active Directory, resulting in user authentication at FAL2 (Federated Authentication Level 2) to the host according to NIST 800-63c. If the IT staff uses an account in Active Directory that has been configured to require smart card login, then the resulting Kerberos authentication is FAL3. The requirement for these FAL2+ levels is that the authentication must be verified by the system you are logging into. Consequently, the specific federated authentication requirement in our use case is that each of the UNIX or Linux computers must to be joined to Active Directory in order to trust the Kerberos based authentication. The use of any vaulted password solution does not provide the authentication assurances required by the system you are logging in to, and subsequently is less secure then the Centrify AD Bridging agent, according to NIST.
The reason Centrify’s best practices focuses on the AAL at the host is that we want to help our customers prevent the malicious misuse by an attacker (ex. OPM attackers) of a valid account by enforcing host-based MFA or federated login as described above. Additionally, Centrify recommends limiting both access rights and privileged command execution through a combination of (a) Request access for time-limited access to systems, and (b) least privilege policies to prevent abuse by malicious insiders (ex. Manning or Snowden).
Furthermore, best practices suggest that after a user logs into a Unix/Linux server at FAL2+, they should then leverage privilege elevation policies for specific commands required for their role. These policies should be implemented using RBAC that leverage AD groups, so that users have access only to the specific privileges they need, no more and no less, and therefore in compliance with NIST 800-53.
For more information on Centrify Federal Compliance Solutions, please visit here.
This is written by the individual author in his/her personal capacity, and the opinions, views and/or thoughts expressed herein are solely the author’s own. They are not intended to and may not necessarily reflect the official policy or position, or the opinions or views of ThycoticCentrify or its affiliates, employees, or any other group or individual.