Video Screencast Help

Customizing Rules in SecurityExpressions

Created: 13 Feb 2007 • Updated: 04 Mar 2008 | 5 comments
Language Translations
amaniscalco's picture
+2 2 Votes
Login to vote

To get the most out of SecurityExpressions, whether you're using it stand alone or as a part of the Audit Integration Component, you should be customizing policy files and rules that meet your organization's unique auditing needs. Here's an article that will get you started. This article assumes you're familiar with SecurityExpressions and auditing for security compliance, but haven't taken the plunge into policy and rule writing.

You already knew that SecurityExpressions lets you apply security policies to your organization's computers by deploying policies predefined by expert organizations such as the Center for Information Security (CIS), the National Security Agency (NSA), SANS (SysAdmin, Audit, Network, Security), and Microsoft. But did you know that the best practice in security auditing is to create your own policy files that support your organization's unique security policies, consisting of a custom set of rules from existing policy files and rules you designed yourself? The auditing process takes time. Instead of auditing the same computers against each policy file that happens to contain relevant rules, you can combine those rules into one policy file that enforces your organization's security policies.

Why Customize?

Generic best practice-based offerings are an ideal starting point but your policy must also reflect industry-specific regulations and your unique business processes. Uniform compliance with your security policies should exist on all workstations and servers across the organization.

Customizable policies allow for 100 percent compliance with unique security policies. The application allows you to use, edit, or adapt existing rules or create new rules.

The following list suggests some of the reasons to create custom rules:

  • Set any computer-level setting
  • Configure computer policy settings
  • Change or set any registry key
  • Verify or change users, groups, user rights, and user account policies
  • Verify or change key permissions or file permissions
  • Ensure password compliance and disable accounts with weak passwords
  • Detect operating computers
  • Determine software inventory
  • Ensure antivirus definition files are current
  • Identify software versions
  • Execute remote software installations
  • Detect hardware devices
  • Detect unauthorized network devices
Methods for Customizing Policy Files

SecurityExpressions includes three security-management interfaces: SecurityExpressions™ Console, Security Expressions™ Audit and Compliance Server, and AuditExpress™. They are used together, each offering its own unique combination of auditing and compliance features optimized by different kinds of networking technology. SecurityExpressions Console, a Windows application with the flexibility to run on servers or workstations, is the application that lets you customize policy files and rules.

We recommend that you locate a policy file that has a rule that is similar to your needs, drag it to your Rule List, and then modify or edit it to meet your needs. An alternative method is to create a new policy file and add custom rules.

If you modify the policies installed with the software, save them under a new name. Not only does this preserve the original policy file, but it also ensures your modifications carry over when you upgrade the software. Upgrading the software updates all SIF files included with the software.

Another method to get started writing policy files for Windows 2000 computers is to import one of Microsoft's Group Policy Template files. You can find these files with an .inf extension in the \WINNT\security\templates folder of your Windows 2000 computer. Additionally, you can create these files using the export feature found in the Local Security Policy Microsoft Management Console (MMC) snap-in. To import a template file (*.inf), start the application, and then select Import Security Template from the File menu.

Editing Existing Policies

To edit existing policies, use one of the following two methods:

  1. Change settings to match a specific computer.
  2. Change settings individually to desired settings.

Changing Settings to Match an Existing Computer

To change settings to match a specific computer, first audit a computer with the desired settings using an existing policy file. To change the settings in the policy file to match the audited computer, right-click the rule you want to change, and choose Update rule with current value from the menu.

Choosing the menu option, Update all rules with current value, changes all settings in the policy file to match the audited computer.

Understanding Policy Files and Rules

A policy file is a configuration file that checks a computer for evidence of whether or not the computer complies with corporate policies. Policy files consist of rules that check a computer for particular conditions, settings, hardware, and software. Policy files have a .sif extension. The file format is the standard INI format used by many Windows applications. It consists of sections and a list of key/value pairs for each section.

Anatomy of a Rule

A rule consists of a series of key/value pairs that describe the desired state to check.

Policy File Sections

A Policy File section begins with a prefix and a name enclosed in square brackets ([ ]).

Sections begin with a prefix followed by a colon (:) and a unique name, such as:


A list of key/value pairs that define the different parameters follows the section header.


For example, the prefix for [Rule:AuditBackup] is Rule and the name is AuditBackup. A series of key/value pairs follows the name, such as



Description=Enable audits of backups and restores




In this example, the section is named Rule:AuditBackup. The keys are Description, Key, Name, and Value. The value of each key value follows the equal sign (=).

The following rule is a registry check.








Warn=CrashOnAuditFail can stop a business completely. Use it only where audit logs are absolutely critical.

Description=If you need absolute assurance that the audit logs are complete and accurate, set this key so that the computer will stop operating if the audit logs run out of space.

MoreInfo=If events cannot be written to the security log, the computer is halted immediately. If the computer halts as a result of a full log, an administrator must log onto the computer and clear the log.%NL%%NL%NOTE: Before clearing the security log, save the data to disk.%NL%%NL%WARNING: Enabling this option will disallow any connections to the computer until the audit logs are cleared. Take caution when enabling this on critical computers. Also, enabling this option on a large number of workstations in the network may result in much overhead when the logs become full.

Evaluating Rules

When you audit your computers, the application evaluates three entities, in the following order:

  • Machine Lists – a group of computers to audit
  • Rule Lists – a set of Rules. When you select a specific Rule List to apply to a Machine List, the application checks all Rules that comprise the set of Rules to use when auditing computers in the Machine List. If a computer is a member of more than one Machine List, all rules from its memberships are used.
  • Rules – information about what to check and how to fix it

The following flowchart identifies the process.


Click to view.

Entity Relationships

Machine Lists, Rule Lists, and Rules are interrelated and have the capability for many-to-many relationships.

  • Machine Lists can contain Rule Lists. The Machine List references Rule Lists to decide which rules to run for a particular computer.
  • Each Rule can have its own dependencies. Rules can belong to one or more Rule Lists.
  • A Rule and a Rule List can be dependent on other Rules to decide if the Rule or the Rule List applies.

Relationships among Rules, Rule Lists, Machine Lists, and the computer

Click to view.

Machine List Examples

The following example illustrates a Machine List that contains a list for a Domain Controller and a Workstation and the corresponding Rule Lists.

Consider the environment where the Domain Controller Machine List consists of a Windows 2000 and Domain Controller filter. This Machine List also contains the Rule Lists named Server Rules and W2K Rules. Server Rules consists of two rules, Rule1 and Rule2, and W2K Rules consists of three rules, Rule3, Rule4, and Rule5.

The Workstation Machine List has a Windows 2000 filter and consists of the Rule List named W2K Rules. W2K Rules consists of three rules, Rule3, Rule4, and Rule5.

With these Machine Lists and Rule Lists, consider these cases and answer these questions.

Case 1

Computer ABC is a Windows 2000 Domain Controller.

Which Rules apply?

Answer: Rule1, Rule2, Rule3, Rule4, Rule 5.

Server Rules (Rule1, Rule2) and the W2K Rules (Rule3, Rule4, Rule5) apply because the filter includes Windows 2000 and Domain Controller.

Case 2

Computer XYZ is a Windows 2000 computer. Which Rules apply?

Answer: Rule3, Rule4, Rule 5.

The Windows 2000 filter includes both Windows 2000 and Windows XP. The 2000 only option includes Windows 2000 only.

Rule List Criteria

The Rule List Criteria is a Rule Expression using any of the rules in the current policy. The Criteria determines whether the Rule List is applicable to the audited computer. Rule Expressions evaluate to OK (true) or NOT OK (false). If OK, the Rule List is applicable and the member rules will be evaluated. If NOT OK, none of the member rules are evaluated. The Criteria is a logical Boolean expression using a standard notation that must be met.

Naming Restrictions

Names of Rules, Rule Lists, Machine Lists, WizParams, and other named policy file objects must adhere to these naming conventions.

Names may consist of combinations of any standard character with the following exceptions:

You cannot use any of the following characters in the name:
Restricted Character Description
, Comma
| Vertical Bar
[ Left Bracket
] Right Bracket
: Colon
( Left Parenthesis
) Right Parenthesis

Variables are a key/value pair used by Rules to store frequently used information. Variables exist in Rules, Machine Lists, and a Global section in a policy file called Global Variable.

Variables may contain other variables in the Value section of the Security Policy File. Circular references are not allowed. The Key section of the file may only contain letters, numbers, and underscore ( _ ).

To reference variables in Rules, enclose the variable name with the percent (%) character. For example, %StdPerm% would be substituted by the value of StdPerm. With such a reference, first the application considers the current rule. If a key exists with that name, it substitutes its value. If not, it looks at the active Machine List. If it has a variable with that name, that value will be used. If not, the global variables are used. If a variable does not exist, it is blank.

Variables are evaluated when the rule is evaluated. The order of evaluation is:

  • Current rule
  • Machine Lists, of which the audited computer is a member
  • Global variables section
  • Built-in variable

You can alter this order using a different format. To specify an alternative search order, begin with a %. Enter one or more path keywords separated by a comma (,). Next, type a colon (:) and the variable name. The keywords represent Machine Lists or special codes indicating the current rule (RULE), or the member Machine Lists (ML). For example, %ML:RULE:perms%, searches in the member Machine Lists first and then the rule for the variable <perms>. %ServerList:perms% would search for variable <perms> only in the Machine List named ServerList.

Policy files contain Global variables and Machine List variables that require a specific syntax.

Global Variables – Global variables are specified globally. You access global variables from Rules. For example, %GVar% is substituted with the value of GVar when you audit.
Machine List Variables – Machine List variables are specified on specific Machine Lists. You access Machine List variables from rules. For example, %GVar% is substituted with the value of Gvar from the current Machine List when you audit.
Specify global variables by right-clicking Machine Lists in the Audit tab and Machine List variables by right-clicking a specific Machine List, and then selecting Edit.

SEVersion Variable Example

The following rule illustrates the variables that identify the software release.

[Rule:New Rule]
Description=%sxversion% -- %seversion% -- %seversion_major% --
%seversion_minor% -- %seversion_release%


Returns the Description: 3.1 -- 3.1.1 -- 3 -- 1 -- 1

Variables in Security Policy Files

In the global section, variables are represented in Key=Value format, such as:




When specified in a Machine List, the variables are stored in the Filter section and prefix Var: is prepended to the key such as:




When specified in a Rule, the variables are in Key=Value format, such as:




Description=Make sure you use %StdPerm% for creating new files


Functions allow you to manipulate strings and perform operations that rules might require. The format to call a function is %<function name>(argument, argument, ...)

For example, the function


returns the last path component, FILE1.DAT.

Functions can contain variables as their argument.

The function


evaluates %File% and then extracts the last path component. If File=D:\TEST\FILE1.DAT, the result is FILE1.DAT.

Creating Custom Rules

Each custom rule reflects a specific item in your system security policy. Before you create the rule, you must determine how you want to check the computer against that item, and how to fix it if it is not compliant with your policy. The product provides a complete set of tools to allow you to create rules for most policies and run custom scripts or executables for more complex tasks.

You can create a new policy file with custom rules, or you can modify an existing policy file.

  1. Start the application and select New from the File menu. The application creates a blank security policy file.
  2. Right-click in the Rules tab and select Add new rule from the menu. Create the rules necessary for your security policy using the Rules Wizard.
  3. From the File menu, select Save and name the file.
Simple Rule Writing Example

This tutorial is a step-by-step example of simple rule. This rule ascertains that the logon caption contains some standard text. This text will appear every time someone tries to log on to this computer and usually contains a message forbidding unauthorized access. The registry stores this text, so this rule modifies a registry value.

  1. The Rules tab is where rules are modified. Right-click the rules list (which in this example is empty) and choose Add new rule.
  2. A new rule, named New Rule appears. Type the name for the rule, such as Caption.
  3. Click the Rule Type tab. Expand Registry and select Value because this check involves a registry value. Press F1 to see descriptions for all check types.
  4. Return to the Wizard tab. To choose the Registry key you want to modify, Click Select for the Key.

    A Registry browser opens. Expand the tree until you find the appropriate key. In this example that key is:

    • HKLM
    • Microsoft
    • CurrentVersion
    • Winlogon

    At any time, press F1 to get more help on the selected item.

  5. After you find the key, select it and click OK.
  6. On the Wizard tab, click Select and browse for the Name.
  7. The Registry browser opened to the right key. Select the value name and click OK.
  8. Type a Value, which is text that you want displayed in the Value box.
  9. On the Parameters tab, select Description and type a short description for the rule.

    Remember to click Save to make the changes effective.

Now your rule is ready for use for an audit.

Comments 5 CommentsJump to latest comment

erikw's picture

This is a good explanation. I'm using Exclusions now to develop new business. It is a great product with some very good features.



Regards Erik Dinamiqs is the home of VirtualStorm (

If your issue has been solved, Please mark it as solved

Login to vote
kasipramod's picture

Hi I need help in SE in creating sif files.
can you please help me out.

Login to vote
ahumphries's picture

Great Intro to Security Expressions. I've been working with this product for a good 6 months now and still learning about it. Thought I'd check out this article. Very well written article.

Login to vote
kasipramod's picture

Hi all I am very New to Security Expressoins

I have a question How to write rule for this type of document, If anyone could help me in this I will write rest of the rules.
I have been asked to write a rule by looking at this document.

Check Reference Numbering Scheme:
The checks use two different reference numbers: the ABCID and CDKEY. The ABCID is a manually assigned reference number. The database STIGID assignments including those for SQL Server begin with two letters that indicate the following:
 BC – This is a General database check and the fundamental requirement is required of any DBMS product where available.
 DM – This is a Microsoft SQL Server specific check and does not apply as written to any other DBMS products.
 DO – This is an Oracle specific check and does not apply as written to any other DBMS products.
 DI – This is an IBM DB2 specific check and does not apply as written to any other DBMS products.
Only checks of type “BC” are included in this checklist and may be mapped to the security requirement as listed in the Database STIG.

3.6 Documentation Conventions:
Conventions used in this document:
 The “< >” characters are used to indicate that a replacement value provided by the reviewer is required. For example, the query command “ use ‘’ should be replaced by the reviewer with the appropriate database name as “ use ‘master’ “. The “<>” characters should not be included in the command.
3.7 BC0001: DBMS version support
Description: Unsupported software versions are not patched by vendors to address newly discovered security versions. An unpatched version is vulnerable to attack.

Follow the vendor instruction for determining the product version number.
View the vendor-provided list of supported versions. To be considered supported, the vendor must report that the version is supported by security patches to reported vulnerabilities.

If the security patch support for the installed version cannot be determined or the version is not shown as supported, then this is a Finding.

If the installation is not connected to a production network and is on an isolated development or test network segment and an upgrade plan is in place, then the severity of this finding may be downgraded to a CAT 2 finding.
Develop and implement a plan to upgrade to a vendor-supported DBMS version.

VKEY:V0005658 Severity:CAT1 Gold:True MAC/CONF:- 1-CSP;2-
IA Control: CheckType: Manual
VIVM EngineLevel:True Res:IAO DOC:FALSE

Reference:Database ABC 3.6.1

ABC Requirement:(BC0001: CAT I) The IAO will ensure unsupported DBMS software is removed or upgraded prior to a vendor dropping support.


Login to vote
jroach21's picture

I was reading through the example of how to create a custom rule and found that on my machine for Step 4, the registry is as follows:

-windows NT

Login to vote