In-Depth
Auditing Security Baselines with Security Templates
There are two primary methods for auditing computers with security templates: manually and using a script command. We explain the benefits and drawbacks of each.
- By Derek Melber
- 10/20/2004
As you sit down to audit a Windows network, you need to consider what should be audited and what will be audited. We all know that the "should" answer includes all possible security control points on all computers and devices on the network. The reality of such an in-depth audit is far from the world we live in. Therefore, you need to scale back to what is more realistic when considering what should be audited. Then, and only then, can you determine what you will audit.
If you look at the different areas of the Windows network, you can break down much of what needs to be audited into four major categories:
- Clients
- Servers
- Domains and domain controllers
- Active Directory and GPO management
The first three categories are where we need to spend our time, since these are where typical security baselines are established and implemented for Windows networks. The fourth category is not controlled by a security template and falls outside the scope of our discussion.
The first three categories have similar control points you must investigate. The majority of these common control points are controlled by security templates. The full list of common and standard control points include:
- Account policies
- Audit policies
- User rights
- Event log settings
Groups- System services
- Resource permissions
- Patches and service packs
- Shares and share permissions
- Users
Security templates can tackle most—but not all—of these security settings. The security template can be used to configure:
- Account policies
- Audit policies
- User rights
- Event log settings
- Restricted groups
- System services
- File permissions
- Registry permissions
As you can see, the only control points that security templates can't tackle are patches, service packs, shares, and users. From a list this long, that's not a bad average. I will take a quick look at these settings later so you know how to audit these settings, too.
How to Audit with Security Templates
Auditing with a security template is most successful when the security baseline was implemented using a security template. However, it is not a complete loss if security templates were not used to establish the security on the computers. The key is that you have the security templates to perform the audit.
Security baselines need to be created for the different types of computers in your Windows network. These computer types can include:
- Domain controllers
- File servers
- Application servers
- Print servers
- Web servers
- Employee computers
- IT staff computers
You will need security templates for each security baseline established for these computers. Once you have these security templates, you can then move forward with the audit. There are two primary methods for auditing computers with security templates. The first option is more of a manual method, while the second method uses a script that partially automates the audit process. Both have their benefits and their drawbacks.
Method #1: Manual Audits
Let's first look at the manual method, which uses the Security Configuration and Analysis (SCA) snap-in. SCA provides a GUI view of the entire audit process, including the results from the audit. To use the security template to audit a computer:
Click the Start button.
Select the Run menu option.
Type MMC into the text box and click the OK button.
Select Console from the Toolbar to get the menu options.
Select the Add-Remove snap-in menu option.
Click the Add button.
Select Security Configuration and Analysis from the Snap-ins list, then click the Add button.
Click the Close button, then click the OK button.
Right-click on the SCA node and select Open Database
Select a name for the database
Select the security template you will use for the audit
After the database is created, right-click on the SCA node and select the Analyze Computer Now option
Provide a log name for the analysis
After the analysis is complete, scan through the nodes to view the results, as shown in Figure 1.
Figure 1. Results of running an
analysis using a security tempalte.
Click image to enlargeIf these steps seem a bit strange, let me explain why they are used and what is happening along the way.
A security template can't be compared natively to a live computer. The security template must be converted into a neutral format for the analysis. This is why step 9 requires that you create a database. Notice, too, that in step 11 you select which security template will be placed in the database. This database is the neutral form that is used to compare the configurations of the security template against the actual settings of the computer.
Method #2: SCA in a Script Command
The other method used to audit a computer's security with a security template is to use the command line version of SCA in a script. The command line tool used is SECEDIT.EXE. This allows for an analysis mode, which results in the same information as the SCA method. The syntax you use for the script would be:
SECEDIT /analyze /db db1.sdb cfg sectemplatename.inf /log logname.log
The target computer will be analyzed using a database name of db1.sdb, a security template named sectplatename.inf, and a log file of logname.log. These names can be anything that you want.
Analyzing the Results
The analysis of the results is rather straightforward. You will focus on the icons that indicate whether the settings on the computer meet or fall short of the baseline security settings in the security template. Figure 2 shows an example of an audit result using the SCA.
Figure 2. Audit results using
the SCA with a baseline security template.
Click image to enlargeThere might be many computer settings don't meet the security template settings. These are clearly indicated by a red "X." The settings in the security template are displayed in the Database Settings column. The Computer Settings column shows the settings that are configured on the computer.
Since the security template you use to analyze the computer mirrors the security baseline, the audit report will consist of all of the red "X" settings.
Auditing What's Left
We could not audit the patches, service packs, shares, or users with the security templates, since templates don't include these settings. However, I want to be sure to explain how you could audit these settings. Here are the control points and the tools you would use to audit them:
Patches: The best tool is the Microsoft Baseline Security Analyzer (MBSA). It provides a GUI method to gather information related to all of the security patches that are, and are not, installed. The tool can be downloaded for free from Microsoft at http://www.microsoft.com/technet/security/tools/mbsahome.mspx.
Service packs: The best way to get information related to the current service pack level is to look on the System Properties sheet, which can be accessed from the Control Panel on any computer.
Shares: The best tool for the job of gathering information about shares on the computer is DumpSec, which provides information about the shares and the share permissions.
Users: For both local users and domain users, you can use the DumpSec tool to gather the list of users, as well as the full list of properties for each user.
The Next Step
Now you have all the information required to establish security baselines, implement baselines, and then audit the baseline security using security templates. For the auditing step, you need to get the security templates that correspond to the different computers on the network. Then, pick a method that suits you best, either using the SCA or the command line option.
After the audit is complete, analyze the information for your report. Finally, there are a few outstanding settings that aren't covered in the security template that you can quickly gather using the tools presented here.
Additional articles by Derek Melber