A security check is a query against the Secure Configuration Manager database represented by the namespace. You can query for a list of users, a list of registry keys, or any object defined in the namespace. You can select the attributes of the object you want returned in the list. You can also filter the list by selecting values of interest for any or all of the attributes available.
The query returns a list of all objects and their attributes that meet the filter criteria. You can view the information as a full report. If you do not want the details, you can request a simple count, or weighted score, of the number of items that fit the criteria. If each item represents a point of vulnerability, then the resulting score is a measure of the endpoint’s total vulnerability for that security issue. For more information about risk scoring, see Understanding Risk Scoring.
For example, you can create a custom security check that allows you to query for a list of users, but limit that list to users without passwords. You can report these users as a number, or score, identifying the magnitude of the threat. You can also return the users in a list. You can then issue warnings or lock accounts to remedy the vulnerability.
For convenience and efficient identification, Secure Configuration Manager organizes security checks by platform and category. The category specifies the type of security check. Secure Configuration Manager automatically includes the following categories:
Audit/Auth Analysis
Data/Databases
Files/Directories
GPO
Internet/Network
Software/Apps
System
User/Groups
When you edit or create a custom security check, you can specify one of the available categories, create a new category, or leave the check uncategorized.
When editing or creating custom security checks, you can add a filter to the check to reduce the amount of data returned in a query. A filter is a logical expression built using specified values of an attribute of an object. These attributes do not have to be the same attributes that you have selected to return as columns. Each instance of the object that satisfies the criteria set by the filters becomes a row returned from the query.
When creating a single filter, specify the following items:
Attribute
Operator
Type
Criterion
When you create a set of filters, also specify the following logic of how the filters combine:
AND/OR
Left and right parentheses
NOTE:Parentheses can be nested. There is a limit of ten nested parentheses.
NOT
When used in a filter, attributes are the characteristics of an object that determine whether rows of data are included in the returned data set. For example, a query on the Unix_Process object returns a list of all running processes. If you are concerned only with those processes owned by certain users, you can use the Owner Name attribute to limit the returned data.
An operator is the comparator between the attribute and the value of the criterion. Certain operators are available only to specific data types. The Security Check wizard provides the following operators.
Operator |
Function |
---|---|
equals |
Select all objects for which the value of an attribute is equal to the criterion. |
not equal to |
Select all objects for which the value of an attribute is not equal to the criterion. |
less than |
Select all objects for which the value of an attribute is less than the criterion. |
less than or equal to |
Select all objects for which the value of an attribute is less than or equal to the criterion. |
greater than |
Select all objects for which the value of an attribute is greater than the criterion. |
greater than or equal to |
Select all objects for which the value of an attribute is greater than or equal to the criterion. |
contains |
Select all objects for which an attribute contains the criterion. Using this operator to compare strings, the comparison is true if the criterion is a substring of the attribute. For example, File/Dir Name contains .ini would return all initialization files. |
not contains |
Select all objects for which an attribute does not contain the criterion. |
is any one of |
Select all objects for which an attribute matches any one of the criteria. |
is not any one of |
Select all objects for which an attribute does not match any one of the criteria. |
is included in saved list |
Select all objects for which an attribute is included in the saved list specified by the criterion. For more information about saved lists, see Excluding Values from a Run. |
is not included in saved list |
Select all objects for which an attribute is not included in the saved list specified by the criterion. For more information about saved lists, see Excluding Values from a Run. |
matches regular expression |
Select all objects for which an attribute matches the regular expression described by the criterion. For more information about regular expressions, see Regular Expressions in the Filter. |
does not match regular expression |
Select all objects for which an attribute does not match the regular expression described by the criterion. For more information about regular expressions, see Regular Expressions in the Filter. |
The filter type category refers to the choice between using a value or a user parameter for the criterion. When you set a criterion as a value in a security check, you cannot modify it without altering the security check itself. When you set a criterion as a user parameter, you can modify the value each time you run the policy template that contains the security check. For more information about policy templates, see Understanding Policy Templates.
The query compares the value of the attribute to the criterion listed for the filtered attribute. The criterion must be of the appropriate input type and in the appropriate format for the attribute in question for the comparison to be valid. For example, if you select Owner Name as the attribute, the matching criterion must be in the format of a user name: root, johnd, or projmgr.
Regular expressions are a criteria type that allow you to perform advanced text pattern matching against string data types. Regular expressions provide more flexibility than simple wildcard characters. To match an exact regular expression symbol, precede the symbol with a backslash (\).
Regular Expression Symbol |
Description |
---|---|
. |
Matches any single character. |
[ ] |
Matches any single character from within the bracketed list. Within square brackets, most characters are interpreted literally. |
[^] |
Specifies a set of characters not to be matched. |
^ |
Matches the beginning of a line. |
$ |
Matches the end of a line. |
| |
Matches either the regular expression preceding it or the regular expression following it. |
( ) |
Groups one or more regular expressions to establish a logical regular expression consisting of sub-regular expressions. Used to override the standard precedence of specific operators. |
! |
Specifies that the following regular expression is not matched. |
? |
Specifies that the preceding regular expression is matched 0 or 1 time. |
* |
Specifies that the preceding regular expression is matched 0 or more times. |
+ |
Specifies that the preceding regular expression is matched 1 or more times. |
{n} |
Specifies that the preceding regular expression is matched exactly n number of times. |
{n,} |
Specifies that the preceding regular expression is matched n or more times. |
{,n} |
Specifies that the preceding regular expression is matched n or fewer times. |
{n,m} |
Specifies that the preceding regular expression is matched a maximum of m times and a minimum of n times. |
\n |
Matches a new line. |
\t |
Matches a tab character. |
The following table provides examples of regular expressions and their matches.
Example |
Matches |
Does Not Match |
---|---|---|
st.n |
Austin and Houston |
Webster |
st[io]n |
Austin and Houston |
Stanton |
st[^io]n |
Stanton |
Houston or Austin |
^Houston |
Houston |
South Houston or Fort Sam Houston |
ston$ |
Houston and Galveston |
Stonewall |
dall|hart |
Dallas and Dalhart and Lockhart |
Dale |
dal(l|h)art |
Dalhart |
Dallas or Lockhart |
il?e$ |
Etoile and Wylie |
Beeville |
il*e$ |
Etoile and Wylie and Beeville |
Bellaire |
il+e$ |
Etoile and Beeville |
Wylie |
ad{2} |
Addison and Caddo |
Adkins |
(la.*){2,} |
Highland Village and Lake Dallas |
Laredo |
il{,1}e$ |
Bowie and Etoile |
Brownsville |
(a.*){2,3} |
Alamo Heights and La Blanca |
Austin or Aransas Pass |
not ville |
Houston and Dallas |
Brownsville |
You can logically combine individual filters in two ways. You can combine consecutive filters with the logical tags of AND or OR, and you can combine groups of consecutive filters with parentheses to separate groups of filters from each other.
For example, if A, B, C and D are your filters, the following examples illustrate various logical combinations:
A AND B AND C AND D
(A AND B) OR (C AND D)
(A OR B) AND (C OR D)
(A OR B OR C) AND D
Another example is the following filter requirement: “Check for all remote users without administrative accounts who have umask values not equal to 027 or 077, or whose password strengths are greater than 0.” This filter requirement can be represented logically as:
((Primary Group ID > 10) AND (Local or Remote Account = Remote)) AND (((umask Value != 027) OR (umask Value != 077)) OR (Password Strength != 0))
When creating a filter for a custom check, you can set a criterion as a value for every run of the security check level, or you can set the criterion as a user parameter to be selected each time you run the security check. For example, you can create a security check with the Owner Name attribute of the Unix_Process object as a filter. If you save the check with the specific value of root, when you add the security check to a policy template, the check always run with the filter criteria set as root. If you save the attribute as a user parameter, you can edit the value within the policy template and run the same check multiple times with multiple filter criteria for that attribute.
In other words, instead of creating several similar security checks for use in a custom policy template, you can create one generic security check with the attribute saved as a user parameter. Then, when you create the policy template, you include multiple instances of the generic security check where each instance specifies a different value for the user parameter.
The following figure shows the creation of a user parameter within a custom security check.
The following figure shows the security check and the user parameter as it would appear in a policy template.
Verify all entered values for data type and format. The wizard does not validate user-specified parameter values.
The property data of a security check is the information about the check that is visible in the Secure Configuration Manager console and at the policy template level. The data consists of the following properties:
Check name
Category
Brief description
Detailed explanation
References
Risks associated with this check and the environment when the violations are not remedied
Remedies for violations of this check
When you modify or create a custom security check, ensure that you include relevant information for each check property. These properties provide other users with the information they need to decide whether this security check is appropriate.