Controlled Use of Administrative Privileges
The processes and tools used to track/control/prevent/correct the use, assignment, and configuration of administrative privileges on computers, networks, and applications.
Why Is This Control Critical?
The misuse of administrative 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 administrative 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, or identical to passwords used on less critical systems, 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.
How to Implement This Control
|CSC 12-1||Minimize administrative privileges and only use administrative accounts when they are required. Implement focused auditing on the use of administrative privileged functions and monitor for anomalous behavior.||Quick win (One of the "First Five")|
|CSC 12-2||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.||Quick win|
|CSC 12-3||Configure all administrative passwords to be complex and contain letters, numbers, and special characters intermixed, and with no dictionary words present in the password. Pass phrases containing multiple dictionary words, along with special characters, are acceptable if they are of a reasonable length.||Quick win|
|CSC 12-4||Before deploying any new devices in a networked environment, change all default passwords for applications, operating systems, routers, firewalls, wireless access points, and other systems to have values consistent with administration-level accounts.||Quick win|
|CSC 12-5||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 administrative passwords.||Quick win|
|CSC 12-6||Passwords should be hashed or encrypted in storage. Passwords that are hashed should be salted and follow guidance provided in NIST SP 800-132 or similar guidance. Files containing these encrypted or hashed passwords required for systems to authenticate users should be readable only with super-user privileges.||Quick win|
|CSC 12-7||Utilize access control lists to ensure that administrative 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.||Quick win|
|CSC 12-8||Through policy and user awareness, require that administrators establish unique, different passwords for their administrative and non-administrative accounts. Each person requiring administrative access should be given his/her own separate account. 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 administrative accounts.||Quick win|
|CSC 12-9||Configure operating systems so that passwords cannot be re-used within a timeframe of six months.||Quick win|
|CSC 12-10||Configure systems to issue a log entry and alert when an account is added to or removed from a domain administrators' group, or when a new local administrator account is added on a system.||Visibility/Attribution|
|CSC 12-11 (NEW)||Configure systems to issue a log entry and alert when unsuccessful login to an administrative account is attempted.||Visibility/Attribution|
|CSC 12-12||Use multifactor authentication for all administrative access, including domain administrative access. Multi-factor authentication can include a variety of techniques, to include the use of smart cards with certificates, One Time Password (OTP) tokens, and biometrics.||Configuration/ Hygiene|
|CSC 12-13 (NEW)||When using certificates to enable multi-factor certificate-based authentication, ensure that the private keys are protected using strong passwords or are stored in trusted, secure hardware tokens.||Configuration/ Hygiene|
|CSC 12-14||Block access to a machine (either remotely or locally) for administrator-level accounts. Instead, administrators should be required to access a system using a fully logged and non-administrative account. Then, once logged on to the machine without administrative privileges, the administrator should transition to administrative privileges using tools such as Sudo on Linux/UNIX, RunAs on Windows, and other similar facilities for other types of systems. Users would use their own administrative accounts and enter a password each time that is different than their user account.||Configuration/ Hygiene|
CSC 12 Procedures and Tools
Built-in operating system features can extract lists of accounts with super-user 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 should 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.
To enforce the requirement for strong passwords, built-in operating system features for minimum password length can be configured to 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.
CSC 12 Effectiveness Metrics
In order to test the effectiveness of the automated implementation of this control, organizations should measure the following:
1. Does the system report on log-in to administrative accounts?
2. Does the system report on the elevation to administrative access, to include traceability to the user account that performed the elevation?
3. Does the system provide an inventory of all administrative accounts?
4. Does the system report on the addition of new administrative accounts?
5. Does the system allow limitations to be placed on the use of administrative accounts, to include not allowing web browsers and email clients to run as administrator?
6. Does the system prevent administrative accounts from logging into machines, either locally or remotely, instead requiring elevation of privileges once logged in with a user account?
7. Does the system require strong passwords for all administrative accounts and does the system require update of administrator passwords on a regular basis?
8. Does the system audit all attempts to gain access to password files within the system?
9. Does the system comply with password policies detailed in the control (yes or no)?
10. How long does it take for administrators to be notified about user accounts being added to super user groups (time in minutes)?
11. Are additional alerts generated every 24 hours until the user account has been removed from or authorized to be a part of the super user group (yes or no)?
CSC 12 Automation Metrics
In order to automate the collection of relevant data from these systems, organizations should gather the following information with automated technical sensors:
1. How many unauthorized elevated operating system accounts (local administrator/root) are currently configured on the organization's systems (by business unit)?
2. How many unauthorized elevated application accounts are currently configured on the organization's systems (by business unit)?
3. What percentage of the organization's elevated accounts do not currently adhere to the organization's password standard (by business unit)?
4. What percentage of the organization's elevated accounts do not require two-factor authentication (by business unit)?
5. How many attempts to upgrade an account to administrative privileges have been detected on the organization's systems recently (by business unit)?
6. How many attempts to gain access to password files within the system have been detected on the organization's systems recently (by business unit)?
CSC 12 Effectiveness Test
To evaluate the implementation of Control 12 on a periodic basis, the evaluation team must attempt a variety of techniques to gain access and exploit administrative accounts within the system. Each of the following tests must be performed at least three times:
* Attempt to gain access to a cross section of devices within the system, using default administrative passwords.
* Attempt to log-in remotely to machines using administrative accounts directly. Verify that this is disallowed by policy.
* Attempt to log-in directly to a workstation or server with root or administrator accounts. Verify that this is disallowed by policy.
* Attempt to gain access to password files within the system using unauthorized accounts. Verify that access is disallowed and that attempts are logged and reported.
* Attempt to elevate to a privileged account on the system. Verify that the administrator password is required to perform the elevation and that the elevation is logged and reported by the system. Verify that traceability within the audit logs is provided to detail the user account that performed the elevation.
* Attempt to configure weak administrator passwords that are non-compliant with established policy. Verify that the system does not allow weak passwords to be used.
* Attempt to re-use an administrator password that was previously used for the account. Verify that the system requires unique new passwords during each update.
Each of these tests must be performed from multiple, widely distributed systems on the organization's network in order to test the effectiveness of administrator controls.
CSC 12 System Entity Relationship Diagram
Organizations will find that by diagramming the entities necessary to fully meet the goals defined in this control, it will be easier to identify how to implement them, test the controls, and identify where potential failures in the system might occur.
A control system is a device or set of devices used to manage, command, direct, or regulate the behavior of other devices or systems. In this case, we are examining the components of user account provisioning and user authentication. The following list of the steps in the above diagram shows how the entities work together to meet the business goal defined in this control. The list also delineates each of the process steps in order to help identify potential failure points in the overall control.
Step 1: Production systems use proper authentication systems
Step 2: Standard and administrative user accounts use proper authentication systems
Step 3: Standard and administrative user accounts properly managed via group memberships
Step 4: Administrative access to systems properly logged via log management systems
Step 5: Password assessment system validates the strength of the authentication systems.
Critical Security Controls - Version 5
- 1: Inventory of Authorized and Unauthorized Devices
- 2: Inventory of Authorized and Unauthorized Software
- 3: Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers
- 4: Continuous Vulnerability Assessment and Remediation
- 5: Malware Defenses
- 6: Application Software Security
- 7: Wireless Access Control
- 8: Data Recovery Capability
- 9: Security Skills Assessment and Appropriate Training to Fill Gaps
- 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches
- 11: Limitation and Control of Network Ports, Protocols, and Services
- 12: Controlled Use of Administrative Privileges
- 13: Boundary Defense
- 14: Maintenance, Monitoring, and Analysis of Audit Logs
- 15: Controlled Access Based on the Need to Know
- 16: Account Monitoring and Control
- 17: Data Protection
- 18: Incident Response and Management
- 19: Secure Network Engineering
- 20: Penetration Tests and Red Team Exercises
This work is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.
To further clarify the Creative Commons license related to the 20 Critical Controls content, (i) All persons are authorized to use the content as a framework in their organization or to sell professional services related to the content (e.g. a consulting engagement to implement the 20 Critical Controls), and (ii) sale of the contents as a framework model is not authorized. Users of the 20 Critical Controls framework are also required to refer to http://www.sans.org/critical-security-controls/ when referring to the 20 Critical Controls in order to ensure that users are employing the most up to date guidance.
You may use the following code to embed the 20 Critical Controls on your site:
<iframe src="http://www.sans.org/critical-security-controls/" width="1000" height="1200" />