Running SCW from the Command Line
SCW comes with a command-line utility called scwcmd.exe. Table 1 lists the Scwcmd switches and their descriptions. Let's look at some Scwcmd command examples. To perform an Scwcmd analysis on the local machine by using the SCW security policy file fileserver.xml, you'd use the command
scwcmd analyze /p:%windir%\
security\msscw\policies\fileserver.xml
(of course, when using this command and the ones below, you'd type them all on one line). To transform the output of an Scwcmd analysis that's stored in w2k3-dc1.xml into an XML document that's formatted according to the scwanalysis.xsl stylesheet, you'd use the command
scwcmd view /x:"c:\documents
and settings\administrator\
w2k3-dc1.xml" /s:%windir%\
security\msscw\transformfiles\
scwanalysis.xsl
Web Figure 2 shows some formatted analysis results.
To transform the SCW security policy file fileserver.xml into a GPO called FileServerPolicy, you'd use the command
scwcmd transform /p:%windir%\
security\msscw\policies\
fileserver.xml /g:FileServerPolicy
The transformation creates a GPO folder for the newly created GPO object in the Sysvol folder. The GPO folder contains the following data:
- an .inf file for the security settings GPO extension
- a .pol file for the Windows Firewall GPO extension
- an IPSec blob for the IPSec GPO extension
SCW IIS settings don't survive an SCW-to-GPO transformation.
After you successfully create a GPO, you can link it to an AD organizational unit (OU) to apply the SCW settings to the machines stored in the OU. The transform operation must be initiated by a domain administrator on a machine to which the SCW security policy will be deployed. The target machine(s) shouldn't have SCW installed, but they do need Windows 2003 SP1 because Windows Firewall and Windows Firewall GPO configuration are supported only by Windows 2003 SP1 and later. To make sure the newly created GPO is applied only to Windows 2003 SP1 machines, you should ensure that the OU you're linking the GPO to contains only SP1 machines or create a GPO Windows Management Instrumentation (WMI) filter that excludes pre-SP1 machines from the GPO application.
Transforming your SCW security policy to a GPO is a must if your organization uses GPOs extensively. If you don't transform the SCW settings into a GPO, they might be overridden by the settings defined in other GPOs at the AD level.
One more, very interesting Scwcmd command example applies different SCW security policy files to different machines. When you execute the command
scwcmd configure
/i:legaldepartment.xml
a local application of the SCW security policy is initiated on each of the remote machines as specified in the legaldepartment.xml configuration file, which Listing 1 shows.
SCW File System Folders and Documents
SCW-related data and files are stored in the %windir%/security/msscw file system folder. Important folders in the Msscw folder are:
- the Kbs folder, which holds the knowledge-base files for SCW-supported server roles. If you want to add new server roles, you must store the corresponding knowledge-base files in this folder. The kbreg.xml file, which Web Listing 1 shows, lists the registered SCW knowledge-base files.
- the Logs folder, which contains SCW log files.
- the Policies folder, which contains security policies created by using SCW.
- the Transformfiles folder, which contains XML stylesheets (.xsl files) that you can use to format SCW output files (as the second command example I mentioned and Web Figure 2 show).
Security Tool Overlap
SCW is an important addition to Microsoft's security policy management portfolio. The tool can be used for security policy authoring, application, and auditing. However, its introduction emphasizes the fact that Microsoft's security policy management portfolio—which now includes GPOs, SCE, and SCW—urgently needs some alignment. Each of these tools can manage different aspects of a Windows security policy, but none of them covers all Windows security-related settings.
Both SCW and SCE are security policy authoring tools. SCW is a specialized authoring tool for reducing a system's attack surface, and it has a knowledge base to leverage, which makes life a lot easier for administrators. Generally speaking, SCE has a broader scope than SCW, but it can't deal with system port configuration, and it lacks intelligence that can propose a preferred security configuration based on the machine's organizational role. SCE has good Help files that offer basic guidance, but administrators are still pretty much on their own for defining security policy settings.
Both SCW and SCE can be used for security policy auditing, but again, SCW focuses on reducing the attack surface and provides intelligent configuration help, and SCE has a broader scope and doesn't recommend settings.
In standalone machine environments, you can use SCW for security policy application on individual machines or groups of machines; the easiest way to do so is from the command line using Scwcmd. Using SCW for security policy application in Windows domain environments isn't recommended; here the best option is to transform the SCW security policy settings into GPO settings, then apply the security policies through GPOs. It's interesting that SCW doesn't natively support the .inf security configuration files that SCE and GPOs use. SCW uses XML instead. As I pointed out earlier, SCW XML files can be translated into GPO-compatible files, and .inf-formatted files can be imported into SCW.
End of Article
Register
