YALE-MSS-9: Authentication and Authorization
YALE-MSS-9.1: Ensure all account types are uniquely authenticated YALE-MSS-9.2: Do not share account credentials (username/password) YALE-MSS-9.3: Utilize secure passwords for authentication |
MSS Guidelines | ITS Linux Implementation |
---|
9.3.1: Change all account usernames and passwords from defaults | 9.3.2: Align (or surpass) password security to align with the current requirements for Net ID credentials | 9.3.3: Lock mobile devices with a password, passcode or pin | 9.3.4: Prohibit password, passcode, or pin reuse for a specified number of generations | 9.3.5: Do not reuse passwords | YALE-MSS-9.4: Grant privileges to IT Systems and data according to the principle of least privilege
MSS Guidelines | ITS Linux Implementation |
---|
YALE-MSS-9.4.1: Review all accounts with access to the system to ensure least privilege is applied | YALE-MSS-9.4.2: Maintain an inventory of all privileged and service accounts and assigned privileges | YALE-MSS-9.5: Deprovision accounts and access when roles & responsibilities change
MSS Guidelines | ITS Linux Implementation |
---|
9.5.1: Ensure accounts are deprovisioned or altered to reflect necessary access when an individual's role or responsibilities change or a user is terminated | 9.5.2: Shared service account passwords should be renewed on a routine basis or when an individual who knew the credentials no longer needs access to the account | 9.5.3: Identify dormant accounts and remove them on a regular basis | YALE-MSS-9.6: Require Multifactor Authentication (MFA) for access to authenticated systems
YALE-MSS-9.7: Use University approved authentication methods
MSS Guidelines | ITS Linux Implementation |
---|
9.7.1: Web applications are required to use Yale credentials to utilize the University's Approved Single Sign On methods | 9.7.2: For non-web applications, use Yale’s central Active Directory services. LDAP is not approved. | MSS Guidelines | ITS Linux Implementation |
---|
9.8.1: Document secrets management decisions and operational practices | YALE-MSS-9.9: Allow only encrypted network protocols for authentication
MSS Guidelines | ITS Linux Implementation |
---|
9.9.1: Use industry standard authentication protocols | YALE-MSS-9.10: Prevent brute force attacks Linux Administrators have user accounts across all systems. Work is done using these accounts, with access to escalate privileges if needed. Other groups/users are given access if applicable. Access is managed through automation and has a standardized level of access. Automation tool users and Jenkins users are created via automation software for use of configuration management and deployments of the application via the Jenkins software respectively. Other service accounts are created for specific use and restricted for that purpose.
YALE-MSS-9.2: Do not share account credentials (username/password)
The Linux Team does not share user accounts.
YALE-MSS-9.3: Utilize secure passwords for authentication
MSS Guidelines | ITS Linux Implementation |
---|
9.3.1: Change all account usernames and passwords from defaults | The Linux Team changes all default passwords upon creation or installation of a service or device. The Application Team is responsible for changing default passwords on applications. |
9.3.2: Align (or surpass) password security to align with the current requirements for Net ID credentials | Access to Linux servers utilizes PKI (public/private keys). Application teams are responsible for setting password complexity. |
9.3.3: Lock mobile devices with a password, passcode or pin | The Linux Team is not responsible for mobile devices. |
9.3.4: Prohibit password, passcode, or pin reuse for a specified number of generations | Access to Linux servers utilizes PKI (public/private keys). Application teams are responsible for setting password reuse policy. |
9.3.5: Do not reuse passwords | Access to Linux servers utilizes PKI (public/private keys). |
YALE-MSS-9.4: Grant privileges to IT Systems and data according to the principle of least privilege
MSS Guidelines | ITS Linux Implementation |
---|
YALE-MSS-9.4.1: Review all accounts with access to the system to ensure least privilege is applied | The Linux Team reviews accounts to ensure least privilege is applied upon account creation but does not currently have a process in place to review the accounts periodically. |
YALE-MSS-9.4.2: Maintain an inventory of all privileged and service accounts and assigned privileges | The Linux Team does not currently have a process to review and remove service accounts and assigned privileges. |
YALE-MSS-9.5: Deprovision accounts and access when roles & responsibilities change
MSS Guidelines | ITS Linux Implementation |
---|
9. |
10 Implement rate limiting or failed authentication lockoutsEnsure accounts are deprovisioned or altered to reflect necessary access when an individual's role or responsibilities change or a user is terminated | If the user whose role is changing is a member of the Linux Team, a change request is submitted by the Manager of the Linux Team which creates appropriate tasks to remove the user from all required systems. If the user whose role is changing is not a member of the Linux Team, it is the user's manager's responsibility to create this request. |
9.5.2: Shared service account passwords should be renewed on a routine basis or when an individual who knew the credentials no longer needs access to the account | When a member of the Linux Team changes roles or is terminated, the Linux Team will roll the root password and the password to Keepass. |
9.5.3: Identify dormant accounts and remove them on a regular basis | The Linux Team does not currently have a process to review and remove dormant and unused accounts. |
YALE-MSS-9.6: Require Multifactor Authentication (MFA) for access to authenticated systems
ITS Linux uses SSH with public key authentication.
YALE-MSS-9.7: Use University approved authentication methods
MSS Guidelines | ITS Linux Implementation |
---|
9.7.1: Web applications are required to use Yale credentials to utilize the University's Approved Single Sign On methods | The Linux Team is not responsible for web application authentication. |
9.7.2: For non-web applications, use Yale’s central Active Directory services. LDAP is not approved. | The Linux Team is not responsible for authentication to applications. |
Passwords are not stored in source code repositories for Linux. Keypass is used to store secrets for the Linux team. Importing secrets into Jenkins and Ansible is documented.
Application owners will need to assess secret management within their own teams.
MSS Guidelines | ITS Linux Implementation |
---|
9.8.1: Document secrets management decisions and operational practices | Decisions are documented in Confluence and appropriate repositories. Work is logged in ServiceNow. |
YALE-MSS-9.9: Allow only encrypted network protocols for authentication
MSS Guidelines | ITS Linux Implementation |
---|
9.9.1: Use industry standard authentication protocols | Managed Linux uses only the secured ports which is "https" (443) and we always recommend end-to-end encryption for applications. Protocols and ciphers are reviewed periodically and adjusted where needed. For Linux administrators, SSH private/public key infrastructure is used for access to all Linux systems. |
YALE-MSS-9.10: Prevent brute force attacks
MSS Guidelines | ITS Linux Implementation |
---|
9.10.1: Implement rate limiting or failed authentication lockouts | The Linux Team does not currently have any controls to prevent Brute Force attacks. |
YALE-MSS-9.11: Use administrative and service accounts for their IT function only
MSS Guidelines | ITS Linux Implementation |
---|
9.11.1: Adjustment of privileged account permissions should be performed by the provider of the account and never the user of the account or a third-partythe account or a third-party | Any privilege account escalation is performed by the Managed Servers Linux team. Access to escalate one's own privilege is not accessible to users. |
YALE-MSS-9.12: Ensure authentication events are associated with an individual and not just an administrative or service account .12: Ensure authentication events are associated with an individual and not just an administrative or service account
Authentications are tracked by individual Net IDs.
The "root" user cannot be logged into directly on any Linux system. Linux administrators log in using their own ID and any account privilege escalation is logged via system logs.
MSS Guidelines | ITS Linux Implementation |
---|
9.12.1: Disable direct login with generic, shared account names ("root", "administrator", "dba", "sa"). The login accounts must meet the account requirements outlined in Yale-MSS-9.3. | Where applicable, Linux disables direct login to service & shared accounts in favor of user login with switch user privileges. |
9.12.2: Do not allow direct logins to accounts with administrative privileges. Require users to log in with an individual account and escalate privileges. | ITS Linux requires login with NetID and then escalate privileges. |