47,99 €
Least Privilege Security is the practice of assigning users and programs the minimum permissions required to complete a given task. Implementing this principle in different versions of Microsoft Windows requires careful planning and a good understanding of Windows security. While there are benefits in implementing Least Privilege Security on the desktop, there are many technical challenges that you will face when restricting privileges.This book contains detailed step-by-step instructions for implementing Least Privilege Security on the desktop for different versions of Windows and related management technologies. It will provide you with quick solutions for common technical challenges, Microsoft best practice advice, and techniques for managing Least Privilege on the desktop along with details on the impact of Least Privilege Security.The book begins by showing you how to apply Least Privilege Security to different categories of users. You will then prepare a desktop image with Least Privilege Security enabled from the start and deploy the new image while preserving users' files and settings. You will identify problems with applications caused by Least Privilege Security using the Application Compatibility Toolkit. This book will help you configure User Account Control on multiple computers using Group Policy and support Least Privilege user accounts using reliable remote access. Then, you will modify legacy applications for Least Privilege Security, achieving the best balance between compatibility and security by using Application Compatibility shims. You will install per-machine ActiveX Controls using the ActiveX Installer Service (AxIS). The book will help you implement best practices for working with ActiveX Controls in a managed environment. Finally, you will deploy default Software Restriction Policy (SRP) or AppLocker rules to ensure only programs installed in protected locations can run and blacklist applications using SRP or AppLocker.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 473
Veröffentlichungsjahr: 2010
Copyright © 2010 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: July 2010
Production Reference: 1290610
Published by Packt Publishing Ltd. 32 Lincoln Road Olton Birmingham, B27 6PA, UK.
ISBN 978-1-849680-04-2
www.packtpub.com
Cover Image by Tina Negus (<[email protected]>)
Author
Russell Smith
Reviewers
Alun Jones
Stephen Lamb B.Sc (Hons)
Marco Shaw
Acquisition Editor
James Lumsden
Development Editors
Kerry George
Reshma Sundaresan
Technical Editors
Vinodhan Nair
Gaurav Datar
Copy Editor
Sanchari Mukherjee
Editorial Team Leader
Gagandeep Singh
Project Team Leader
Priya Mukherji
Project Coordinator
Ashwin Shetty
Proofreader
Chris Smith
Indexer
Rekha Nair
Graphics
Geetanjali Sawant
Production Coordinator
Adline Swetha Jesuthas
Cover Work
Adline Swetha Jesuthas
Russell Smith specializes in management and security of Microsoft-based IT systems and is a Contributing Editor for CDW's Biztech magazine and writes regularly for industry journal Windows IT Professional. Russell is also contributing author to Supporting and Troubleshooting Applications on a Microsoft Windows Vista Client for Enterprise Support Technicians from Microsoft's Official Academic Course (MOAC) series of books published by Wiley and Sons.
An independent IT consultant and MCSE with more than ten years of experience, Russell's recent projects include Active Directory Security Consultant for the UK Health Service National Programme for Information Technology (NPfIT) and Exchange Architect for Wipro Technologies. Russell also has extensive experience as an IT trainer.
Alun Jones (MVP, MCP) is the President of Texas Imperial Software (http://www.wftpd.com). Texas Imperial Software develops secure networking software and provides security engineering consulting services. Texas Imperial Software's flagship product is WFTPD Pro, a secure FTP server for Windows, written entirely by Alun.
Alun entered the security field as more and more of WFTPD's support needs indicated that few companies were able to meet their needs for security on the Internet without help. His current day job is as a Security Engineer for an online retailer.
The Information Security-related blog, Tales from the Crypto (http://msmvps.com/blogs/alunj) carries Alun's occasional thoughts on the topic of Computer Security.
Alun has attended University at Corpus Christi College, Cambridge, and Bath University, and now lives near Seattle, Washington with his wife Debbie and son Colin, both of whom he now wishes to thank for their patience in allowing him to review this book.
Stephen Lamb has worked as an Information Security Professional for fifteen years, working with clients throughout Europe. Stephen is a firm believer that effective information security enables people and businesses to be more effective. He found from experience that a successful security strategy must encompass user awareness together with meaningful processes and procedures. During his career, Stephen has designed, developed, and implemented technical solutions to complex information security challenges. Stephen is fascinated by the challenges and opportunities social media bring to the security posture of organizations and individuals.
Marco Shaw is currently working as an independent contractor. He has been working in the IT industry for over 12 years. He was awarded the Microsoft Most Valuable Professional award for his contributions to the Windows PowerShell community in 2008, 2009, and again in 2010.
Marco spoke at TechMentor at San Francisco in 2008, where he provided two popular sessions on PowerShell. He also provided two popular sessions on Windows Server 2008 R2 and System Center Operations Manager 2007 at TechDays 2009 in Halifax, Canada.
His recent authoring activities have included writing PowerShell content for a Windows Server 2008 book by Microsoft Press, a PowerShell-related article on System Center Operations Manager 2007 for TechNet Magazine, providing PowerShell content for a SQL Server 2008 book by Sams, and also for a revised edition of System Center Operations Manager 2007 Unleashed by Sams. He has also co-authored the second edition of PowerShell Unleashed, published by Sams released early in 2009.
Marco has also been the technical reviewer for other books covering Microsoft technologies.
Blog: http://marcoshaw.blogspot.com
Twitter: http://twitter.com/marcoshaw
E-mail: <[email protected]>
Dedicated to St. Petersburg, Russia - where this book was written.
In this, the first book to be entirely dedicated to the subject of running Least Privilege Security (or standard user accounts) on Windows operating systems in the enterprise, you will learn about the benefits Least Privilege brings organizations in terms of not only security, but regulatory compliance, improved manageability, and operational simplicity. The book provides a complete guide to implementing Least Privilege Security on the desktop, with step-by-step instructions and advice about how to overcome the most common technical and political challenges.
Chapter 1, An Overview of Least Privilege Security in Microsoft Windows, explores the principle of Least Privilege Security and shows how to implement it in different versions of Microsoft Windows. It also explains how to control and change system privileges, benefit from implementing Least Privilege Security on the desktop, and overcome the most common technical and political problems and challenges when implementing Least Privilege Security.
Chapter 2, Political and Cultural Challenges for Least Privilege Security, covers the reasons why users may not accept Least Privilege Security on the desktop. It also clearly explains and justifies the benefits of Least Privilege Security for your organization. The chapter also covers how to apply Least Privilege Security to different categories of users and get buy-in from management.
Chapter 3 , Solving Least Privilege Problems with the Application Compatibility Toolkit, covers how to modify incompatible applications on the fly and achieve the best balance between compatibility and security by using Application Compatibility shims. It explains how to create shims using the Application Compatibility Toolkit 5.5 and distribute compatibility databases to devices across the enterprise.
Chapter 4, User Account Control, covers how to achieve a seamless user experience by using the different components and compatibility features of User Account Control. It also explains how to configure User Account Control on multiple computers using Group Policy and the inner workings of User Account Control's core components.
Chapter 5, Tools and Techniques for Solving Least Privilege Security Problems, covers how to set up a system for temporarily granting administrative privileges to standard users for support purposes. It also covers how to use Task Scheduler to run common processes without the need to elevate privileges and how to install third-party solutions to configure administrative privileges for applications and Windows processes on-the-fly.
Chapter 6, Software Distribution using Group Policy, explains how to prepare applications for Group Policy Software Installation (GPSI) and Windows Installer deployment. It also explains how to repackage legacy setup programs in Windows Installer .msi format and how to make GPSI more scalable and flexible using the Distributed File System (DFS). It covers how to target client computers using Windows Management Instrumentation (WMI) filters and Group Policy Scope of Management.
Chapter 7, Managing Internet Explorer Add-ons, covers how to support per-user and per-machine ActiveX controls and manage Internet Explorer add-ons via Group Policy. It also explains how to install per-machine ActiveX controls using the ActiveX Installer Service (AxIS) and how to implement best practices for working with ActiveX controls in a managed environment.
Chapter 8, Supporting Users Running with Least-Privilege, explains how to support Least-Privilege user accounts using reliable remote access solutions, how to connect to remote systems with administrative privileges using different techniques and enable remote access using Group Policy and Windows Firewall.
Chapter 9, Deploying Software Restriction Policies and AppLocker, explains how to deploy default Software Restriction Policy (SRP) or AppLocker rules to ensure only programs installed in protected locations can run. It discusses how to force an application to launch with standard user privileges even if the user is an administrator and how to blacklist an application using SRP or AppLocker.
Chapter 10, Least Privilege in Windows XP, covers how to redeploy Windows XP with Least Privilege Security configured and identify problems with applications caused by Least Privilege Security using the Microsoft Deployment Toolkit. It also explains how to mitigate the problems and limitations users may face when running with a Least Privilege Security account and how to handle ActiveX controls in Windows XP.
Chapter 11, Preparing Vista and Windows 7 for Least Privilege Security, explains how to collect and analyze data to identify any potential compatibility problems with Least Privilege Security and software installed on networked PCs using Microsoft's Application Compatibility Toolkit (ACT). The reader will learn how to analyze logon scripts for Least Privilege compatibility, how to prepare a desktop image with Least Privilege Security enabled from the start and deploy the new image while preserving users' files and settings.
Chapter 12, Provisioning Applications on Secure Desktops with Remote Desktop Services, explains how to install the core server roles for Remote Desktop Services in Windows Server 2008 R2 using Windows PowerShell. It also explains how to set up and understand Remote Desktop Licensing and configure Remote Desktop Gateway for secure remote access to applications over HTTPS. This chapter also discusses how to advertise published Remote Applications on Windows 7’s Start menu using Remote Desktop Web Access.
Chapter 13, Balancing Flexibility and Security with Application Virtualization, covers how to sequence an application for streaming and virtualization, and how to set up the App-V Client to work with a server-less deployment model.
Chapter 14, Deploying XP Mode VMs with MED-V, explains how to deploy legacy applications that are not compatible with newer versions of Windows and how to set up Windows XP Mode for Windows 7. It also explains how to configure the different components of MED-V for managing and deploying VMs in a large corporate environment and how to prepare VMs for use with MED-V.
The following software products are used in this book:
This book is for System Administrators or desktop support staff who want to implement Least Privilege Security on Windows systems.
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
Code words in text are shown as follows: "Now that we've got our machines configured with the WinRM service and listening on port 5985 (or port 80 for WinRM 1.1), we need to see if we can connect using the winrs command."
Any command-line input or output is written as follows:
New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this: "The Allow non-administrators to install drivers for these device setup classes setting under Computer Configuration | Policies | Administrative Templates | System | Driver Installation in Vista and Windows 7 Group Policy allows administrators to stipulate devices that can be installed by standard users according to the device GUID as specified in the driver".
Warnings or important notes appear in a box like this.
Tips and tricks appear like this.
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply send an e-mail to <[email protected]>, and mention the book title via the subject of your message.
If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or e-mail <[email protected]>.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/support, selecting your book, clicking on the let us know link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded on our website, or added to any list of existing errata, under the Errata section of that title. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
You can contact us at <[email protected]> if you are having a problem with any aspect of the book, and we will do our best to address it.
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:
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.
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.
The built-in administrator account is disabled out of the box in Vista and Windows 7, and UAC prompts are not triggered for this account by default. This behavior can be changed in Group Policy.
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.
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.
For an application to be awarded the Certified for Vista trademark, it must function properly 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:
The following output shows just three privileges:
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).
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.
