Securing XP Desktops:
Controlling Local Use and Network Access
by David M. Piscitello, President, Core Competence, Inc.
Spend even a short time investigating computer and network security, and you'll encounter the acronym AAA. AAA stands for authentication, authorization, and accounting:
- Authentication provides methods of verifying a user's identity: authentication asks, "Is this user who he claims to be?"
-
Authorization imposes controls on network and computing use, asking, "Is this user permitted access to this resource?"
-
Accounting provides a means of monitoring user activities, for billing and, perhaps more importantly, for auditing security measures. Auditing answers the questions, "Are the security measures in place adequate? Do they match the policy I intend to enforce?"
In a companion article, I presented ways to create user accounts and implement auditing on systems running Windows XP Professional Edition, by using the Local Security Policy editor. In today's article, we explore ways to exercise control over what local computer and network resources users may access, using XP's Group Policy Object Editor.
When (and why)
access controls are necessary
When you provide company-owned PCs and laptops for employees, the return you expect on this investment is productivity. In your Acceptable Use Policy, perhaps you state that company-owned PCs are to be used primarily for business purposes. "Primarily" or equivalent hedge words often show up in today's AUPs, because companies concede that "breaks" are part of any work day. PCs and Internet connections provide certain employees recreation and entertainment, and in this respect, are just as appropriate as basketball hoops, TV/radio, game tables, etc. For any diversion, companies typically impose "access controls" to protect the work environment (and company assets). Companies expect employees to respect the guidelines: Don't hang on the rim. Keep cigarette ashes from the felt on the billiards table. Adjust the radio volume so that it doesn't disturb other employees. And don't restart a PC while others are accessing file shares remotely.
In AUPs, a company also establishes policies for access to its facilities. Employees must present ID cards. Employees are often prohibited from escorting unregistered guests into facilities. Just as you might employ a security guard to assure that employees comply with these policies, so might you implement authorization controls on XP Professional desktops to assure that employees don't allow unauthorized access to company computers and applications, company intranets, and even the company's Internet access. These are simple examples of when and why you might want access controls on company-owned computers.
User Rights Assignment
at the Group Policy Level
In Windows XP, you can control user access effectively by assigning that user to a group, and asserting access permissions (privileges) at the group rather than individual level. Asserting group policy enables you to distribute organization-wide security policy objects from an Active Directory. Alternately, you can create a policy template suitable for distribution, and import it at individual machines. Templates can be installed using scripts, or by using yet another Microsoft Management Console plug-in, Security Configuration and Analysis.
To get a feel for the security settings you can impose under User Rights Assignments at the Group level, run the Group Policy Object Editor (Start => Run => gpedit.msc) on a local machine. Then follow this path: Computer Configuration => Windows Settings => Security Settings => Local Policies => User Rights Assignment. Double-click on a policy to access its properties (or select and right-click properties).
At this level, you are assigning privileges largely related to system level access, maintenance, and availability to groups, not individuals. Microsoft provides a thorough analysis of every security setting in the Windows XP Security Guide: Securing XP Clients. I'll focus on a subset of the more critical security settings in this table:
|
Policy |
Dave's Setting |
When and Why? |
|
Access this computer from the network |
Administrators, Users |
Determines what groups can use SMB, CIFS, NetBIOS, HTTP and COM+. This setting prevents the use of Guest and Anonymous user accounts as attack vectors. |
|
Allow logon through Terminal Services |
Administrators (Helpdesk group), or No one |
Determines what groups can remotely access the local machine. Restrict this to administrators unless you use Remote Assistance to assist users from a Help Desk. If you don't use Terminal Services, disallow it entirely. |
|
Bypass traverse checking |
Users |
Restrict this to users to prevent Guest and Anonymous user accounts from accessing restricted files and folders. |
|
Change the system time |
Administrators |
System time is critical for maintaining accurate auditing. Only administrators should change time. |
|
Debug programs |
No one |
Restrict this to prevent unauthorized access to OS components through debugger programs. Only developers need this privilege, and even then, only in the context of their individual account, which is enabled by default. |
|
Force shutdown from a remote system and Shut down the system |
Administrators |
Restrict access to the shutdown process to prevent a malicious user from denying service to legitimate local machine users. |
|
Log on locally |
Administrators, Users |
Restrict logon to authorized users and admins to prevent access via Guest accounts. |
|
Profile single process |
Administrators |
With this privilege, a user can monitor nonsystem processes (e.g., applications), which falls into the "information gathering" category. Only allow admins this privilege. |
|
Restore files and
directories and Backup files and directories |
Administrators |
Determines whether a user can override permissions and restore or backup files and directories. Both operations can be misused. You may want to allow this privilege for laptop users who are savvy enough to recover from a system problem or data loss while on the road. |
An explanation about the "No one" security setting: configure this by enabling a security setting, then removing all groups from the policy.
If you open the Local Security Policy Editor (Run => secpol.msc) and navigate to User Rights Assignments, you'll find the same list of policies you see from the Group Policy Object Editor. Changes at this level affect individual user accounts, giving you the ability to increase or further restrict policy for a specific user. My experience is that "one-off" exceptions to group policies always come back to haunt me. They are hard to isolate, are most likely to be poorly documented, and can usually be avoided by creating another group policy, even if that policy applies to a single individual.
Conclusions
Exercising control over user access rights to networks and computers is a complementary security process to creating accounts and auditing users through these electronic identities. Several methods exist to implement such controls when running Windows XP Professional on user computers. Microsoft is under constant scrutiny and doggedly criticized for a perceived lack of attention to security in its products. Some of this criticism is earned. On any system, I object to configuration defaults that facilitate exploits, and I'd love to have a "secure vs. ease of use defaults" choice when purchasing a Windows PC. But that's not the hand we are currently dealt.
The practical response is not to whine and carp, but to accept that every system administrator (and user) must accept responsibility and accountability for configuring for security. You can grump at Microsoft, or you can measurably improve Windows XP Professional through the Local and Group Policy Object Editors. Is it fair that you should have to do this work? Not really. Is it effective? Yes. ##
Resources
Windows XP Security Guide: Securing XP Clients
UK Security Online: Windows XP -- Home User Self-Defence
Ways to Open the Group Policy Editor
Microsoft Technet: To open Group Policy Object Editor as an MMC snap-in
Copyright© 2004, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.