Section 7.3. Creating and Enforcing Security Policies

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:

Run mmc from the command line to load the MMC in author mode. Author mode allows you to construct new consoles from scratch and add snap-ins to them.
From the Console menu, select Add/Remove Snap-in. Then select Add. This opens a dialog box entitled Add Standalone Snap-in.
From the list, select Security Templates, click Add, and then click Close.
Click OK in the next box to confirm the addition of the 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.

Table 7-1. Template policy areas
Framework area	Description
Account policies	This area applies security configuration to user accounts, including passwords, account lockouts, and Kerberos ticket policies. Password and account lockout policies apply to workstations and servers; Kerberos ticket policies apply only to domain controllers.
Local policies	This area allows you to set auditing and event logging policies, user rights assignments, and registry keys that directly affect system security. It also controls auditing of events, including application actions and security notifications. Note that settings in this area apply to all Windows 2000 or later systems, and not to only a specific kind of system.
Restricted groups	This particularly useful area allows you to define policies regarding a user's membership into security groups that allow elevated privileges. It's simple to define a policy where domain users can never be a member of the local Administrators group; other policies are equally easy.
System services	This area contains startup options for services and access controls on them.
Registry	In this area, you can configure access permissions on specific keys in the registry. In addition, you can audit access and modification of registry entries.
File System	This area allows you to preconfigure access permissions on selected file system directories.
Event Log	In this area, you can specify how the Application, Security, and System event logs fill and rotate and what their maximum size might be. You also can configure who has access to view the logs.

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:

http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/Default.asp?url=/resources/documentation/windowsserv/2003/standard/proddocs/en-us/sag_SCEdefaultpols.asp

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:

In the Security Templates console, expand Security Templates in the tree pane on the left, and right-click C:\WINDOWS\security\templates (this is the default templates folder in the system).
Select New Template from the context menu that appears.

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:

Select an existing template inside the Security Templates console. In this example, I'll use the securews.inf file.
Right-click the existing template, and click Save as...from the context menu.
Give the new template a name, as shown in Figure 7-6.
Click OK. The new template is created with the settings from the old basic template.

Figure 7-6. Creating a new security template

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:

Select the GPO you want to use inside Group Policy Object Editor.
Navigate through Computer Configuration Windows Settings Security Settings.
Select the appropriate security template from the list of .INF files, and then click OK.

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:

Run mmc from the command line to load the MMC in author mode. Author mode allows you to construct new consoles from scratch and add snap-ins to them.
From the Console menu, select Add/Remove Snap-in. Then select Add. This raises a dialog box entitled Add Standalone Snap-in.
From the list, select Security Configuration and Analysis, click Add, and then click Close.
Click OK in the next box to confirm the addition of the snap-in.

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:

Right-click Security Configuration and Analysis in the left pane of your console and select Open Database from the context menu.
The Open Database dialog box appears. Type a name or select one from the list to open an existing database, or enter a name for a new database.
If you enter a new filename, you will be given the option of importing a base security template. Choose either a predefined template that ships with Windows Server 2003 or one that you've modified or customized.
Click OK.

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.

In the case of templates whose settings conflict, the settings imported last will apply.

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:

Windows NT 4.0
Windows 2000
Windows XP
Windows Server 2003
IIS
SQL Server
Internet Explorer
Office

MBSA 2.0 also scans for missing security hotfixes in the following products:

Windows NT 4.0
Windows 2000
Windows XP
Windows Server 2003
IIS
SQL Server
Internet Explorer
Exchange Server
Windows Media Player
Microsoft Data Access Components (MDAC)
MSXML
Microsoft Virtual Machine
Commerce Server
Content Management Server
BizTalk Server
Host Integration Server
Office

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:

http://www.microsoft.com/technet/security/tools/mbsahome.mspx

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:

Click Scan a computer to scan a single computer.
The Pick a computer to scan screen appears, as shown in Figure 7-10.

Figure 7-10. Scanning a computer using MBSA
Ensure the correct computer name is listed in the Computer Name field. You can also specify an IP address instead. Additionally, enter a name for the resulting report; you can use any of the options listed theredomain, IP address, date and time, or computer name.
Select the scope of the scan. You can choose to scan for Windows vulnerabilities, weak passwords, IIS vulnerabilities, SQL vulnerabilities, and security updates. (You can use a Windows Software Update Services [WSUS] server if you want. SUS is covered later in this chapter.)
Click Start Scan to begin the scan. The wizard will fetch the latest security update information from the Microsoft site and then commence the scan.
When the scan is complete, you'll see the View security report screen. A sample screen is shown in Figure 7-11.

Figure 7-11. MBSA scan results
You can see each issue the scan identified, how serious the issue is, and a link to information on how to correct it.

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.