Securing XP Desktops:
Account and Auditing Policies
by David M. Piscitello, President, Core Competence, Inc.
If asked to name one of the most neglected security processes, I'd probably answer, "Securing user (client) computers." Organizations still struggle to find time, talent and budget to administer servers and security systems. The predictable result is that client computer security policy and implementation is often relegated to some of the least capable staff in your company: the users themselves. This is true for businesses in general, but especially true in small to medium businesses today.
Every organization can take measures to reduce the many risks poorly administered client computers create. Many companies manage the obvious ones (antivirus measures, personal firewall and especially VPN software) fairly well. Ironically, often the same companies that insist on "strongly authenticated tunnels" make little effort to assure that PCs configured with VPN adapters have equally strong user account and auditing policies. Let's look at ways to remedy this inconsistency using Windows XP.
Why these benchmarks?
In this article, I recommend specific security settings. Here's how I chose them.
The Center for Internet Security (CIS) has developed a set of security configuration benchmarks for Windows, Solaris, Linux and HP-UX systems, ranging from account and auditing policies to permissions for accessing file systems, running services, and accessing the configuration data (e.g., the Windows registry). These draw from the recommended best configuration practices of the NSA, Microsoft's best practices, and the accumulated expertise of security experts worldwide. CIS offers security templates for Windows 2000 (Professional and server) that codify its benchmarks in a format you can import through the Local Security Policy editor or the Security Configuration and Analysis Tool (a plug-in of the Microsoft Management Console). You can also develop a group policy template from CIS's templates, and distribute this to client machines using Active Directory. CIS is in the process of developing XP templates, so until they are available, I've extrapolated the security settings I recommend from the Windows 2000 Professional settings.
So, these settings represent more than my considered opinion alone. Ready to take a look? Here we go.
User Accounts and Windows XP Account Policies
Too many users operate client systems under the local administrator account. Too often, they don't bother to change the account name from the default (administrator), or even create a logon password. And users who log on as administrators can install unauthorized software, create file shares, and run unauthorized and unprotected services. If you provide company-owned computers to employees, you might conclude that granting users these freedoms is too great a risk. To help the user keep the computer available, and to prevent unlicensed, unstable, or potentially malicious software from being installed, create accounts for users in a Users Group, where access permissions will prevent them from making system-wide changes. From the Administrative Tools Control Panel (visible in Classic View), choose Computer Management => Local Users and Groups => Users. Highlight the Administrator account, right-click on it, rename it to something else, password protect it, and do not share it with system users. While you're here, disable guest and unwanted account(s), and make certain all authorized users must change passwords periodically. These actions won't make you popular, but you'll probably receive fewer helpdesk calls from users who took advantage of local administrator authority, only to mess up their own machines.
Once you've forced all accounts to use passwords, you can use Windows XP account policies to compel users to create passwords that are difficult to guess or crack. Account policies are accessed through the Local Security Policy editor, which is accessible from the start menu (Start =>Run => secpol.msc). You will also find it in the Administrative Tools folder.
Launch the editor, open Security Settings, and open the Account Policies folder. To meet the emerging consensus benchmark security configuration (see Why These Benchmarks?), change the security settings in the Password Policy folder to the following values:
|
Policy |
Security Setting |
Why? |
|
Enforce password history |
24 passwords remembered |
Preventing users from re-using passwords and "root" information of previous passwords (e.g., piscitello1234, piscitello1235) |
|
Maximum password age |
42-90 days |
Passwords should be changed with reasonable frequency |
|
Minimum password age |
1 day |
Prevents users from cycling through the 24 passwords remembered so they can re-use their favorite password |
|
Minimum password length |
8-12 characters |
8 is an acceptable minimum for users, but 12 is preferred for privileged (e.g., administrator) accounts |
|
Passwords must meet complexity requirements |
Enabled |
Users must create passwords using upper and lowercase alphabetic characters, numbers, and special characters to make passwords difficult to crack. |
|
Store passwords using reversible encryption |
Disabled |
This setting causes passwords to be encrypted using a one-way hash. Passwords can't be derived from the hash. |
Next, change the security settings in the Account Lockout Policy folder to the following values. Cumulatively, these settings are intended to frustrate repeated attempts to guess an account and password:
|
Policy |
Security Setting |
|
Account Lockout Duration |
15 Minutes |
|
Account Lockout Threshold |
3 Bad Login Attempts |
|
Reset Account Lockout After |
15 Minutes |
(If your Account Lockout Duration says "Not applicable," it's because you haven't set the Account Lockout Threshold yet. Enter a number greater than zero in Account Lockout Threshold, then you can set the Duration.)
Admittedly, passwords are not the most desirable authentication method, but unless you deploy Kerberos for Windows Domain accounts or a third party authentication method (e.g., a token), it's worth your while to configure XP systems with password and account lockout policies that will help prevent unauthorized access.
Windows XP Auditing Policies
Auditing user activities is an essential complement to account administration. If you don't audit logon events, how can you know whether someone has attempted to break into your system, succeeded in adding an account, or has escalated privileges from Plain Old User to Administrator? Generally speaking, you should keep a log of security-related events that either forewarn or provide post-incident evidence of attacks or misuse of account privileges, on company-owned client systems as well as servers.
Using the Local Security Policy editor, you can direct Windows XP to record account activities in the Security Event Log. Launch the editor (Start => Run => secpol.msc), open Security Settings, and open the Local Policies folder. Open the Audit Policy and change these security settings, as follows:
|
Policy |
Security Setting |
Why? |
|
Audit account logon events |
Success, Failure |
Records the result of every logon attempt using domain logon credentials. |
|
Audit account management |
Success, Failure |
Records attempts to create, rename, enable, or disable users and groups and account passwords |
|
Audit policy change |
Failure only, or |
Records attempts to modify the audit policy and other security settings you've made |
|
Audit privilege use |
Failure only, or |
Records each time a user invokes a "privileged" operation on the system such as a Backup or Restore operation. |
|
Audit object access |
Failure only, or |
Use this in conjunction with security properties you set on individual files and folders to record user attempts to access those "objects" |
|
Audit logon events |
Success, Failure |
Records the result of every logon attempt using a local logon credentials |
|
Audit system events |
Success and Failure |
Records system shutdown and restart events, log full events, and other events that have system-wide significance. |
Audit and other security related events are recorded in XP's Security Event Log. Protecting this log from unauthorized access and assuring that entries won't be overwritten are critical security configuration tasks. Go to Administrative Tools => Computer Management. Open System Tools, then open Event Viewer. Select Security with your right mouse button, and choose Properties. From the Properties Window, increase the default size of the Security Event log from 512 Kb to 80 Mb, and select Overwrite Events As Needed as the action to perform when the maximum log file size is exceeded. To restrict guest access to the log, you must edit the Registry (sorry!). Run Registry Editor (Start => Run => regedit) and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog. Choose the Security subkey. Select the REG_DWORD RestrictGuestAccess, and set the value to one (1). If Restrict GuestAccess is not there, you must create it by right-clicking on Security, then choosing New => DWORD Value. The value is case sensitive, so capitalize the R, G, and A when typing RestrictGuestAccess.
While you're here, you can make the same change for the Application and System log subkeys as well.
'tis but the first step...
User account and auditing policies play an important role in securing client systems, and should not be neglected. Nor should logging, here as well as at your firewall! Considerably more can be done to secure Windows XP Professional. In upcoming articles, we'll consider user rights assignments, public key policies, and additional security options configurable through local security policies. ##
Resources
Step-by-Step Guide to Securing Windows XP Professional in Small and Medium Businesses
LiveSecurity article: The Problem with Passwords
LiveSecurity article: http://www.watchguard.com/archive/showhtml.asp?pack=1594
Microsoft Windows XP Security Guide Overview
Windows 2000 Default Security Policy Settings
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.