The first two articles in this series have taken a high-level approach to privilege management and the need for a reduction in the assignment of administrative privileges. However, a technical explanation is necessary to fully understand how Least Privilege impacts the operation of the IT environment. The explanation in this article will relate to the Microsoft Windows environment and focus on existing solutions that are natively available. Each solution attempts to manifest a resolution to the problem of Least Privilege. As you'll find, each also has limitations in its efficacy and scalability as a holistic solution.
Before discussing each solution in-depth, a look at the limitations of the Windows operating system (OS) itself is first necessary. When a user logs into a computer, the user's interaction with the computer is typically comprised of system configuration activities such as changing networking information or connecting to printers as well as making use of applications that are installed to the computer. Applications are typically installed to the location C:\Program Files or C:\Program Files (x86) (in the case of 32-bit applications installed on x64 systems) with computer-specific information stored in HKEY_LOCAL_MACHINE. These locations are considered secure installation locations by the Windows OS. Standard users are prevented from making changes to these locations. File-based user-specific information is typically stored in the user's profile with registry-based user information stored in HKEY_CURRENT_USER.
This separation between areas that are considered secure and available for users ensures that application installations can be completed only by an assigned administrator. It also ensures that for the protection of the application, its core installation cannot be modified by standard users. Some applications, however, do not recognize the separation between these two areas. Others may require access to drivers and other system-level components that are typically reserved for administrative users only. When applications such as these are installed to a computer, their use effectively requires that its user have Administrator-level access.
As discussed in the first article of this series, the problem is that the common solution for providing this level of access is to add the user to the computer's Administrators group. Doing so results in every action by the user being completed with administrative privileges when the desired result is merely to make one or more "bad" applications run.
Early attempts in the Microsoft Windows environment to limit the use of Administrator privileges suggested that users log in using a non-administrative account. That account would include the privileges necessary to accomplish the "regular" tasks of the day. In the case in which a task requires the use of administrative privileges, early guidance suggested that the user log out and log back in with a separate Administrator account.
This process incurs major administrative overhead to the user. If a user regularly needs to use the "bad" application, the user will find themselves wasting time logging out and back in repeatedly. With no enforcement mechanism in place to ensure proper behavior, many users ultimately chose to log in with their Administrator privileges to the neglect of the lesser-privileged and more secure "primary" account.
An early alternative solution to resolve this problem was the use of the Runas tool. This command-line tool and shell extension allowed users to log into their computers with standard credentials. When the use of an application required administrative elevation, the user would use Runas to launch the application with alternate administrative credentials. Leveraging the use of the Runas tool along with its Windows shell extensions eliminated the need to log out and back in to enable credential elevations. Yet this solution suffered from many of the same limitations as the double-login concept:
Because of these limitations, the use of Runas as a tool for selective elevation is based on little more than the "honor system." Although this might have been moderately effective for use by small groups of highly trusted administrators within IT, the spread of its use through the regular user population was not controllable and did not meet the requirements of a technical control as defined by many compliance regulations.
To combat the inadequacies of Runas, the Windows Vista and Windows Server 2008 OSs were both updated to include a new service called User Account Control (UAC). This change affects how Administrators interact with the OS. In short, when an Administrator logs into a UACenabled system, they initially use a set of credentials that do not have administrative privileges. When the administrator attempts to accomplish a task that requires administrative credentials, the system then switches between the initial "regular" and the alternate "elevated" credentials for the needed activity. To prevent an unwanted action or malware infection from automatically elevating a user's credentials, any occurrence of credential switching involves graying out the desktop and prompting the user to approve the elevation.
UAC affects standard users as well. When a standard user attempts to perform a task that requires elevation, a prompt appears for them as well. This prompt, called an Over the Shoulder (OTS) Elevation Prompt, provides a place to enter credentials for an alternate administrative account. Entering the username and password for an Administrator into the OTS prompt allows the standard user to accomplish the task.
Yet there's a problem with this implementation. The only way to complete an OTS elevation is by handing over Administrator privileges to a user, an action that ultimately gives them the username and password that could be used for future elevations. This implementation results in the same type of person-based credentials assignment that Least Privilege specifically desires to avoid.
With UAC, for a standard user to accomplish a task or run an application that requires elevated privileges, the user must have access to Administrator account credentials. With these credentials, a standard user has what amounts to full control over the entire computer and is no longer operating in a Least Privilege environment.
The implementation of UAC resolves one of the biggest problems with Runas: Namely, the requirement for an Administrator to manually identify and elevate when administrative privileges are necessary. The UAC service in many—though not all—cases automatically recognizes when privilege elevation is required. UAC also resolves some of the issues associated with Runas' use of completely separated credentials for standard and administrative access. When an Administrator elevates their credentials, they are effectively using the same user account. However, UAC still suffers from significant limitations that make it challenging to use in an enterprise environment:
To this point, this series has discussed the definition of Least Privilege, the benefits it portends to provide for the IT environment, and how native solutions have yet to truly align with its goals. In order to achieve an environment that supports Least Privilege, there are a set of desired capabilities that are necessary. These capabilities at present are not available through the native Windows OS but in many cases are available through third-party add-on products. Although not a comprehensive list, consider the following needed capabilities when looking for solutions that enable Least Privilege:
Third-party applications are available today that augment the native OS as well as UAC by enabling elevations while protecting the OS from attack. This additional software assists IT with maintaining a secured and controlled desktop that supports the needs of the user while providing the protections required by IT.