|
7.2. Creating and Enforcing Security PoliciesTo understand the rest of this chapter, you need to have a fundamental understanding of how to manage security policies and configurations. Windows Server 2003 comes with two basic tools that will help you create, distribute, and automate security configurations: security templates and the Security Configuration and Analysis tool. 7.2.1. Using Security Policy TemplatesSecurity 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 across multiple systems using either remote registry editing or GP. 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 organization security policy onto many systems. They're also helpful because you can define multiple templates, given that 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 principle. 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 reading 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 ordinary 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. You can safely use this template on the vast majority of workstations, as it is designed with compatibility in mind, second to security. The secure security templatesSECUREWS.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 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 serversfocuses on securing transmissions between workstations and servers running Windows Server 2003. It also removes the Authenticated Users group 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.2.1.1 Creating a custom security templateYou 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 headache. Best of all, you can use these templates in conjunction with a utility called the Security Configuration and Analysis Tool (SCAT) 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 filesystem. 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 the templates, resave to a different name, and make further modifications to create your own custom template. To do so, just follow these steps:
7.2.1.2 Importing a template into a GPOOne 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.2.2. Security Configuration and AnalysisThe 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 up to speed with a template as a whole, 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.2.2.1 Creating and using template databases with SCASCA 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; they do not replace or otherwise modify any preexisting settings within 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.2.2.2 Scanning system securityTo 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-3. Figure 7-3. Using SCA to compare system status with a baselineTo 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-4 shows the password policy tree under Account Policies. Figure 7-4. Examining the results of an SCA analysisNote 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. Settings that don't appear in the database are not analyzed and thus are not marked. 7.2.2.3 Correcting system securityIf 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-5. Figure 7-5. Changing a policy setting in the SCA databaseSimply 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.2.3. Microsoft Baseline Security AnalyzerThe 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. MBSA can scan for problems in the following products:
MBSA 1.21 also scans for absent 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 http://www.microsoft.com/technet/security/tools/mbsahome.mspx. 7.2.3.1 Using the MBSARunning 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 to know what issues to address, and then run it once again after your templates have been applied and tested to identify what might have slipped through the cracks. |
|