Managing Privileged Accounts

Privileged account credentials are prized targets for attackers. It is therefore important to follow a set of practices and protocols that help secure, control, manage, and monitor these accounts. Extra care must be taken to secure privileged accounts because of the significant risks to systems, applications, and services that could result from misuse, creating or exposing vulnerabilities, and/or facilitating unauthorized access.

Privileged or administrative accounts have elevated access to systems and data and are authorized to perform system and security functions that ordinary user accounts are not. They may provide heightened or elevated access to systems, data, and/or to one’s own workstation.

Categories of individuals that typically are granted privileged access include system and database administrators and network infrastructure staff with responsibility to perform system repairs or make changes to software or operating systems. In accordance with the principle of least privilege, privileged accounts should only be provided when required by a person's job responsibilities and individuals should be granted the minimum access sufficient to complete those responsibilities.

Privileged Account Classification and Requirements

Privileged account credentials (for example, passwords, encryption keys, access tokens) are a type of IT security information and are classified as High.

Those who manage or own privileged accounts must meet the requirements outlined in these two standards:

Types of Privileged Accounts

Privileged accounts can be used to install applications, apply patches, change configuration, manage users, and retrieve log files. Some accounts can have institution-wide access, while others are limited to a local environment. Below are some examples of privileged accounts with system and security functions.

Highest priority for securing credentials; at significant risk if not properly protected and maintained:

  • Local administrative accounts. Non-personal accounts that provide administrative access to perform maintenance on workstations (including one’s own), servers, network devices, databases, and platforms.  
  • Privileged user accounts. Administrative privileges on one or more systems or an enterprise network.
  • Domain (Active Directory) administrative accounts. Administrative access across all workstations and servers within the domain.

Additional examples:

  • Service accounts. Local or domain accounts used by an application or service to interact with the operating system.
  • Active Directory administrative accounts. Specific service accounts that permit making changes to the operating system or configuration and grant or revoke access to resources such as shared storage.
  • Application account. Accounts that can access databases, run batch jobs or scripts, or provide access to other applications.

Privileged Account Management

Account Owner Responsibilities

Privileged accounts must have a designated owner(s)—different from the account users—who is ultimately accountable and responsible for reducing the risk of threats to institutional data from misuse, including credentials theft, inappropriate disclosure of sensitive data (whether intentional or accidental), data tampering, and unauthorized access to administrative interfaces and configuration stores.

The privileged account owner is expected to:

  • Identify a specific business need prior to establishing a privileged account.
  • Only grant administrator or other privileged access to authorized users with a job-related need.
  • Configure systems containing university data classified as Restricted, High, or Moderate to require two-factor authentication of privileged account users.
  • Configure systems containing data classified as Restricted or High to audit the actions of privileged account users.
  • Deactivate, suspend, or terminate privileged account access or administrator privileges after notification that authorized users have left their U-M position or no longer have a job-related need for the access.
  • Periodically audit permissions to prevent privilege creep so that users do not accrue new permissions as they move from position to position.  
  • Use a different password for each privileged account (for example, root, administrator) on multiple systems maintained by the same staff.
  • Use enterprise password management software to securely store privileged credentials. U-M offers units a no-cost license for Passwordstate.
  • Follow the naming standards for privileged accounts in the U-M Windows Forest.

Different systems at the university may have additional or specific requirements for privileged accounts.

Account User Responsibilities

Users with elevated privileges, including account owners, are expected to:

  • Where reasonable, authenticate to the system as an individual first and then switch to the administrator account. 
  • Never authenticate to a privileged account via a clear text unencrypted protocol (for example, HTTP or telnet); only authenticate via encrypted protocols (for example, HTTPS; SSH).
  • Enter privileged account credentials only from a U-M managed device or a personally owned device configured to protect sensitive data; never access a privileged account from a public computer or public WiFi.
  • Instead of logging in as a super-user, utilize operating system features such as sudo (Unix/OSX) or “run as” (Windows) that allow for temporary escalation of privileges. Network services that run as privileged accounts present a significant risk. If exploited, a vulnerability in a network service running as a privileged user will grant the attacker privileged access to the network, bypassing all access and security controls.
  • Perform day-to-day work as a non-privileged user and only use privileged accounts for tasks that require additional capabilities and administrative privileges. 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. 
  • Prohibit access to information unless it is required for the performance of specific tasks to support critical system needs.