In spy novels, secret agents often operate on a need-to-know basis, in which each agent is told only what he or she must know to fulfill his or her individual mission. Restricting the amount of information granted to each agent helps protect the overall operation. The IT equivalent of this model is the concept of least privilege, in which each user account is granted only the privileges required to fulfill that user's role and responsibilities. Least privilege helps limit the damage that can result from the spread of malware, user mistakes, or abuse by disgruntled employees or malicious intruders. To put the concept into practice, you need to determine which privileges various roles require, create groups to manage those roles, then apply the concept to groups, services—and administrators.
Use Auditing
The first step in implementing least privilege is identifying each user's roles and responsibilities so that you can then determine the minimum set of user rights and permissions necessary. When you then begin to set up formal role-based authority on a system, you'll likely encounter the situation in which a user account obviously lacks an essential right or permission, but because of uninformative error messages and poor documentation, you can't figure out exactly what that right or permission is. In such situations, the Windows Security log is invaluable.
Open the Microsoft Management Console (MMC) Group Policy snap-in and drill down to Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policies. Enable Window's nine audit policies for failed events. When the computer next applies Group Policy, it will begin recording failure events in the Security log. Note, however, that Audit object access events and Audit directory service access events also require you to enable auditing of failed events on the objects you want to monitor—for example, system volumes, Active Directory (AD), and registry keys.
To enable auditing on a volume such as the C drive, open the drive's Properties dialog box in Windows Explorer, go to the Security tab, click Advanced to display the Advanced Security Settings dialog box, then go to the Auditing tab. Add an entry that audits Failed Full Control events for the Everyone object. To enable auditing of AD, open the MMC Active Directory Users and Computers snap-in and drill down to the domain root, open its Properties dialog box, and follow the same steps as for enabling auditing on a system volume. To enable auditing on the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER registry keys, open regedit, right-click each key, select Permissions, then follow the same steps as for system volumes and AD. Only audit Failed events for these objects, or you might overload the system as it tries to log every attempt to access every object.
The system might need several minutes to update auditing on large structures such as the C drive, domain, and registry, but once the audit policy is configured, failure auditing will help you diagnose authority problems. If a slowdown does occur on the audited system, simply disable Audit object access events and Audit directory service access events at the system level. For more information about auditing, see "Windows 2003 Security Log," March 2005, InstantDoc ID 45269; "Keeping Tabs on Object Access," June 2001, InstantDoc ID 20563; and "Auditing Windows 2000," July 2000, InstantDoc ID 9633. For more information about role-based security, see "Role-Based Access Control," June 2003, InstantDoc ID 38775, and "Tips for Tightening User Account Security," March 2005, InstantDoc ID 45209.
Create Groups
After you have an idea of the permissions that various user roles require, the next step is to create groups for those roles. Using groups that correspond to job roles and granting permissions to those groups (rather than to user accounts) is a key way to leverage least privilege, minimize the work involved in setting it up, and keep your security configuration maintainable.
In small-to-midsized business (SMB) networks, for example, one of the most important uses of least privilege is on the file server. Rarely does everyone need access to every folder on this server, yet in many environments such broad access is exactly what you find. Instead of granting Everyone Full Control on your file server's shares, identify important financial, HR, and proprietary information, then design your folder hierarchy so that such information resides in discreet subfolder branches. Create groups for each resource and level of access (e.g., Read Only, Read & Modify) and grant permissions accordingly. For more information about effectively controlling user access, see "Effective Access Control for Win2K and NT," October 2000, InstantDoc ID 15482.
Don't Forget Services
Least privilege also applies to service and application accounts. Just as users can be tricked into running malware or performing actions on behalf of an attacker, programs can be tricked, through buffer overflows or other attacks that cause the program to execute arbitrary instructions from an attacker. Developers' efforts to write secure code and your efforts to keep security patches up-to-date are initial defenses against such attacks, but allowing least privilege when assigning rights and permissions to the application or service account provides a second line of defense.
To view or configure the account under which a service runs, open the MMC Services snap-in, open the service's Properties dialog box, and go to the Log On tab, which Figure 1 shows. Too often, services run under the System or Administrator accounts. Few applications require such broad access. A service running with such authority can let an attacker do much more harm than one limited to the authority it truly needs. Many times, these privileged accounts are the default for applications because software developers fail to identify the minimum necessary authority and take the easy way out by simply requiring that applications run with administrative authority.
Fortunately, many developers are becoming more security conscious. In Windows Server 2003, Microsoft introduced two new built-in accounts—Local Service and Network Service—that services can use. Both accounts (aka security principals) run with much less authority than the all-powerful System account. For more information about these principals see "Access Denied: Understanding the Local Service and Network Service Accounts," page 16.
Limit Administrative Authority
The use of least privilege is also crucial for reducing the risks of administrative authority. The concept of a
completely trusted, all-powerful administrator is deeply embedded in the architecture of today's commercial OSs (i.e., Linux, Windows, and UNIX). There's no simple way to implement preventive or detective controls on administrators because these OSs don't support concepts such as dual-authorization or separation of duties. Using only native functionality and a single system, you can't even reliably monitor administrators because they can clear or otherwise tamper with the Security log. To reliably monitor administrative activity on a system, you need to implement a separate monitoring server over which the monitored administrators have no control. For Linux or UNIX systems, you can use the syslog feature to implement robust, high-integrity administrative monitoring; for Windows, you must implement a solution that uses a tool such as LogParser (see "LogParser," July 2004, InstantDoc
ID 42174) or purchase a third-party solution.
As for preventative control of administrative authority, your best approach is to limit and reduce the number of people who have that authority. Very few (if any) administrators truly need Domain Admin authority to perform day-to-day tasks. Resetting passwords, restarting services, maintaining users and groups, and adjusting file permissions can all be delegated, thanks to Windows 2000 Server's and later versions' granular delegation of authority within AD and the OS itself. To learn more about AD's delegation of control, see "AD Delegation Eases Administration," May 2005, InstantDoc ID 45841, or "Tools for Managing AD Delegation," August 2002, InstantDoc ID 25641.
For most resources outside of AD (e.g., a file), figuring out how to delegate control is simply a matter of opening the object's Properties and modifying its permissions. However, system services can be a tough nut to crack because a service's Properties dialog box doesn't have a Security tab. To learn how to delegate control of services, see "Access Denied: Setting Permissions on Win2K Services," March 2002, InstantDoc ID 23963. If you run a small IT shop and are the only one who has Administrator authority, you should still apply least privilege to yourself to limit the impact of mistakes and malware.
Fulfill Your Mission
Using least privilege to protect your network takes some work at first, but the payoffs are worth the effort. Understanding the concept and how to take advantage of it definitely qualifies as need-to-know information. Look for more articles about implementing least privilege in upcoming issues of Windows IT Security.
