If you've ever been responsible for implementing IT system security in an organization, whether for servers or any other networked devices, you'll know what a tough job it can be. While upper management expects the IT department to keep the company's data safe from hackers and unauthorized access, users and middle management often have other ideas about what constitutes good security, preferring to circumvent security policy or have themselves exempted, without a valid business reason. Sometimes complaints about security are justified, due to poor design or execution.
Security is often bolted on to projects as an afterthought, rather than being an integral part of a design from the outset. Poorly implemented security makes you, the IT guy, unpopular. So, where security isn't an absolute necessity, it's regularly omitted for the sake of an easy life. To make matters worse, many IT professionals have a limited understanding of security, not knowing their ACLs (Access Control Lists) from their integrity levels, making it difficult for uninitiated staff to support a properly secured environment.
To minimize problems, personal firewalls are often disabled and users' rights are elevated. While such actions may be acceptable as part of the troubleshooting process, such configuration changes frequently remain permanent. If effectively managing security on servers and network devices causes enough problems with uncooperative coworkers who demand unrestricted access 24/7, then security on the desktop is not only likely to start a mutiny (if not well implemented), but it also comes with a unique set of technical challenges that are difficult to surmount, even for seasoned system administrators.
Least Privilege Security may sound like a complicated principle that only those with a degree in computer science can comprehend. But the reality is that anyone who has configured a basic firewall or router is likely to have encountered this most basic security principle, consciously or not, and that it has a natural place in desktop computing, just as in any other IT sphere.
In this chapter we will cover the following topics:
Exploring the principle of Least Privilege Security, and how it is implemented in different versions of Microsoft Windows.
Understanding how system privileges are used to control the aspects of an operating system's configuration that users can change.
Looking at the benefits of implementing Least Privilege Security on the desktop.
Examining how to overcome the most common technical and political problems and challenges while implementing Least Privilege Security.
Each user that logs in to NT-based versions of Microsoft Windows, does so with a set of system privileges. Privileges differ from permissions in that they give users the ability to perform an action, whereas permissions allow access to an object such as a file or registry key. There are many privileges used to control access to various system functions, ranging from the ability to change the system time to restoring files and directories. Rather than assigning each user account with privileges individually, a set of built-in groups are provided with pre-assigned privileges. Users are then added to groups, in a form of role-based access control, as the following table describing built-in groups in Windows 7 illustrates:
|
Group |
Description |
|---|---|
|
Administrators |
Administrators have almost complete and unrestricted access to the computer domain. |
|
Guests |
Guests have the same access as members of the Users group by default, except that the Guest account is further restricted. |
|
Network Configuration Operators |
Members in this group have some administrative privileges to manage configuration of networking features. |
|
Power Users |
Power Users is included for backwards compatibility, but has been deprecated and has no administrative privileges. |
|
Remote Desktop Users |
Members in this group are granted the right to log on remotely. |
|
Users |
Users are prevented from making accidental or intentional system-wide changes and can run most applications. |
The two most frequently used built-in groups are Users and Administrators. If your user account is assigned to the Administrators group, you have a high level of privilege on the system and can perform almost any task that isn't specially protected by the operating system.
Note
While members of the administrators group in Windows aren't completely unrestricted, it is possible to override operating system protections and make any desired changes.
In contrast, if your user account is assigned to the Users Group, you can run installed programs and change settings that won't affect system stability, but you can't install software to the restricted Program Files directory, or modify protected areas of the registry or Windows directory. The Power Users group was often used in Windows NT, 2000, and XP, but was essentially an administrator with a few less privileges. Microsoft decided to deprecate this group in Windows Vista, preferring system administrators to assign users to either the users or administrators group, as it was easy for power users to escalate to administrative privilege. You should, however, note that the Power Users group still exists in Vista and Windows 7 for compatibility reasons, but isn't assigned any privileges.
Each user that logs in to NT-based versions of Microsoft Windows, does so with a set of system privileges. Privileges differ from permissions in that they give users the ability to perform an action, whereas permissions allow access to an object such as a file or registry key. There are many privileges used to control access to various system functions, ranging from the ability to change the system time to restoring files and directories. Rather than assigning each user account with privileges individually, a set of built-in groups are provided with pre-assigned privileges. Users are then added to groups, in a form of role-based access control, as the following table describing built-in groups in Windows 7 illustrates:
|
Group |
Description |
|---|---|
|
Administrators |
Administrators have almost complete and unrestricted access to the computer domain. |
|
Guests |
Guests have the same access as members of the Users group by default, except that the Guest account is further restricted. |
|
Network Configuration Operators |
Members in this group have some administrative privileges to manage configuration of networking features. |
|
Power Users |
Power Users is included for backwards compatibility, but has been deprecated and has no administrative privileges. |
|
Remote Desktop Users |
Members in this group are granted the right to log on remotely. |
|
Users |
Users are prevented from making accidental or intentional system-wide changes and can run most applications. |
The two most frequently used built-in groups are Users and Administrators. If your user account is assigned to the Administrators group, you have a high level of privilege on the system and can perform almost any task that isn't specially protected by the operating system.
Note
While members of the administrators group in Windows aren't completely unrestricted, it is possible to override operating system protections and make any desired changes.
In contrast, if your user account is assigned to the Users Group, you can run installed programs and change settings that won't affect system stability, but you can't install software to the restricted Program Files directory, or modify protected areas of the registry or Windows directory. The Power Users group was often used in Windows NT, 2000, and XP, but was essentially an administrator with a few less privileges. Microsoft decided to deprecate this group in Windows Vista, preferring system administrators to assign users to either the users or administrators group, as it was easy for power users to escalate to administrative privilege. You should, however, note that the Power Users group still exists in Vista and Windows 7 for compatibility reasons, but isn't assigned any privileges.
Least Privilege Security is the practice of assigning users and programs the minimum permissions required to complete a given task. For example, if your daily duties include checking e-mail, surfing the Internet, and running a human resources application, then your user account should not be granted administrator privileges on your desktop. None of these tasks warrant anything more than standard user privileges. A standard user does not have any administrative access to the local system, and as such is not able to change critical settings that might affect system stability, security, or other users on the same machine. While this is a simplification, as it's likely that less privileges are required to run these applications than those granted to a standard user, it becomes impractical to study the privileges required for each and every operation that a user might carry out. Today, Least Privilege Security is most often referred to when discussing the protection of systems, rather than information in computer systems. As we enter an age when regulatory compliance and protection of information becomes more prevalent, it's interesting to note that Least Privilege Security is just as much about protecting information as it is about protecting the system—both go hand in hand. Programs generally run with the same set of privileges that are granted to the user. So, if you accidently launch a piece of malware from the Internet while you are logged in with administrator privileges, the malware has the ability to make the same changes and access the same information as your high-privileged administrator account.
Note
Most current malware relies on users having administrative privileges to install. If more users run with non-admin accounts, the situation is likely to change. Least Privilege Security should be further secured with the use of antivirus software and other protection technologies, such as Software Restriction Policy and AppLocker.
Considering the threat landscape has changed beyond recognition in recent years, users will often counter least privilege accounts, insisting that I'll be careful or I know what I'm doing. When users undertake risky activities such as browsing the Internet (computer expert or not), it's impossible to be sure that malevolent software won't be accidently launched through malicious code embedded in web pages, which is intended to launch silently without the user's knowledge, or exploit an unpatched vulnerability in the operating system. While antivirus software can provide a certain degree of protection, many exploits cannot be detected by even the best antivirus programs. A defense-in-depth strategy that includes both antivirus and Least Privilege Security, among other measures, is far more effective than any one protection mechanism alone. Users often have blind faith in antivirus, software believing it will protect them from all evil. Browsing the Internet is just one example of a risky activity. Malware can find its way into systems through removable media, CDs, and e-mail, and then propagate throughout a network, causing untold amounts of damage and lost productivity.
A word processor is unlikely to need privileged access to a system. If we limit the level of privilege that an application has to a system, so users can perform only the tasks required to complete the job, then maintaining systems becomes much easier. Privileges can be assigned to user accounts through the built-in administrators and users groups in Windows NT, providing system administrators with an easy way to restrict privileges for the majority of users. While this doesn't necessarily achieve true Least Privilege Security—for example, why would a word processing application need to change a system's power scheme—it is a reasonable trade-off between security, manageability, and usability in most production environments.
In 1993, Windows NT 3.1, which was designed for business use, introduced the NTFS filesystem and centralized security. Despite that, 9.x consumer editions of Windows existed in parallel with NT for some time, and the concept of securable objects was never introduced into the 9.x line. Starting with Windows XP, the distinction between consumer and business versions of Windows disappeared, at least from a technology point of view, as Windows XP was based on Windows 2000 and replaced Windows ME for home users.
The FAT/FAT32 (File Allocation Table) filesystem used in 9.x editions of Windows didn't support the use of access control lists. Therefore, there were no strict means of controlling access to specified files and registry keys for a set of defined users. All users were effectively administrators. There were some methods for controlling what users could do, but it was far from what was available in more sophisticated operating systems of the time.
Ease of use has always been one of Windows strong selling points, and the wide choice of applications has helped it become the most prevalent OS on the desktop.
Windows NT, which spawned Windows 2000, XP, Vista, and Windows 7 has many fundamental differences from DOS-based Windows. However, the most important point in this discussion is its use of NTFS—a filesystem that is considerably more reliable and flexible than FAT and supports the concept of access control. This provides NT-based systems with a foundation that can be secured and protected according to a user's role. Along with other features such as a stable kernel, the ability to assign users with system privileges, and computers with system policy, NT provided the stability and security features required from a true business-grade operating system.
NT had no built-in equivalent to the switch user (su) command in Unix, so it was common that all users would be assigned to the administrators group on any one system, or at a minimum power users, which was essentially the same as administrators with a few less privileges. This started the trend on Windows NT, despite a sound security model being in place, for all users to run with administrative privileges. The future merger of the NT line and DOS-based 9.x versions of Windows ensured that the practice of running with administrative privileges would be entrenched for years to come.
An unfortunate side effect was that application developers commonly ran with administrative privileges, meaning that their applications would not run correctly under a standard user account. Even to this day, there is much debate about secure application development and resistance from developers who refuse to work without administrative privileges.
Though the Windows NT 4 Resource Kit did include a tool called SU (Switch User,) similar to the Unix command-line tool, it was a separate product. Windows 2000 introduced for the first time a built-in command called runas that allows users to run an application under the context of a different user account without logging off. The runas command is an equivalent of the Unix su command and is facilitated through the secondary logon service. This new command-line tool and service were intended for administrators, in the hope that they would use a standard user account for everyday use, and elevate applications only when administrative access was required. It suffices to say that this never caught on. One of the biggest annoyances of runas is that it can't be used to launch Explorer or certain control panel applets, without using messy workarounds.
runas isn't limited to administrators, but for daily use its implementation is simply too clumsy and wouldn't gain user acceptance in most environments. Another major drawback of runas is that if a standard user needs to run an application under the context of another account, then all the access rights the standard user has to the network and local filesystem are lost if not shared with the elevated user. runas is best used in contexts where a standard user will elevate using an account that has access to all necessary resources, for example, when a sysadmin elevates from their standard user account to Domain administrator.
In Windows Vista and Server 2008, network drives mapped in one security context are not visible to processes running under a different account in the same logon session, regardless of the permissions assigned to the network drive. This behavior can, however, be changed by adding a REG_DWORD entry to the registry called EnableLinkedConnections, with a value of 1 under HKLM\Software\Microsoft\Windows\CurrrentVersion\Policies\System and rebooting the system. runas has several command-line options, known as switches, which can be used to change the way elevated programs are launched. The /netonly switch allows users to retain access to resources on the local machine as specified by their primary account, but gives permission to networked resources according to the privileges of the account specified in the runas command. This can be useful for certain tasks where local administrative access is not required. Other switches such as /noprofile and /env allow users to control whether their own user profile or environmental variables will be used. While runas from the command line is likely the most convenient way for system administrators to use the full array of features, holding Shift while right-clicking on an executable file presents runas in the context menu.
If Windows 2000 was designed for business, then XP was a revolution for home users, finally merging the 9.x and NT range, thereby providing everyone with the security and stability of the NT kernel. This wasn't without its challenges, and to address problems with applications that weren't designed to run on NT, Microsoft created the Application Compatibility Toolkit (ACT). ACT allows businesses to scan their networks, creating an inventory database of installed applications. Programs can then be tested, and if necessary, any problems resolved with the use of application compatibility shims (fixes). ACT comes with a series of predefined shims, several of which can be used to solve problems with applications that weren't designed to run as a standard user.
XP also includes new Group Policy settings called Software Restriction Policy (SRP). While not intended to directly address Least Privilege Security problems, SRP does allow system administrators to dictate that given applications must run as a standard user. This is useful where users have to run with administrative privileges, but you want to restrict applications, such as Internet Explorer, to standard user privileges, minimizing the risk if users surf websites that host malware or browser exploits.
While it has always been, in theory, possible for corporate users to run as a standard user on NT-based operating systems, it was always difficult and unrealistic for home users, largely because Windows wasn't designed with this in mind. Ease of use always prevailed over security.
For the first time, Microsoft tried to go some way to change this situation with the introduction of User Account Control (UAC) in Vista. Much derided and misunderstood, UAC is a collection of technologies designed to make it easier for users to run with Least Privilege Security and to persuade developers to design applications that work without administrative privileges. Before Windows Vista, many routine tasks required elevation of privilege. User Account Control addresses this problem by changing system privileges to allow standard users to change the time zone, power schemes, and other previously restricted settings. User Account Control includes file and registry virtualization that transparently diverts write operations for protected areas of the filesystem and registry to the user's profile, allowing applications that don't comply with the Windows security model to function correctly without any modification.
Finally, and most controversially, UAC prompts users before they're allowed to make any changes to the system that require administrative privileges. This behavior can be configured in several different ways depending on the organization's requirements. UAC have been criticized for being too ubiquitous, thereby increasing the chances that users will simply agree to elevation without considering the risks. Despite Microsoft's efforts to make it easier to run as a standard user, by default, the first account in Vista is an administrator, albeit protected by UAC. If users opt to create additional accounts, they are prompted to assign standard user privileges, though this is not mandatory.
Descriptions of UAC from Microsoft have been somewhat contradictory. One of UAC's original design goals was to make it a security boundary, providing a sandbox where privilege cannot be elevated without the user's explicit consent. However, after Vista's release Microsoft acknowledged that it was a security feature, and not a boundary when running in Admin Approval Mode, implying that it could be compromised and wasn't designed to be impenetrable.
Using least privilege concepts, Microsoft has tightened the security of system services. To reduce the attack surface, Vista's system services run with a minimum set of privileges. The service control (sc) command-line tool lets system administrators query and change the system privileges assigned to services. The following example shows how to use the command to determine what privileges are granted to the Remote Procedure Call (RPC) service:
sc qprivs rpcss
The following output shows just three privileges:
[SC] QueryServiceConfig2 SUCCESS SERVICE_NAME: rpcSs PRIVILEGES : SeChangeNotifyPrivilege : SeCreateGlobalPrivilege : SeImpersonatePrivilege
Microsoft has attempted to improve UAC in Windows 7 by making it quieter and more configurable. While there is no doubt that UAC is more configurable in Windows 7, it is for you to decide whether or not it is improved. The default user in Windows 7 is still a Protected Administrator, but the UAC settings are not as stringent as those in Vista. Windows 7 provides users with a less annoying experience, but with the prospect that their systems could be silently compromised. When designing UAC for Windows 7, Microsoft endeavored to strike the right balance between usability and security. Windows 7 gives users more control over UAC behavior, and the new features can also be configured in Group Policy.
Professional, Enterprise, and Ultimate SKUs of Windows 7 include XPM (XP Mode), which is intended to help smaller businesses migrate to Windows 7, while alleviating application compatibility concerns. It includes a license to run a virtualized instance of Windows XP and a new version of Virtual PC, which can integrate applications running inside a virtual machine with the Windows 7 desktop—blurring the line between installed and virtualized programs. Microsoft provides a managed version of XPM for larger organizations called Microsoft Enterprise Desktop Virtualization (MED-V).
Note
Least Privilege Security in Unix-based operating systems
In Unix-based operating systems it is common to log in with a restricted set of privileges for everyday use, and to switch to a different user account with administrative privileges, when required. Traditionally, Unix offered an all-or-nothing approach to privilege assignment. Accounts either had administrator or standard user privileges. This model has been supplemented in modern distributions with the ability to assign privileges in a more granular fashion.
Most operating systems, including Windows NT, use advanced Least Privilege Security concepts as follows:
Discretionary Access Control (DAC) is where system administrators assign access to a set of objects, such as a directory of files, and allow the user to change the security properties of those files. The user becomes the owner of the directory and can modify the security properties of all files within that directory.
Mandatory Access Control (MAC) allows system administrators to centrally control the changes users can make to objects they own. MAC helps prevent the flow of sensitive information from a high-privileged account to a lower one.
Windows Vista introduced a form of MAC through Mandatory Integrity Control (MIC) that prevents processes running with a low Integrity Level (IL) from writing to or deleting objects with a higher IL.
Windows Server 2003 included Role-based Access Control (RBAC) that allows system administrators to control access, based on users' organizational roles. Focusing on users' roles rather than objects and resources, as with DAC, is a more natural way for system administrators to control access to data across an organization. DAC enforces basic least privilege concepts to protect operating system files and registry keys using groups, which are collections of users, whereas RBAC roles are collections of permissions.
As servers are usually considered crucial to an organization, operators are often granted limited privileges to perform a restricted set of duties. A common example of this is management of backups in remote offices. Employees responsible for backup may have limited IT knowledge, but they need to change tapes and log on to the server to check for running backup jobs. It's preferable not to assign unqualified personnel administrative privileges on a server and create an additional significant risk.
In the same way that a firewall is supplied with all inbound ports blocked (requiring an admin to specifically open individual ports for Internet traffic to traverse one of the firewall's network interfaces to the corporate intranet) modern operating systems elevate privilege only when necessary. The firewall system of all ports closed, by default where the factory configuration prevents network traffic flowing from an untrusted to trusted network, also makes the device simple to configure. Issuing a command to open one or two ports is easier than trying to shut off hundreds of ports, leaving just a few open.
Least Privilege Security is often applied to servers as a matter of course, but the idea of desktop security is regularly limited to the concept of antivirus software and possibly a personal firewall. The benefits that least privilege brings to servers also apply to desktops.
Though considered a security principle, the biggest benefit of Least Privilege Security is that it aids change and configuration management. Every time you log in to a computer with administrative privileges, there's the potential that the system's configuration may undergo unsanctioned changes, knowingly or otherwise. Least privilege helps to maintain the intended configuration of a system, but at the same time giving the flexibility to change it (if permitted by corporate policy enables System Administrators to maintain) and manage who can change what. Least Privilege Security enables system administrators maintain better standardized environments and reduce support costs. If the helpdesk can be reasonably certain of a system's configuration, it's much easier to support that system. If users are allowed to change important configuration settings without a good reason, the help desk faces a much tougher job, increasing the time required to resolve problems, thus driving up costs.
Least Privilege Security also prevents users from circumventing controls implemented by system administrators. If a user has administrative privileges, with the right knowledge, it's possible to circumvent Group Policy. Ultimately, if a user has administrative privileges, there's likely a way to break into a system even if other controls are in force.
Good change and configuration management provides stability. How often are support staff faced with queries such as it was working ok yesterday? Computers don't stop working without a reason. Something must have changed. If system administrators can prevent unwanted change, these types of queries can be reduced. Wouldn't it be nice to know that every time a user switches on their system, they can be sure that it will work as expected?
If users are prevented from making unintentional changes to critical system components on the desktop, the risk of malicious or unsanctioned software finding its way onto corporate systems is significantly reduced. The likelihood of users being infected with drive-by internet attacks, rootkits, or worms is minimized as users need to specifically give permission for such software to run. A large number of today's malicious programs require administrative privileges to install. Therefore, a standard user is far less likely to infect a machine accidentally. Even if a standard user account becomes infected with a virus, the damage it can do is considerably less than if they had been granted administrative privileges.
You may be thinking that there are ways around some of the protections that Least Privilege Security provides, and you would be right. However, it must be understood that Least Privilege Security should be used as one layer of a comprehensive defense-in-depth strategy, and that other technologies such as Software Restriction Policies, Windows Firewall, and antivirus software, should be deployed to provide complete protection.
Many organizations are subject to regulatory compliance, and all such regulations require that users are given only the privileges required to complete their work. Even if your business is not subject to regulation, it should be considered best practice to implement Least Privilege Security, to boost customer trust. Sensitive data is easily stolen from users if layered protection is not in place. If keylogging software is silently installed on a user's machine, then the program may be able to transmit captured data to its author without the user's knowledge. A comprehensive defense-in-depth security strategy would be almost certain to prevent such an attack.
Least Privilege Security can also help organizations to manage software licensing. While it doesn't necessarily remove the need to audit programs installed across an enterprise, enforcing a standard image using least privilege reduces the chances that your business will fall out of compliance through unauthorized or unlicensed applications being installed on desktops.
Least Privilege Security shouldn't be viewed as a panacea for all security-related problems. It's perfectly possible that malware could install itself by exploiting an unpatched security vulnerability, which might have otherwise required administrative privileges to install. Freely available software on the Internet is often packaged in portable or a per-user form, which usually indicates that it can be installed without administrative privileges. Consequently, Least Privilege Security alone cannot prevent all unauthorized software appearing on your network, and should be used in conjunction with Software Restriction Policy. Least Privilege Security does a good job of protecting critical system components and configuration, but a virus could still infect a fully patched system. The damage would likely be limited to an individual user's profile, leaving the underlying system untouched. This damage limitation mechanism, provided by Least Privilege Security, makes any virus outbreak on your network less serious and easier to clean up.
The biggest reason to avoid least privilege on the desktop is that striking a balance between usability and security is much harder on a desktop than on a server. However, technologies do exist to help implement least privilege successfully on the desktop.
The single biggest roadblock in running as a standard user is application compatibility. Windows developers have become used to logging in to their machines with administrative privileges. This inevitably results in software that requires administrative privileges to work correctly. One of Microsoft's goals with User Account Control is to try to change this practice, and force programmers into developing software as a standard user. Application compatibility problems with Least Privilege Security range from programs failing to launch, to not retaining user settings. Error messages appearing at inopportune moments, inconveniencing users, and making it appear that the application wasn't designed to run on the system where it's installed are a result of bad practice on the part of developers. Frequent UAC prompts in Vista led many users to think that the problem was with UAC rather than due to a poorly coded application.
Earlier versions of Intuit's QuickBooks software for small businesses were probably the most well-known Least Privilege Security compatibility offenders. Until recently, it was a requirement for users of QuickBooks to be a member of the administrators, or pre-Vista power users group, forcing many businesses to risk the integrity of their systems by allowing users to run with administrative privileges. Fortunately today, most commonly used off-the-shelf enterprise applications will run with least privilege user accounts. For legacy applications and other programs that are still incompatible with Least Privilege Security, there are many technologies that can be used to solve compatibility problems, such as virtualization techniques and compatibility shims, which will be covered in the second half of this book.
Security is always a trade-off against usability, and least privilege is no exception. Implementing Least Privilege Security prior to Windows Vista involved a lot of work, and most system administrators simply didn't have the time, resources, or management backing to make it work in such a way that it would be accepted by end users. That's not to say that it's impossible to implement Least Privilege Security in Windows XP, but it does require time and testing on your part. There are many common settings that users can't change as a standard user in Windows XP. User Account Control has addressed most of these issues in Vista and Windows 7.
Let's take a look at the issue of changing a system's time zone, date, or time. As a standard user in Windows XP, you cannot change any of these settings. Changing the date and time is protected because Kerberos, the standard network authentication protocol in Windows 2000 and later, relies on date and time synchronization for successful authentication with a domain controller. If a system's date and time doesn't fall within close range of the domain controller, the user will not be able to log in. Hackers can manipulate the date and time to cover their tracks and as such this provides another reason to restrict access to these settings. For non-domain computers, Windows synchronizes the time and date with an Internet time server, so standard users don't require access to modify time and date settings.
Time zone is another matter as it simply changes the way the time is displayed to users, not affecting their ability to log in if the time zone is different to the server's. Prior to Windows Vista, standard users were not able to change the time zone, causing much frustration for notebook users. It may not seem such a big deal to most system administrators, but users are not likely to accept that they can't change the time zone on their notebook if they travel a lot, deeming it as a problem with their system. The time zone is just one example of a problem you will encounter when implementing Least Privilege Security in Windows XP.
In spite of it being considered a routine task by most users, standard users cannot burn data to a CD or DVD in Windows XP. As you can see, removing administrative privileges in Windows XP is likely to create problems very quickly if the change is not carefully planned.
Though Least Privilege Security makes it harder for users to break their systems, it also makes it more difficult for users to fix problems or make necessary changes without involving the help desk. This may not be a problem for desktops that are located in an office with easy access to IT support, but for remote workers without administrative privileges, should a serious problem occur, there could be a long wait before a solution is implemented. Help desks often rely on remote workers to change important system settings to fix serious problems. This is somewhat of a catch-22 situation, as it's likely that if a user doesn't have administrative privileges, those important settings can't be modified and the system will work reliably, but should something need to be changed, the user has to call the help desk.
It's commonplace for system administrators to rely on remote workers, who rarely visit the office, to install operating system updates and third-party software patches, which requires administrative privileges. Issues also arise when users want to install hardware. If a suitable driver isn't already available on the system, a standard user cannot add a new device driver. Many smaller businesses don't require users to adhere to a list of supported hardware, further exacerbating the problem. There are certain categories of employees, such as engineers and sales representatives, who may need to install or update software on a regular basis.
Even in a large organization, it may not be possible to deliver all such software automatically from a central distribution point. Help desks are not used to supporting Least Privilege Security as it's not the standard configuration in older versions of Windows. Along with many Windows professionals, first-level support and help desks often have little understanding of the Windows security model. To support Least Privilege Security, system administrators and help desks need to have a good understanding of basic security principles such as the Windows security model, User Account Control, and how to solve common problems related to Least Privilege Security. So, before implementing Least Privilege Security in your enterprise, you need to consider training costs for support staff.
While my own experience shows that in most cases implementing Least Privilege Security on the desktop is more than worth the effort, I'm not expecting you to take my word for it that least privilege is going to make a big difference to your organization's bottom line. Fortunately, there is independent evidence pointing to the fact that Least Privilege Security does make a difference.
Measuring the productivity of an information worker is much harder than for a traditional blue-collar worker. System performance and reliability plays only a small part in what constitutes user productivity, with usability, familiarity, and transactional efficiency also playing a role. While there is plenty of anecdotal evidence supporting the benefits of Least Privilege Security, getting hard figures is difficult. The best way to persuade management to adopt a desktop least privilege project in your organization is to conduct your own trials with a small but varied group of users, and compare variables such as the quantity of help desk tickets raised, user satisfaction, and productivity comparisons before and after least privilege is trialed. Running these tests will also give you some insight into the technical problems that will be specific to your organization. You should also set an example and run as a standard user, elevating to an administrative account only when necessary, to demonstrate to the users and management that least privilege is a feasible solution for everyone.
Without least privilege on the desktop, it's impossible to truly reap the benefits of a centrally managed infrastructure. Research by IDC covering 141 enterprises with 1,000 to 20,000 users shows that central management can save up to $190 per PC a year. Small businesses without a managed infrastructure benefit from improvements in Vista and User Account Control. While not all of Vista's security features can be emulated in XP, larger organizations can configure XP to run accounts as a standard user, and reap the benefits of Least Privilege Security.
A study carried out by eWEEK before the release of Windows Vista showed that organizations that deployed least privilege for users on Windows 2000 and XP experienced a significant decrease in the number of successful security exploits. Vista was developed using the Secure Development Lifecycle (SDL) and with new features, such as UAC and service hardening, it is more secure than Windows XP. Microsoft's Security Intelligence Report for July to December 2008 (SiRv6) shows that malware infected Vista SP1 roughly 60 percent less than XP SP3. Changes in Vista make it more difficult to compromise the operating system and Internet Explorer. SiRv6 shows that Microsoft software was targeted 35 percent less in Vista than XP. This isn't without its downside, as attention has moved to exploiting third-party software. Research by BeyondTrust, a company that produces software to help enterprises eliminate administrative privileges, shows that running as a standard user mitigates 92 percent of known security vulnerabilities on Windows systems.
We should now have a full understanding of the principle of Least Privilege Security and its implementation in Windows, from the early days of no real security in consumer editions of the operation system to today's push towards Least Privilege Security in Windows 7. Before proceeding to the next chapter, we have:
Understood how system privileges are used to control the aspects of an operating system's configuration that users can change
Familiarized ourselves with the principle of Least Privilege Security, and how it is implemented in different versions of Microsoft Windows
Become aware of the technical advantages and disadvantages that Least Privilege Security brings to desktop computing
Understood the business benefits of Least Privilege Security on the desktop
In the next chapter, we will move on temporarily from the technical aspects of implementing Least Privilege Security on the desktop, to talk about the cultural and political challenges, which for many can be harder to overcome.
