Docstoc

ESEARFinal

Document Sample
ESEARFinal Powered By Docstoc
					The Essentials Series


Eliminating
Administrator
Rights
 sponsored by
                by Greg Shields
Article 1: Understanding Least Privilege.........................................................................................1
          Least Privilege Is More than Eliminating Admin Rights.....................................................2
          Breaking Apart Least Privilege............................................................................................3
                     The User’s Role .......................................................................................................3
                     The Available Tasks ................................................................................................4
                     The Corporate Policy ...............................................................................................4
          Least Privilege Inhibits Inappropriate Behaviors ................................................................5
Article 2: The Business Benefits of Eliminating Administrator Rights ..........................................6
          Operational Benefits ............................................................................................................7
          Security Benefits..................................................................................................................8
          Compliance Benefits............................................................................................................9
          Not Just for Enterprises......................................................................................................10
Article 3: Limitations in Native Solutions for Privilege Management ..........................................11
          Runas..................................................................................................................................12
          User Account Control ........................................................................................................13
          Capabilities to Resolve Least Privilege .............................................................................15




                                                                        i
Copyright Statement
    © 2008 Realtime Publishers, Inc. All rights reserved. This site contains materials that
    have been created, developed, or commissioned by, and published with the permission
    of, Realtime Publishers, Inc. (the “Materials”) and this site and any such Materials are
    protected by international copyright and trademark laws.
    THE MATERIALS ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND,
    EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED
    WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
    TITLE AND NON-INFRINGEMENT. The Materials are subject to change without notice
    and do not represent a commitment on the part of Realtime Publishers, Inc or its web site
    sponsors. In no event shall Realtime Publishers, Inc. or its web site sponsors be held
    liable for technical or editorial errors or omissions contained in the Materials, including
    without limitation, for any direct, indirect, incidental, special, exemplary or consequential
    damages whatsoever resulting from the use of any information contained in the Materials.
    The Materials (including but not limited to the text, images, audio, and/or video) may not
    be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any
    way, in whole or in part, except that one copy may be downloaded for your personal, non-
    commercial use on a single computer. In connection with such use, you may not modify
    or obscure any copyright or other proprietary notice.
    The Materials may contain trademarks, services marks and logos that are the property of
    third parties. You are not permitted to use these trademarks, services marks or logos
    without prior written consent of such third parties.
    Realtime Publishers and the Realtime Publishers logo are registered in the US Patent &
    Trademark Office. All other product or service names are the property of their respective
    owners.
    If you have any questions about these terms, or if you would like information about
    licensing materials from Realtime Publishers, please contact us via e-mail at
    info@realtimepublishers.com.




                                                  ii
Article 1: Understanding Least Privilege
“We’re still using that ancient corporate application and it requires Administrator privileges on
every desktop to run…”
“The CIO told me he needed Admin rights on his laptop due to his travel schedule…”
“Without Administrator privileges, our Help desk is forced to do all the work for customizing
users’ desktops, and they’re just overloaded…”
The likelihood is great that you’ve experienced one or more of these situations at some point in
your IT career. Ancient and poorly coded applications require Administrator privileges at every
desktop for their correct functionality. Executives and individuals of power within organizations
pull rank to be exempted from company security policy. Strained Help desk personnel succumb
to peer pressure from employees to “just give me rights and I’ll take care of myself.” In all of
these situations in the world of IT, individual user privileges are inappropriately expanded due to
the operational needs of the day.
But each and every time those privileges are expanded unnecessarily as a global resolution to an
individual problem, the end result is a reduction in environment security. Every time elevated
privileges are handed out to solve today’s problem, this action invariably causes bigger issues
down the road.
All of these situations relate to and are resolved through the implementation of the concept of
“Least Privilege.” The Principle of Least Privilege was developed more than 30 years ago by the
US government’s Department of Defense (DoD). Looking at computer systems from the
perspective of complete security, the DoD defined Least Privilege in that day as:
       [The Principle of Least Privilege] requires that each subject in a system be granted the
       most restrictive set of privileges…needed for the performance of authorized tasks. The
       application of this principle limits the damage that can result from accident, error, or
       unauthorized use.
Today, the concept of Least Privilege is used to identify a state at which the lowest level of
privileges are assigned to computer system elements while still enabling needed activities to be
accomplished.




                                                 1
Least Privilege Is More than Eliminating Admin Rights
The previous definition effectively says that any action you attempt to accomplish with a
computer must be done with the absolute lowest level of privileges required to accomplish that
task. For many administrators, this equates to getting rid of administrative rights wherever
possible within the organization. But eliminating admin rights on servers and desktops only
accomplishes part of Least Privilege’s lofty goals. Accomplishing its goals means digging deeper
into the functionality of the operating system (OS) to enable those fewest privileges necessary to
perform authorized tasks. Succeeding requires a few additional steps beyond merely eliminating
admin rights on user desktops:
   •   First, think outside the “Administrator” box. Assigning a user to the Administrators
       group grants that user complete power over the processing of his or her computer system.
       Yet a user often needs elevated privileges for only a single or a few actions on that
       system. Granting the user complete power over that system for the purposes of solving a
       single need is unnecessarily excessive.
   •   All types of person-based privileges are too coarse. Many organizations initially attempt
       to reduce user access by converting unnecessary Administrators to other access levels
       such as Power User. Though this movement has the tendency to reduce that user’s overall
       level of access, these “person-based” privileges are still exercised over an entire
       computer. This process of changing the user’s assigned role still grants the user those
       privileges over every aspect of the computer system. This result is still not granular
       enough to truly fulfill the needs of Least Privilege.
   •   Control privileges at a per-process or a per-application level. When a user works with a
       computer system, that user is launching various applications and processes on the system.
       Those applications and processes enable the user to work with data and accomplish job
       tasks. Controlling the level of privileges assigned to each process or application
       eliminates the need for privilege assignment based on who the user is. Rather, privileges
       can be assigned based on the combination of who the user is and what the user needs to
       do.




                                                 2
Breaking Apart Least Privilege
Ultimately, the goal of Least Privilege is in assigning privileges to users based on the intersection
of the role held by the user, the tasks the user needs to accomplish, and the policy of the
organization. Figure 1 provides an example of this intersection. This combination of who the
person is as defined by their assigned role within the organization, the actions required as a part
of their role, and when those actions are considered appropriate ensures the greatest level of
control over the user’s interactions with the organization’s computer systems. The next three
sections discuss each of these three elements in more detail.



                    The User’s
                      Role




                       Least
                      Privilege

      The                              The
    Corporate                        Available
     Policy                           Tasks



Figure 1: Least Privilege is involved with the intersection of the three elements shown.


The User’s Role
Each user within an organization has a role to play in the operation of business. A user in the
accounting department may require access to financial documents. A salesperson needs the use
of the sales application and customer database. Users in IT require access to administrate
systems. Each user’s role is involved with completing one aspect of the needs of the business.
The role element of Least Privilege is used first in combination with the task element to be
discussed in the next section. Roles in an organization are mapped to logical roles within an OS
for the purpose of later identifying the activities allowed and not allowed by that role. Continuing
with the previous example, the accounting department user may be assigned to the Accounting
role within the OS.




                                                       3
The Available Tasks
Within an organization are also a number of tasks that must be accomplished in order to achieve
the goals of business. Mapping those tasks to the services available within the organization’s
computing environment illuminates a list of activities and applications. As examples, those
activities may relate to the ability to add printer drivers, change network settings, or customize a
user’s desktop. Within the realm of applications, tasks may be related to the ability to launch a
spreadsheet tool, connect to a database client, or make use of a customized line-of-business
application.
Each of these activities and applications is identified by the OS process that drives its
functionality (for example, winword.exe is the process that drives Microsoft Word). Some of
these tasks operate natively within the context of a standard user account with little or no added
privileges necessary for their functionality. These tasks are configured by default to use the least
privileges necessary for their processing. Others may require elevated access within the
computer system to complete their actions. When necessary, those specific and identified
processes are selectively granted the rights necessary to accomplish their mission.
Through this process of selectively granting privileges based on the need of the process, users
can be given the exact level of permissions needed to accomplish their roles as a function of their
needed activities and applications. Effectively, instead of applying privileges based on who the
person is, privileges are assigned based on what users need to do.

The Corporate Policy
The third segment of Least Privilege relates to the period of use for both the user and the
application. This period of use is determined by the goals and standards set by corporate policy.
This third segment is necessary as a business changes over time. With that evolution comes
changes in the practices and processes of business. For example, consider a user who spends the
majority of their time away from the office and in the field. They may require more
administrative access to their laptop because they are far removed from the assistance of the
local Help desk. Later on, the business may acquire new technology that enables the Help desk to
assist remote users, negating the need for them to retain administrative rights. With this change
comes the end of the need for the user’s elevated privileges on their identified computer.
Individual activities and applications have life cycles as well. Although the organization might
desire its workforce to have the elevated rights necessary to accomplish a system task today, the
organization may later determine that centralized control is more desirable. Version one of a
custom line-of-business application may require elevated privileges due to faults in its code
architecture, while version two overcomes these faults and no longer requires the elevated
privileges. In all of these cases, the period of use of the user and the application must be
controlled in order for Least Privilege to be most appropriately used.




                                                  4
Least Privilege Inhibits Inappropriate Behaviors
Throughout this definition of Least Privilege, the end result is in reducing or eliminating system
behaviors that are considered inappropriate by the business. Behaviors—whether invalid
software download and installation, the inappropriate changing of system settings, or the
unintended introduction of malware and other unwanted software onto computers— can be
eliminated or reduced through the application of Least Privilege.
The next article in this series will discuss these behaviors in depth through its discussion of the
business benefits of implementing Least Privilege. The third article will continue the discussion
by looking at limitations in the native solutions available today within the Windows OS. It will
explore feature sets that are necessary to ensure that the goals discussed in this article can be
accomplished with success.




                                                  5
Article 2: The Business Benefits of Eliminating Administrator
Rights
The first article one of this series engaged in an extended definition of the Principle of Least
Privilege. Starting with a very high-level look at privilege assignment, that discussion showed
how Least Privilege requires the lowest set of privileges possible to be assigned in order to
accomplish any particular task. It further requires that privileges assigned for the purposes of
accomplishing one task are not leveraged to perform another unauthorized task. Because of these
requirements, the granular assignment of privileges requires the combination of three parts: the
role a user has in the organization, the activities the user needs to accomplish, and the corporate
policies of that organization. Aggregating these three elements results in a list of the processes
and applications each user role is approved to accomplish.
The third article will discuss how these high-level ideals are manifested within the Windows
operating system (OS). But know for now that the end goal is for processes and activities within
the OS to be assigned elevated privileges only when those privileges are specifically required.
This process ensures that an individual user is not granted wholesale Administrator privileges for
the purposes of solving a single issue. A much better approach is in distributing privileges to
individual applications and processes based on the needed activities of the user.
The end result of this approach in a Microsoft Windows environment is the significant reduction
of Administrator privileges across the board. Users who were previously granted Administrator
rights to resolve the privilege needs of a single application can now have those rights removed.
IT administrators themselves can be more specifically granted the privileges they need to
manage the computing environment. The rights formerly assigned to every action of a specific
person are now more granularly assigned to the specific activities and applications that require
elevation.
Eliminating Administrator rights enables a set of benefits to the organization, which can be
broken into benefits related to operational improvements, security enhancements, and a greater
ability to fulfill compliance requirements. The business stands to gain from each related to this
right-sizing of security privileges.




                                                 6
Operational Benefits
The first set are those related to operational benefits. These benefits relate to improvements in
organizational workflow, the standardization of settings within the environment, and the ultimate
ability of IT and the business to get the job done:
   •   Standardized settings are assured. The Windows OS has thousands of potential settings
       that can be standardized using various techniques. This standardization of settings
       ensures that each desktop behaves in ways similar to others. It ensures greater uptime in
       the environment by ensuring that known-bad configurations are avoided, while those that
       enhance usability are enforced. The problem with standardization in environments with
       widespread Administrator rights is the ability for the local user to reconfigure the desktop
       at will. When individual users retain the ability to move away from standardized settings,
       this increases the complexity of the overall IT environment and reduces the ability of IT
       administrators to keep the environment up and operational.
   •   Users are prevented from installing unlicensed and unapproved applications. One of the
       capabilities given to users with Administrator rights is the ability to install new software.
       When a user is granted traditional Administrator rights, the user gains the ability to install
       any software to their computer without requiring the normal workflow steps usually
       required by IT. Although this setup means that the user can more quickly install the
       software they need, it also means that IT no longer fully owns the software inventory
       process. Inappropriate and/or unlicensed software can be installed to desktops without the
       knowledge of IT or the business. This can introduce the potential for data compromise in
       the case of known malware or can be a license violation in the case of legitimate
       software. Thus, granting Administrator privileges to users gives them the authority for the
       installation without the responsibility of security and proper licensing.
   •   More efficient use of hardware resources. Inappropriate software, especially software
       downloaded from illegitimate Web sites, adds a resource burden to business hardware.
       This resource burden is especially problematic in the case of malware code. By retaining
       control over which software is installed to desktops across the environment, IT ensures
       that available hardware is used with the best possible performance and the least possible
       downtime.
   •   Reduced cost of ownership for desktops. Related to the previous bullet point, the more
       time IT is required to spend with each individual desktop, the more costly that desktop is
       to maintain. The installation of inappropriate software along with the inappropriate
       reconfiguration of standardized settings often results in an increased rate of problems as
       well as an increased level of downtime for that desktop. By eliminating Administrator
       rights and ensuring greater standardization, IT will reduce the costs associated with
       maintaining each individual desktop.
   •   Fewer calls to the Service Desk. In the end, all of these benefits are associated with a
       reduction in the number of support calls to the Service Desk. When desktops can
       maintain a standardized configuration, users are more likely to accomplish their assigned
       tasks through their required applications and processes.




                                                  7
Security Benefits
Operational benefits are important to the business side of the IT organization. But the elimination
of Administrator rights also impacts the environment’s security posture. These benefits go far in
ensuring the safety and security of critical corporate data by preventing the installation of
malicious software and the configuration of known-insecure settings:
   •   Security configurations cannot be overwritten. Though many organizations may not
       engage in a high level of desktop customization for visual purposes, nearly all enforce
       configurations that are known to improve the security posture. These security settings
       relate to the automated installation of security patches, enabling and configuration of the
       firewall, and other desktop and application lockdowns that ensure the safety of the
       environment. As with those discussed in the previous section, virtually all of these
       settings grow suspect in environments in which local users with Administrator rights can
       disable them at will. By eliminating traditional person-based Administrator rights,
       organizations can ensure that users retain the ability to accomplish system tasks they
       require—networking changes, printing, and so on—while being prevented from adjusting
       settings related to system security.
   •   Malware infections are inhibited. Very little of a user’s daily processing requires the use
       of Administrator privileges. Yet when users run with Administrator privileges during
       their daily use, they unnecessarily expose themselves to the potential for malware
       infection. Such is particularly the case when users browse the Internet. When the
       browser’s process is launched without administrative privileges, it is very difficult for
       accidentally downloaded malware to infect the system. This is the case because making
       any changes to the protected areas of the Windows OS—those areas most desired by
       malware—requires administrative privileges. Thus, browsing the Internet with the
       lowest-possible set of privileges goes far in preventing most known forms of malware
       infection.
   •   Enhanced data protections. The user-initiated download and installation of malware is
       not the only mechanism by which computer systems can be compromised. When a user
       elsewhere in the network accidentally infects their computer with malware that is
       designed to replicate, its replication can be inhibited by ensuring it runs with the least
       possible privileges.




                                                 8
Compliance Benefits
In addition to the operational and security benefits, eliminating Administrator rights assists with
an organization’s ability to maintain industry and regulatory compliance. Virtually all
organizations fall under some form of regulation—the Sarbanes-Oxley Act (SOX) for
corporations, the Health Insurance Portability and Accountability Act (HIPAA) for medical
organizations, the Gramm-Leach-Bliley Act (GLBA) for banking institutions, the Federal
Desktop Core Configuration mandate for federal entities, and others. Though each regulation is
unique in the text of its requirements, all require some form of technical control that ensures the
safety and security of sensitive data in the environment.
Without going into the individual requirements of each regulation, the following benefits relate
to the fulfillment of the spirit of each. By controlling and effectively logging user and
administrator activities, the fulfillment of compliance regulation requirements can be assured:
   •   Logging of user activities can be assured. The native logging systems within the
       Windows OS suffer from the limitation that any administrative user can clear the logs at
       will. This limitation means that a user with administrative access can clear any record of
       their activities if desired. With the assurance of activity logging a primary requirement of
       virtually all compliance regulations, preventing log erasure is a key necessity for the
       secure and compliant IT environment.
   •   Data access can be protected. Virtually all corporate data must be accessed through some
       form of application. When the access to that application has been elevated through the
       assignment of Administrator privileges, the user may have the ability to leverage that
       access for other unauthorized purposes. Conversely, when granular privileges are
       assigned based on individual activities, the likelihood of data breech is reduced due to a
       reduction in the count of potential activities that can be accomplished by the user.
   •   The power of IT administrators can be limited based on their responsibilities. Lastly,
       with traditional privilege models, IT administrators must be given Administrator access if
       they are to have the rights necessary to do their jobs. This all-or-nothing approach to
       permissions enables rights for administrators that go above and beyond their individual
       needs. Using the Least Privilege mode, privileges assigned to administrators can be
       tailored specifically to only the activities required by the individual. This setup reduces
       the spread of Administrator access to IT administrators, and is a key technical control
       required by many compliance regulations.




                                                  9
Not Just for Enterprises
Though many of the benefits identified appear to relate to the enterprise large-scale organization,
they hold the same value to smaller businesses as well. In comparison with large-scale
organizations, which tend to have IT and security policies in place and a high level of process
maturity, smaller businesses are often forced to use an adhocracy model. Because of the “get the
job done” nature of small businesses, the potential tends to be higher for one-off system
configurations due to special needs. Because of the trends in this type of workflow, it can be
argued that the reduction of Administrator rights in smaller organizations is equally, if not more,
important to the security and operations of the environment. Eliminating traditional person-based
Administrator rights provides the same level of protection for small businesses as it does for
large, enterprise-scale organizations.




                                                 10
Article 3: Limitations in Native Solutions for Privilege
Management
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.




                                                  11
Runas
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:
   •   Additional steps are required. In order to launch the process under the alternate
       credentials, extra steps are still required. For non-technical users, these extra steps can be
       challenging, forcing them to remember the extra steps each and every time the alternate
       credentials are required to launch an application. Users must also be aware of which
       applications require administrative credentials and ensure that they elevate only the
       applications that need them.
   •   The user must manage separate credentials. There is an additional administrative
       overhead on the part of the user as well as IT in managing two separate sets of
       credentials. As examples, dual credentials include the typical processes of managing
       password changes and remembering passwords. IT must also manage the storage of
       double credentials for each user on the network, which adds a burden on their operational
       workflow.
   •   No enforcement. Leveraging the Runas tool is a purely client-based approach. Thus, no
       policy-based enforcement is present to ensure that users are correctly elevating approved
       applications and not using credentials for unapproved actions. The elevated credentials
       are also equivalent in capability to standard credentials. So there is no technical control in
       place to ensure that users don’t simply log in to the computer with the elevated
       credentials.
   •   Launched processes were created as a separate user. When processes and applications
       are launched using the alternate set of credentials, they are launched under a different
       user account entirely. This alternate account method does not work with some
       applications and often causes problems with the correct logging of user actions.
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.




                                                  12
User Account Control
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 UAC-
enabled 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.

   Due to this added level of security, administrators that operate under UAC’s controls are referred to
   as Protected Administrators.

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.




                                                    13
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:
   •   Complex. Much of UAC’s functionality lies “under the covers” of the desktop itself,
       making it difficult to truly understand. Although UAC in consumer environments works
       well for protecting individual users and their computers, understanding how to best use it
       in a managed, corporate environment requires specialized skills.
   •   Annoying prompts. Without a core understanding of UAC’s protections, non-technical
       users and IT generalists often see UAC and its prompting as an intrusion into their daily
       workflow. With many actions requiring administrative access, especially considering the
       reconfiguration of the Windows Vista and Windows Server 2008 file system, UAC
       prompts are seen relatively frequently. The ever-present barrage of elevation requests
       slows the ability of the privileged user to get their job done.
   •   Responsibility for elevation remains with the user. Because the decision whether to
       accept or reject an elevation request remains with the individual user, that user retains the
       ability to make the wrong decision. When users are not appropriately trained on how to
       use UAC and when to approve or reject elevation requests, they may out of frustration
       always choose to accept. This behavior ultimately reduces UAC’s effectiveness in
       protecting the computer against malicious code.
   •   Little or no centralized mechanisms for control, management, or logging. UAC is a
       purely client-based solution that includes no mechanism for the centralized logging of
       elevation requests. It also includes only a coarse capability for centralized management
       and tuning, having only ten configurations that can be controlled via local or Group
       Policy.
   •   Person-based credentials assignment. Last, and possibly most important, UAC’s
       implementation retains the person-based credentials assignment architecture discussed in
       the first article of this series. Administrative credentials are assigned to an individual and,
       once assigned, grant the individual what amounts to full control over the entire computer.
       Credentials with UAC cannot be granularly assigned to enable Administrator access to a
       specified activity or application. This limits its utility as a solution for enabling a Least
       Privilege environment.




                                                  14
Capabilities to Resolve Least Privilege
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:
   •   Granular privilege assignment. Considering the three separate elements that must
       aggregate to identify the individual, the element, and the period of use, solutions that
       support a more granular level of control are necessary. Solutions that support this
       granularity will be able to elevate administrator-assigned actions and applications based
       on a user and his or her role. Individual users and applications should have the ability to
       be enabled or disabled as needed by IT administrators. This granular level of control
       eliminates the need to assign entire-computer privileges for the resolution of point issues.
   •   Centralized control and policy-based assignment. With the move to granular control of
       elevation comes the need for centralized control over which applications, actions, and
       users can and should be elevated. Centralized control also includes centralized logging
       support that fulfills security and compliance needs. Policy-based assignment ensures that
       configured elevation settings at each client computer are enforced based on the policy
       applied to that computer. It also enables entire classes of users, computers, and
       applications to be managed as single units for enhanced management.
   •   Movement of elevation responsibility from individual users to IT. A chosen solution
       should remove the onus of responsibility for elevation completely from individual users.
       This movement of responsibility ensures that educated and trained IT personnel are
       making decisions about elevations based on corporate policy and security experience. It
       also eliminates the possibility that an uninformed user will automatically choose to
       elevate when any prompt appears.
   •   Right-sizing of notifications. Although UAC’s excess of prompting has led many
       administrators to desire a complete elimination of prompting, there may be situations
       where users require a minimal level of notification. This level of notification may be
       unobtrusive unless necessary for the protection of the OS.
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.




                                                   15