All UC Berkeley IT Resources and all devices connected to the UC Berkeley network or cloud services must comply with the Minimum Security Standard for Networked Devices (MSSND). The recommendations below are provided as optional guidance to assist with achieving the Privileged Accounts requirement.
MSSND Privileged Accounts Requirements
Devices must be configured with separate accounts for privileged (administrator) and non-privileged (user) access.
-
Non-privileged user accounts must be used and only elevated to root or Administrator when necessary.A secure mechanism to escalate privileges (e.g., via User Account Control or via sudo) with a standard account is acceptable to meet this requirement.
-
Privileged and super-user accounts (Administrator, root, etc.) must not be used for non-administrator activities.
Network services must run under accounts assigned the minimum necessary privileges.
For devices that do not support separation of privileges: Devices that do not provide separate facilities for privileged and unprivileged access (e.g., some network appliances and printers with embedded operating systems) are exempt from this requirement, provided they do not handle P3 or P4 data and are not on a network containing P4 data.
Background and Description of Risk
Privileged access gives a user the ability to perform any task on a device without restriction and is necessary for the provisioning and administration of the device. For the following reasons this access should only be used for the duration of those activities that require it.
- Risk of Malware Infection: Many types of malware infect and spread by changing system configurations and installing new services, two activities that are generally limited to privileged users. When reading email, browsing the web, or accessing files as a privileged user, any malware a user encounters will also run as a privileged user, bypassing all access and security controls. Additionally, malware introduced through administrative activities is more likely to capture administrative passwords or read files containing private keys or other administrative credentials.
- Risk of Accidental Errors: Privileged access bypasses access controls, so errors made by a privileged user may have catastrophic consequences, resulting in data loss or significant downtime.
- For example, on a Unix system, an extra space may turn “rm –Rf /tmp/olddata” into “rm –Rf / tmp/olddata”, deleting the entire file system. Limiting the use of privileged access to only those times when that access is required reduces the likelihood of this type of error.
- For example, on a Unix system, an extra space may turn “rm –Rf /tmp/olddata” into “rm –Rf / tmp/olddata”, deleting the entire file system. Limiting the use of privileged access to only those times when that access is required reduces the likelihood of this type of error.
- Risk of Compromise to Service Accounts with Administrative Privileges: Besides the risk associated with unnecessary use of privilege by a user, network services that run as privileged accounts present a significant risk as well. If exploited, a vulnerability in a network service running as a privileged user will grant the attacker privileged access to the device, bypassing all access and security controls.
Recommendations
1. For all staff, faculty, and students with administrator access on any devices on the campus network, whether institutionally- or personally-owned:
1.1 Use Operating System privilege elevation features
Privileged accounts should only be used when elevated permissions are needed for a specific task. Instead of logging in as a super-user, or placing a user account in a group that provides privileged access, utilize operating system features such as “sudo” (Unix/OSX) or “Run As…” (Windows) which allow for temporary elevation of privileges.
If these features are not available, practice rigorous self-discipline and only log in as a super-user when necessary.
Similarly, when working on devices that do not provide separate facilities for privileged or unprivileged access (e.g., some network appliances and printers with embedded operating systems) only stay logged into the device for as long as necessary to perform the administrative task, then log out.
2. For campus IT Workforce Members and IT administration organizations:
2.1 Maintain an up-to-date inventory of all privileged accounts
Keep an inventory of privileged accounts for critical Active Directory groups (such as Domain Admins), admin and root accounts for unix servers, databases, and business applications. Include network devices, such as printers, firewalls, routers and other infrastructure equipment. Also include accounts associated with cloud applications (e.g., SaaS, PaaS or IaaS), or other 3rd-party services.
The inventory should identify the owner of each privileged account, the access privileges granted, the system component it is associated with, the location of the device, and the contact info for the account owner. Keep the inventory updated and document all changes. Secure the inventory appropriately (e.g., limit file access permissions).
At appropriate intervals (at least annually), regularly review privileged access assignments. Document all changes in detail.
2.2 Do not share admin accounts
For privileged access, administrators should each use a unique account that is tied to their personal identity and is separate from their day-to-day user account. The default administrator, root or similar accounts should only be used when absolutely necessary; it is better to rename or disable them.
2.3 Limit the scope of permissions for each privileged account
Many privileged accounts have no limits; they have full access to everything. To minimize risk, enforce the principle of least privilege by granting employees the minimum privileges needed to perform their jobs (e.g., “full admin” vs. “Power user” vs. “regular user”). Delegate permissions when possible and utilize role-based access control (RBAC) in systems and applications where possible.
2.4 Follow passphrase best practices:
In addition to the recommendations found in the campus Passphrase and Admin Account Security guidelines, consider the following passphrase best practices for administrator accounts:
-
Change the passphrase on each device so you are not using the default passphrase
-
Avoid using hard-coded passphrases in applications and appliances
-
Require privileged account passphrases to be changed when administrators with access leave, or their responsibilities have changed, to reduce the risk of departing employees compromising systems
-
Never share privileged account passphrases or store them in plain text; use password management tools or an encrypted file for this purpose
-
Safeguard privileged accounts by using two-factor authentication when available (e.g., for campus enterprise applications use Duo; for SSH, use an SSH certificate as well as account password authentication)
2.5 Use a Privileged Access Management (PAM) system
Privileged Access Management (PAM) refers to a class of solutions that help secure, control, manage and monitor privileged access to critical assets. PAM solutions secure the credentials of privileged accounts by storing them inside a secure repository (a vault) to reduce the risk of those credentials being stolen. System administrators are authenticated through the PAM system to access these credentials, where all privileged use activity is logged.
Examples of public domain and commercial PAM products include:
-
Hashicorp Vault is a freely available product that includes features for securing SSH authentication, as well as various cloud services.
-
Cmd is a commercial service-based platform for managing access control.
These types of products can add a large amount of complexity and availability concerns, but for teams managing large server pools, especially with multiple administrators with varying privilege levels, these applications can also add a great deal of value.
For campus IT administration organizations that utilize campus Active Directory (AD) services, contact Berkeley IT Platform Services to learn more about available PAM services for AD admin account administration.
2.6 Monitor and log all privileged activity
Privileged account activity should be logged. Examples of events to log include:
-
The use of admin privileges (e.g. sudo logs)
-
Successful and failed admin login attempts or privilege escalation attempts
-
Account lockout events
-
Changes to privileged groups (e.g. addition of a user account to a privileged group)
-
Actions of privileged account usage
For systems and applications involving P4 protected data, admin logs should be monitored and reviewed periodically
2.7 Restrict access
Where possible, restrict access to administer devices by IP address (e.g., for SSH, restrict by IP at the key level). Only allow access through a network and/or host-based firewall from a secure bastion host, or limit access to the campus VPN using Duo 2FA.