The obvious question people are asking is "do I need to use the Windows Vista Security Guide" to secure my Vista system? Perhaps, the slightly more interesting question is the follow-up question: "If I have to use the guide, why didn't Microsoft make it the default?"
To answer this question, you really need to understand the benefits and drawbacks of the security guide.
What Is Good in the Vista Security Guide
Generally, the audit changes made in the guide are not bad. It is particularly good that the guide enables Process Creation auditing, as this is the only way to audit User Account Control events. The method of implementation of the audit changes-a startup script-is very inelegant, but stems from the fact that Microsoft did not provide a centralized management mechanism for sub-category auditing in Windows Vista.
We also like the fact that Microsoft went to the trouble of publishing the guide in the first place. A properly written guide, with reasonable settings, can give a nice introduction to security risk management. It can be used to reinforce that not everyone can use the same configuration.
What Could Have Been Better in the Vista Security Guide
The use of the GPOs is inelegant to say the least. The Windows 2000 Security Hardening Guide from Microsoft was the first to take a novel approach to security configuration management. It put all settings held in common across all systems into a single GPO. This trend was continued in subsequent security guides from Microsoft, but was broken, with a bang, in the Vista Security Guide. There are hundreds of duplicated settings across the Desktop and Laptop policies. This makes it very difficult to get an at-a-glance understanding of the settings recommended in the guide, and even more difficult to modify them to suit individual needs.
It is strange that the audit settings are set both in the Desktop and Laptop GPOs, even though the auditing used is identical in both. The guide makes 16 changes to the default audit policy in the SSLF configuration, and 10 subcategory changes plus changes to the categories in the Enterprise configuration. There are several odd things about this configuration. First, the guide turns off auditing on events. For instance, Account Lockout events are normally audited, but the guide turns off auditing for them in both configurations. Of course, there should never be any of those events on a client, as they would get logged on the computer hosting the account. That means users of the guide need to ensure they are turned on at the domain level though. Using the settings in the guide, account lockout events will happen, and it probably would be good to have an audit trail. Another oddity with respect to auditing is that the guide specifies category audit settings in the GPO in the Enterprise configuration, but not in the SSLF configuration. That actually means that the Enterprise configuration will have more events audited than the more sensitive SSLF configuration. This is supposedly done because the Enterprise configuration for Windows Vista is designed to work both with Windows Vista and Windows XP. However, it makes it quite difficult to tell what modifications need to be made to a Windows Vista computer.
It is important to note that environments that use Remote Assistance will be unable to use the guide as is. The Vista Security Guide makes all the changes that become problems for Remote Assistance.
Another feature of the guide that we dislike is that it enforces a number of default settings. In fact, the guide will modify the Group Policy Editor interface to show a number of settings that are not normally shown, so that the defaults can be enforced. In some cases, there are even settings added to control behavior for which Windows Vista already has settings, but Windows XP does not. This is the case, for instance, with the AutoRun settings, which are available in Windows Vista already under Computer Configuration\Administrative Templates\ Windows Components\AutoPlay Policies. The settings added to the user interface by the guide seem, pretty universally, to have been a cut-and-paste effort from the Windows XP Security Guide, and are often not needed on Windows Vista. The fact that settings were specifically added to control behavior that Windows Vista already controls, clutters the changes the guide makes that actually modify how Windows Vista operates, and makes it hard to analyze whether the guide will work in a particular environment or not.
Enforcing defaults can be valuable, and may be recommended for the environments targeted by the SSLF settings. However, in a highly managed environment, such as the one the guide is intended for, it is typically unnecessary. In fact, it greatly complicates security management because there are now so many more tweaks made that finding the cause of a problem becomes much more difficult. It also gives the impression that the authors of the guide fell prey to that all-too-common ailment of believing that more settings must be better. One of the best ways to fill a guide with settings is to make changes that make no difference, such as enforcing defaults.
Previous security guides from Microsoft have largely adhered to the principle that "less is more" and have only advocated changes that make a significant difference in the operating system. Unfortunately, the Windows Vista guide breaks that tradition. For instance, templates make a large number of settings that are not visible in the GUI. An example is the setting to disallow use of Windows Messenger; it is turned on in both the Enterprise and SSLF configurations. This hardly seems necessary because Windows Messenger was deprecated and does not ship with Windows Vista. The downloadable version will not run. This setting, thus, makes no difference whatsoever and serves only to confuse matters.
Nowhere is the More-Settings-Is-Good syndrome more evident than in the firewall section though. The guide makes extensive changes under Computer Configuration\Administrative Templates\Network\Network Connections\ Windows Firewall\Domain Profile and Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall\Standard Profile. This may be sensible, until one recognizes that those nodes are used to configure the firewall in XP SP2, not the Windows Vista firewall (the settings here will apply to the Windows Vista firewall, but only if the Windows Firewall with Advanced Security settings are not configured, which they are). It is also unfortunate that the guide does not contain usable information on how to replicate the firewall settings made in the templates for those environments that cannot use, or are uncomfortable with using, the templates as they are.
Not recognizing this in the guide, and filling the Group Policies with unnecessary security settings calls into question the wisdom of the advice given in the guide.
