Learning Windows Server 2003
7.3. Creating and Enforcing Security Policies
If you haven't yet upgraded to Service Pack 1 and are still interested in distributing a comprehensive, consistent security policy to your machines, Windows Server 2003 comes with two basic tools that will help you do just that: security templates and the Security Configuration and Analysis tool. While they aren't as easy to use or as manageable as SCW-based policies , they are certainly as effective. Another bonus point: your investment of time and resources in creating these templates isn't wasted, as you can include them in any future SCW policies that you might create. In this section, I'll discuss templates, how they're used, and how to create and manage them on your network. 7.3.1. Using Security Policy Templates
Security templates list all possible security attributes and settings for a given system and their associated configurations. By using the Security Templates snap-in, you can easily provision a standard collection of security settings across multiple systems using either remote registry editing or Group Policy. For administrators that have a large number of systems to manage, and for those who provision quite a few systems on a regular basis, security templates can save a lot of time: they can assist with setting up a new machine or rolling out a new organizational security policy to many systems. They're also helpful because you can define multiple templates, since few large organizations have a single security standard for all computers. Security policy templates are a tool your organization can use to implement the three facets of the CIA triangle, which I discussed earlier in the chapter. You can begin using security templates by loading the Security Templates snap-in:
You now have the Security Templates snap-in added to a console. From this snap-in, you can expand the Security Templates section in the console tree on the left, and then expand the C:\Windows\security\templates folder to view the predefined security templates. The Security Templates snap-in contains seven configurable areas, which you can display by double-clicking the label in the righthand pane inside the snap-in after selecting a template from the list in the lefthand pane. The areas are shown and described in Table 7-1.
Each template is nothing more than an ASCII text file with a .INF extension that contains a list of all settings therein. Looking at the file itself is often a more useful and quicker way to determine applicable settings. For example, the following is a portion of the HISECWS.INF file: [Profile Description] %SCEHiSecWSProfileDescription% [version] signature="$CHICAGO$" revision=1 DriverVer=10/01/2002,5.2.3790.0 [System Access] ;---------------------------------------------------------------- ;Account Policies - Password Policy ;---------------------------------------------------------------- MinimumPasswordAge = 2 MaximumPasswordAge = 42 MinimumPasswordLength = 8 PasswordComplexity = 1 PasswordHistorySize = 24 ClearTextPassword = 0 LSAAnonymousNameLookup = 0 EnableGuestAccount = 0 ;---------------------------------------------------------------- ;Account Policies - Lockout Policy ;---------------------------------------------------------------- LockoutBadCount = 5 ResetLockoutCount = 30 LockoutDuration = -1 ;---------------------------------------------------------------- ;Local Policies - Security Options ;---------------------------------------------------------------- ;DC Only ;ForceLogoffWhenHourExpire = 1 ;NewAdministatorName = ;NewGuestName = ;SecureSystemPartition
The compatible security template, COMPATWS.INF, is meant to allow non-Microsoft certified applications to run on a system without being inhibited by security features. It discerns between ordinary users, who can run only certified Windows applications (those earning the compatibility seal that's usually displayed on the software packaging), and power users, who can run uncertified and potentially problematic software. It also allows a certain subset of registry keys, initialization files, and other folders to be modified by otherwise unprivileged users. However, it's really not the most secure template to use, and I'd advise using another, more secure template (as I describe in a bit) unless you're running into impassable compatibility problems. The secure security templates--SECUREWS.INF for workstations and ordinary servers and SECUREDC.INF for domain controllersare designed to provide a middle-of-the-road level of security. The secure templates offer more stringent password policies, restricted guest access, audit policies that cover most important security events, and increased account lockout policies. However, files, folders, and registry keys and their security settings are not configured with this template because, for the most part, they are configured securely out of the box. For your environment, you might want to modify this to include custom permissions for certain directories and registry keys. You might use this if you have a sensitive application (say, a mortgage loan origination program) that has credit-report data stored locally. You can customize the template to secure this program's data directory by default. If you are just starting to focus on security within your business, and you have applications that are up-to-date and in their latest release, try using these secure templates. They really batten down the hatches as opposed to the compatibility template, and they're a good place to start when tightening configurations on your network. Be aware that older applications that use insecure methods to communicate over the network might fail, though. The highly secure templateHISECWS.INF for workstations and ordinary servers and HISECDC.INF for domain controllersfocuses on securing transmissions between workstations and servers running Windows Server 2003. It also removes the Authenticated Users group (and any other groups for that matter) from the Power Users group on all machines that use this template. Use this template only if you know your applications won't break with the stringent restrictions on network communications. Finally, the default security template, SETUP SECURITY.INF (note the space), restores the default security settings for an initial installation of Windows. You can use this to restore the initial settings for a client computer or regular server if you have misapplied a template or you want to start "from scratch." However, you cannot do this for domain controllers. For more information on this, see:
7.3.1.1. Creating a custom security template
You might want to make your own customized policy modifications that go above and beyond those made in the templates shipped with Windows Server 2003. Creating a custom security template affords you an easy way to package, deploy, and apply these modifications with a minimum of administrative headaches. Best of all, you can use these templates in conjunction with a utility called the Security Configuration and Analysis Tool (SCA) to assess the overall "hardness," or state of security, of your machines. To create your own security template, follow these steps:
Now you can make any policy modifications you want in any one of the policy areas supported by the tool: account policies, local policies, the event log, restricted groups, system services, the registry, and the file system. Your additions, deletions, and other changes are saved in the template immediately. To take this one step further, you might decide to build on the basic policy settings provided by the templates shipped with Windows Server 2003. In that case, it's quite simple to open one of the default templates, resave it to a different name, and make further modifications to create your own custom template. To do so, just follow these steps:
7.3.1.2. Importing a template into a GPO
One of the most common ways to apply a security template to many machines is by importing the template into a GPO. The following steps describe how to do it:
7.3.2. Security Configuration and Analysis
The Security Configuration and Analysis (SCA) MMC snap-in lets you compare systems in their current configuration against settings specified within a security template, or within multiple templates. Using the report generated by that process, you can make wholesale changes to a system's security to bring it in line with an entire template, or you can modify configurations on an item-by-item basis. This is a great tool for initial system rollouts and deployments because you can have one template containing your business's entire security policy that you can apply using a simple tool. You also can save the current system configurations and export them to a template should a rollback be needed. To begin using the SCA snap-in, you'll need to add it to a console. To do so, follow these steps:
7.3.2.1. Creating and using template databases with SCA
SCA uses databases, which have a .SDB extension, to store security templates for faster access and data retrieval. You can either create a new template database if this is your first time using SCA, or open an existing SDB file, by doing the following:
Once you've created a database with an initial security template inside it, you can import any number of other templates into it as well. Simply right-click Security Configuration and Analysis, and from the context menu choose Import Template. From there, select the .INF file that is the template you want, and click OK. The settings are added to the database.
Keep in mind that when you make changes to a security policy from within SCA, those settings are saved to the database and not to a template file that you can import into a GPO or otherwise apply to other systems. You'll need to export any saved settings to another template to use the template in other systems. To do so, right-click Security Configuration and Analysis, and from the context menu choose Export Template. From there, choose a filename with a .INF extension for the exported template, and click OK. 7.3.2.2. Scanning system security
To analyze a system using SCA, right-click Security Configuration and Analysis in the console and select Analyze System Now from the context menu. The Perform Analysis dialog box will appear. Select a filename for the results and accompanying log and click OK. Two reports will be generated. First, events will be written to a log file to correspond with each success and failure of a component analyzed by SCA. And second, SCA will write the current state of each component to the configuration trees within SCA, as shown in Figure 7-7. To view the log file, right-click Security Configuration and Analysis in the left pane, then select View Log File. Windows will load the log file into the right pane and will show generally what portions of the computer's security policy don't match up to a certain baseline as set in the database. For a more exact analysis , you'll need to examine the policy tree itself. To do so, expand Security Configuration and Analysis and select one of the seven security areas to consider. Figure 7-8 shows the password policy tree under Account Policies. Figure 7-7. Using SCA to compare system status with a baseline Figure 7-8. Examining the results of an SCA analysis Note the Database Setting and Computer Setting columns in the right pane. These indicate exactly which configuration options match between the current computer and the settings configured in the SCA database. Settings that agree are preceded by an icon with a small green checkmark. Likewise, settings that disagree are preceded by a small red X. You can also have an exclamation point, depending on the severity of the difference and Windows' ability to comprehend what's going on. Settings that don't appear in the database are not analyzed and thus are not marked. 7.3.2.3. Correcting system security
If you want to make changes to a computer's security policy as specified by SCA in a wholesale manner, simply right-click Security Configuration and Analysis and select Configure Computer Now. The changes will be updated on the local computer. If you want to make a change in the database based on an actual configuration object, you can right-click the attribute in question to raise the Analyzed Security Policy Setting dialog box, as shown in Figure 7-9. Figure 7-9. Changing a policy setting in the SCA database
Simply adjust the settings in the box and then click OK. The change will be committed to the database, but not to the local computer, and all future computers you examine with that SCA database will be analyzed with that change committed. 7.3.3. Microsoft Baseline Security Analyzer
The Microsoft Baseline Security Analyzer, or MBSA , is an excellent tool that you can use to assess your network and the effects of your security policy. MBSA works by scanning a machine or range of machines for specific policy problems, security updates that aren't present, Microsoft Office updates that aren't present, and other red flags that might indicate security risks. Then it lists all the problems in an easy-to-read report that you can use to rectify each problem. The latest version as of this writing, Version 2.0, adds a better interface over the previous version with more informative screens and reports, and makes use of both the much-improved Microsoft Update catalog and Windows Update Agent detection engine. MBSA can scan for configuration problems in the following products out of the box:
MBSA 2.0 also scans for missing security hotfixes in the following products:
MBSA is an essential tool for ensuring the computers in your organization remain in compliance with any security policy you have in place. You can download the tool from the Microsoft web site at:
7.3.3.1. Using the MBSA
Running a scan on a computer or set of computers using the MBSA is simple. In the following example, I'll assume we're scanning only a single computer. First, open the MBSA program. Then do the following:
A suggestion about security strategy: I recommend you use the MBSA before applying your security templates or SCW policies to know what issues to address, and then run it once again after your templates or SCW policies have been applied and tested to in order to identify what might have slipped through the cracks. |