Critical Control 12: Controlled Use of Administrative Privileges

How do attackers exploit the absence of this control?

The misuse of administrator privileges is a primary method for attackers to spread inside a target enterprise. Two very common attacker techniques take advantage of uncontrolled administrative privileges. In the first, a workstation user, running as a privileged user, is fooled into opening a malicious e-mail attachment, downloading and opening a file from a malicious website, or simply surfing to a website hosting attacker content that can automatically exploit browsers. The file or exploit contains executable code that runs on the victim's machine either automatically or by tricking the user into executing the attacker's content. If the victim user's account has administrative privileges, the attacker can take over the victim's machine completely and install keystroke loggers, sniffers, and remote control software to find administrator passwords and other sensitive data. Similar attacks occur with e-mail. An administrator inadvertently opens an e-mail that contains an infected attachment and this is used to obtain a pivot point within the network that is used to attack other systems.
The second common technique used by attackers is elevation of privileges by guessing or cracking a password for an administrative user to gain access to a target machine. If administrative privileges are loosely and widely distributed, the attacker has a much easier time gaining full control of systems, because there are many more accounts that can act as avenues for the attacker to compromise administrative privileges. One of the most common of these attacks involves the domain administration privileges in large Windows environments, giving the attacker significant control over large numbers of machines and access to the data they contain.

How to Implement, Automate, and Measure the Effectiveness of this Control

  1. Quick wins: Organizations should use automated tools to inventory all administrative accounts and validate that each person with administrative privileges on desktops, laptops, and servers is authorized by a senior executive and that all administrative passwords have at least 12 pseudo-random characters, consistent with the FDCC standard.
  2. Quick wins: Before deploying any new devices in a networked environment, organizations should change all default passwords for applications, operating systems, routers, firewalls, wireless access points, and other systems to a difficult-to-guess value.
  3. Quick wins: Organizations should configure all administrative-level accounts to require regular password changes on a frequent interval of no longer than 60 days.
  4. Quick wins: Organizations should ensure that all service accounts have long and difficult-to-guess passwords that are changed on a periodic basis, as is done for traditional user and administrator passwords, at a frequent interval of no longer than 90 days.
  5. Quick wins: Passwords for all systems should be stored in a well-hashed or encrypted format, with weaker formats such as Windows LANMAN hashes eliminated from the environment. Furthermore, files containing these encrypted or hashed passwords required for systems to authenticate users should be readable only with superuser privileges.
  6. Quick wins: Organizations should use automated scripts to ensure that administrator accounts are used only for system administration activities, and not for reading e-mail, composing documents, or surfing the Internet. Web browsers and e-mail clients especially must be configured to never run as administrator.
  7. Quick wins: Through policy and user awareness, organizations should require that administrators establish unique, different passwords for their administrator and nonadministrative accounts. Each person requiring administrative access should be given his/her own separate account. Administrative accounts should never be shared. Users should only use the Windows "administrator" or Unix "root" accounts in emergency situations. Domain administration accounts should be used when required for system administration instead of local administrator accounts.
  8. Quick wins: Organizations should configure operating systems so that passwords cannot be re-used within a certain timeframe, such as six months.
  9. Visibility/Attribution: Organizations should implement focused auditing on the use of administrative privileged functions and monitor for anomalous behavior (e.g., system reconfigurations during the night shift).
  10. Visibility/Attribution: Organizations should configure systems to issue a log entry and alert when an account is added to or removed from a domain administrators group.
  11. Configuration/Hygiene: All administrative access, including domain administrative access, should use two-factor authentication.
  12. Configuration/Hygiene: Access to a machine (either remotely or locally) should be blocked for administrator-level accounts. Instead, administrators should be required to access a system using a fully logged and nonadministrative account. Then, once logged in to the machine without administrative privileges, the administrator should then transition to administrative privileges using tools such as sudo on Linux/UNIX, Runas on Windows, and other similar facilities for other types of systems.
  13. Configuration/Hygiene: If services are outsourced to third parties, language should be included in the contracts to ensure that they properly protect and control administrative access. It should be validated that they are not sharing passwords and have accountability to hold administrators liable for their actions.
  14. Advanced: Organizations should segregate administrator accounts based on defined roles within the organization. For example, "Workstation admin" accounts should only be allowed administrative access of workstations, laptops, etc.
Associated NIST Special Publication 800-53, Revision 3, Priority 1 Controls
AC-6 (2, 5), AC-17 (3), AC-19, AU-2 (4)
Associated NSA Manageable Network Plan Milestones and Network Security Tasks
Milestone 5: User Access
Milestone 7: Baseline Management

Procedures and Tools to Implement and Automate this Control

Built-in operating system features can extract lists of accounts with superuser privileges, both locally on individual systems and on overall domain controllers. To verify that users with high-privileged accounts do not use such accounts for day-to-day web surfing and e-mail reading, security personnel could periodically gather a list of running processes to determine whether any browsers or e-mail readers are running with high privileges. Such information gathering can be scripted, with short shell scripts searching for a dozen or more different browsers, e-mail readers, and document editing programs running with high privileges on machines. Some legitimate system administration activity may require the execution of such programs over the short term, but long-term or frequent use of such programs with administrative privileges could indicate that an administrator is not adhering to this control.
Additionally, to prevent administrators from accessing the web using their administrator accounts, administrative accounts can be configured to use a web proxy of 127.0.0.1 in some operating systems that allow user-level configuration of web proxy settings. Furthermore, in some environments, administrator accounts do not require the ability to receive e-mail. These accounts can be created without an e-mail box on the system.
To enforce the requirement for password length of 12 or more characters, built-in operating system features for minimum password length can be configured that prevent users from choosing short passwords. To enforce password complexity (requiring passwords to be a string of pseudo-random characters), built-in operating system settings or third-party password complexity enforcement tools can be applied.

Control 12 Metric:

The system must be configured to comply with password policies at least as stringent as those described in the controls above. Additionally, security personnel must be notified via an alert or e-mail within 24 hours of the addition of an account to a superuser group, such as a domain administrator. Every 24 hours after that point, the system must alert or send e-mail about the status of administrative privileges until the unauthorized change has been corrected or authorized through a change management process. While the 24-hour timeframes represent the current metric to help organizations improve their state of security, in the future organizations should strive for even more rapid alerting, with notification about new additions to superuser groups sent within two minutes.

Control 12 Test:

To evaluate the implementation of Control 12 on a periodic basis, an evaluation team must verify that the organization's password policy is enforced by creating a temporary, disabled, limited privilege test account on 10 different systems and then attempting to change the password on the account to a value that does not meet the organization's password policy. The selection of these systems must be as random as possible and include a cross-section of the organization's systems and locations. After completion of the test, this account must be removed. Furthermore, the evaluation team must add a temporary disabled test account to a superuser group (such as a domain administrator group) to verify that an alert or e-mail is generated within 24 hours. After this test, the account must be removed from the group and disabled.
Finally, on a periodic basis, the evaluation team must run a script that determines which browser and e-mail client programs are running on a sample of 10 test systems, including five clients and five servers. Any browsers or mail client software running with Windows administrator or Linux/Unix UID 0 privileges must be identified.
Control 12 Sensors, Measurement, and Scoring
Sensor: Password assessment tool
Measurement: Automated password assessment is performed and reports generated. L0phtcrack 6 provides the ability to schedule periodic password assessments and generate reports. Other tools can be scripted to provide similar capabilities. Systems from Critical Control 10 must also be leveraged to check for default passwords on all networked systems.
Score: Automatically verify that password assessment tool is installed: 20 points. Automatically verify that password assessment tool is configured or scripted to run automatically: 40 points. Vulnerability scan configuration from Critical Control 10 automatically verified to cover default passwords on all networked systems: 40 points.
Sensor: Security Event Information Management (SEIM) system
Measurement: Log management and reporting systems from Critical Control 6 must be collecting information on the use of administrative credentials. This requires the ability to report on this criterion, and the individual systems must be configured to report on the use of administrative credentials.
Score: Automated tool verifies systems are configured to report the use of credentials with administrative privileges. 100 points.