Table Of Contents
Configuring Variables and State Conditions
Overview
Where Variables are Used
Display only Show All mode Option
COM Component Sets
COM Component Extract Utility
Data Sets
File Sets
Network Address Sets
Network Interface Sets
Network Services
Notification Settings
Query Settings
Notification and Query Tokens and Syntax
Localized Language Version Support
Registry Sets
Included Registry Sets
Setting State Conditions
System State Sets
User State Sets
Configuring Variables and State Conditions
Overview
Configuration variables are named configuration data items that you create for repeated use in other configuration items such as file access control rules, network access control rules, and alerts. You can group files together, as well as network addresses, and network services. Once configured, you enter these global variables in corresponding fields for other CSA MC items.
You use configuration variables to help build the rules that form your policies. Using variables makes it easy for you to maintain policies by letting you make any necessary modifications in one place and having those changes instantiated across all rules and policies.
System State and User State conditions let you write conditional rules based on the state of a system or the user of the system. Therefore, rules are only applied if the configured conditional settings are met.
This section contains the following topics.
•
Where Variables are Used
•COM Component Sets
–COM Component Extract Utility
•Data Sets
•File Sets
•Network Address Sets
•Network Interface Sets
•Network Services
•Notification Settings
•Query Settings
•Notification and Query Tokens and Syntax
•Localized Language Version Support
•Registry Sets
•Setting State Conditions
–System State Sets
–User State Sets
Where Variables are Used
The following section shows how variables relate to access control rules. Available Variables types (COM Component Sets, Data Sets, Event Sets, File Sets, Network Address Sets, Network Interface Sets, Network Services, Query Settings, and Registry Sets) are shown on the left and the rule types or other configuration pages they can be applied to are shown below them.
•Variable type: COM Component Sets
–COM Component access control rules
•Variable type: Data Sets
–Data access control rules
•Variable type: Event Sets
–Alerts
–Reports
•Variable type: Files Sets
–Application classes
–File access control rules
•Variable type: Network Address Sets
–Connection rating limiting rules
–Network access control rules
–Network shield rules
•Variable type: Network Interface Sets
–Connection rating limiting rules
–Network access control rules
–Network shield rules
•Variable type: Network Services
–Network access control rules
•Variable type: Query Settings
–All access control query rules
•Variable type: Registry Sets
–Registry access control rules
Note Using variables is generally optional. Nearly all the information used in variable configurations can also be entered directly into corresponding rule configuration fields. Variables are simply a tool meant to simplify the creation of rules, especially if the same configurations are used in multiple rules.
Note You can use the Compare button in Variable list views to compare and merge similar variables. See Comparing Configurations, page 5-10 for details on using the Compare tool.
See for Chapter 10, "Event Logging and Alerts" details on configuring Event Sets.
Display only Show All mode Option
Each individual variable page (including Application Classes) contains a Display only in Show All mode checkbox. If your lists of variables are growing too long in rule or application configuration pages, clicking the Display only in Show All mode checkbox on a variable page causes that variable to no longer appear in lists for that variable type. To display hidden items, you must go to the Admin Preferences page and choose another admin preferences that Always uses Show All mode or change the preference assigned to you. See Configuring Role-Based Administration, page 2-14.
COM Component Sets
Configure COM component sets for use in COM component access control rules. COM objects are groupings of COM Program IDs (PROGID's)
and/or COM Class IDs (CLSID's) under one common name. This name is then used in COM component access control rules to allow or deny access to the COM component set name. All COM components that match the entries of a given component set are relevant to the rule in which the set is used.
You can also use pattern matching when creating COM component sets. For example, entering "Word.*" would match "Word.Application" and "Word.Document".
CSA MC ships with several pre-configured COM component sets you can use as well.
Note This is not available for UNIX configurations.
Note CSA MC provides a COM component import utility which installs with each Cisco Security Agent. Running this utility extracts all COM component PROGID's and CLSID's for software running on the system in question. See page 6 for instructions.
To configure a COM component set, do the following.
Step 1 From the menu bar Configuration drop-down list, move the mouse over Variables. A cascading menu with further selections appears.
Step 2 Select COM Component Sets from the cascading menu. Any existing COM component set configurations are shown.
Step 3 Click the New button to create a new COM component set. This takes you to the configuration view (see Figure 9-1).
Step 4 In the available edit fields, enter the following information (See Using the Correct Syntax, page 2-41. You can also click the Quick Help question mark beside each field for syntax information.):
•Name—This is a unique name for this COM component set. Generally, it's a good idea to adopt a naming convention that lets you quickly enter COM component set names in a corresponding rule configuration field.
•Description—This is a line of text that is displayed in the list view helping you to identify this particular COM component set configuration.
•Display only in Show All mode—If your lists of variables are growing too long in rule or application configuration pages, clicking the Display only in Show All mode checkbox on a variable page causes that variable to no longer appear in selection lists for that variable type. This feature works in conjunction with Admin Preference settings. You must go the Admin Preferences page to make the item reappear. See Configuring Role-Based Administration, page 2-14.
Step 5 PROGID's/CLSID's matching—Enter the COM component PROGID's or CLSID's here (one per line) to which you want to impose restrictions.
By default, this field has an <all> entry indicating all PROGID's and CLSID's. When you click inside this field, the <all> disappears so that you can enter your own restrictions.
When entering PROGID's, use syntax as shown in the following example:
When entering CLSID's (uppercase hexadecimals), using the following syntax (You must include the brackets shown here.):
{000209FF-0000-0000-C000-000000000046}
Step 6 but not—Make exceptions to PROGID's or CLSID's you've entered in the PROGID's/CLSID's matching field.
By default, this field has a <none> entry indicating no exceptions. When you click inside this field, the <none> disappears so that you can enter your own exceptions.
When all required information is entered, click the Save button to save your COM component set in the CSA MC database.
Figure 9-1 COM Component Set Configuration View
COM Component Extract Utility
CSA MC provides a COM component extraction utility, called extract_com, which installs in the Cisco\CSAgent\bin directory with each Cisco Security Agent. Running this utility extracts all COM component PROGID's and CLSID's for software installed on the system in question and places this data into a text file. You can cut and paste these ID's from the text file into your COM component sets and access rules.
See Using the COM Extract Utility, page 12-11.
Data Sets
Configure data sets for use in data access control rules. Data sets are groupings of data strings under one common name. These strings represent either a set of patterns that will be matched against the URI portion of HTTP requests or MSRPC and LPC patterns for signature matching. The name of the data set is then used in rules that control data access permissions and restrictions. All the data parameters that exist under that name are then applied to the rule where the name is used.
CSA MC ships with several pre-configured Data Sets you can use. The pre-configured data sets group URI patterns to match based upon the following:
•functional associations of meta-characters (e.g. "(" and ")")
•examples of known classes of attacks
•Web server specific exploits
The pre-configured data sets groups for signatures match based upon the following:
•MSRPC Interface ID
•LPC Interface ID
The following is an example of an HTTP request attempting to execute an attack by invoking a command shell to obtain a directory listing. A data set of this syntax, *cmd.exe*, would stop not only this exploit but any other exploit trying to make use of a command shell.
GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+dir
Note Not all pre-configured data sets are used in pre-configured policies. For example, some attack fingerprints or command arguments might be acceptable on one deployment of a web server, but not be acceptable for a different deployment. Therefore, pre-configured data sets used in shipped policies may require modification if legitimate, but blocked meta-characters are being used by a web server.
Note Additionally, modifying the preconfigured data sets allows you to block a pattern which specifically matches a new/old exploit or attack.
Note Data access control rules specifying HTTP protocol data sets are not supported for desktop versions of Windows operating systems.
To configure a data set, do the following.
Step 1 From the menu bar Configuration drop-down list, move the mouse over Variables. A cascading menu with further selections appears.
Step 2 Select Data Sets from the cascading menu. Any existing data set configurations are shown.
Step 3 Click the New button to create a new data set. This takes you to the data set configuration view.
Step 4 Name the data set. This is a unique name for this data set. Generally, it's a good idea to adopt a naming convention that lets you quickly enter data set names in a corresponding rule configuration field.
Step 5 Describe the data set. The text you put in the Description field is displayed in the list view helping you to identify this particular data set configuration.
Step 6 Configure Display only in Show All mode—If your lists of variables are growing too long in rule or application configuration pages, clicking the Display only in Show All mode checkbox on a variable page causes that variable to no longer appear in selection lists for that variable type. This feature works in conjunction with Admin Preference settings. You must go the Admin Preferences page to make the item reappear. See Configuring Role-Based Administration, page 2-14.
Step 7 Protocol—Select the protocol for which you are configuring this data set. See Data Set Interface Matching Syntax, page 2-55 and Data Set Pattern Matching Syntax, page 2-55 for syntax requirements and examples.
•All:
–Patterns matching—Enter the data strings here (one per line) to which you want to impose restrictions. By default, this field has an <all> entry indicating all strings. When you click inside this field, the <all> disappears so that you can enter your own data.
Note When entering data patterns, the "*" character is a generic wildcard specification.
–but not—Make exceptions to the data strings you've entered in the Patterns matching field. By default, this field has a <none> entry indicating no exceptions. When you click inside this field, the <none> disappears so that you can enter your own exceptions.
•HTTP:
–Patterns matching—Enter the data strings here (one per line) to which you want to impose restrictions. By default, this field has an <all> entry indicating all strings. When you click inside this field, the <all> disappears so that you can enter your own data. This pattern is used by HTTP Web servers to match against the requested URI (Uniform Resource Identifier) to enforce allow/deny Data access control rules.
–but not—Make exceptions to the data strings you've entered in the Patterns matching field. By default, this field has a <none> entry indicating no exceptions. When you click inside this field.
•MSRPC:
–Enter an Interface ID matching to include or to exclude. The default is <all>. Generally, you will want to leave the default here and match by patterns over all interfaces.
–but not—Make exceptions to the data strings you've entered in the Interface ID matching field. By default, this field has a <none> entry indicating no exceptions. When you click inside this field.
–Enter Patterns matching to include or to exclude. These patterns are represented by the @signatures or @highrisk_signatures tokens.
–but not—Make exceptions to the data strings you've entered in the Patterns matching field.
•LPC:
–Enter an Interface ID matching to include or to exclude. The default is <all>. Generally, you will want to leave the default here and match by patterns over all interfaces.
–but not—Make exceptions to the data strings you've entered in the Interface ID matching field. By default, this field has a <none> entry indicating no exceptions. When you click inside this field.
–Enter Patterns matching to include or to exclude. These patterns are represented by the @signatures or @highrisk_signatures tokens.
–but not—Make exceptions to the data strings you've entered in the Patterns matching field.
Note Specifying patterns other than @signatures may impact system performance. This is because a data access control rule specifying a data set of @signatures will be triggered only when the application in the rule attempts to access a payload that is associated with the @signatures token. If the data access control rule specifies a data set of "<all>" the rule will be triggered for every payload accessed by the application specified in the data access control rule.
In some rare cases, you may want to configure a data set using only a specified Interface ID. Such cases may be as follows:
•to block an MSRPC interface entirely; useful for interfaces known to be vulnerable
•use only high-confidence signatures for a particularly solid or mission-critical interface, use lower confidence signatures for an interface known to be vulnerable and less important
•create an exception for false positives on a particular interface
•take different actions based on an interface: query, deny, terminate, etc.
Step 8 When all required information is entered, click the Save button to save your data set in the CSA MC database.
You can now enter this data set name by clicking the Insert Data Set link in the data access control rule files field.
Figure 9-2 Data Set Configuration View
File Sets
Configure file sets for use in file access control rules and application classes. File sets are groupings of individual files and directories under one common name. This name is then used in rules that control directory and file permissions and restrictions. All the parameters that exist under that name are then applied to the rule where the name is used.
CSA MC ships with several pre-configured File Sets you can use.
Note You do not have to specify a setting for every field in the File Sets page. If you do specify multiple settings, note that within single fields, multiple selections are "or-ed". If settings are specified for multiple fields, they are "and-ed".
To configure a file set, do the following.
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 From the Configuration menu, mouse over Variables and select File Sets.
Step 3 Click the New button to create a new file set.
Step 4 If you have not configured an operating system preference for your administrator account, click Windows or UNIX in the pop-up box. If you have configured an operating system preference for your administrator account, the new file set will automatically be created for that operating systems. This takes you to the file set configuration view (see Figure 9-3).
Step 5 In the available edit fields, enter the following information (See Using the Correct Syntax, page 2-41. You can also click the Quick Help question mark beside each field for syntax information.):
•Name—This is a unique name for this file set. Generally, it's a good idea to adopt a naming convention that lets you quickly enter file set names in a corresponding rule configuration field. When using configuration variables in file access rules, network access rules and application classes, you must enter the variable name preceded by a dollar sign:
For example, if you have a file set variable named cgi_files, you must enter $cgi_files into any edit field where you are using this variable. The dollar sign tells CSA MC that this is a variable value.
•Description—This is a line of text that is displayed in the list view helping you to identify this particular file set configuration.
•OS—When you create a file set, you must select to either create a UNIX or a Windows file set. Your file set is then designated for all UNIX or all Windows platforms. Optionally, you select to target an operating system more narrowly by selecting a specific UNIX or Windows operating system from the OS list box.
Step 6 Directories matching—Enter the directories and files here (one per line) to which you want to impose restrictions.
By default, this field has an <all> entry indicating all directories. When you click inside this field, the <all> disappears so that you can enter your own directory restrictions. When entering directory restrictions, use the following syntax:
Windows example:
c:\Program Files\**\*SQL*\bin\**
\Program Files\**\*SQL*\bin
UNIX example:
Step 7 but not—Make exceptions to the files and directories you've entered in the directories matching field. For example:
Windows example:
c:\Program Files\**\*SQL*\bin\temp
Caution The exclusion entry above means that any temp files in the bin folder are ignored by the restrictions you apply using this file set. This also means that the path you're protecting in the Directories matching field is NOT protected when the excluded directory "temp" is being accessed.
UNIX example:
By default, this field has a <none> entry indicating no exceptions. When you click inside this field, the <none> disappears so that you can enter your own exceptions.
Step 8 Files Matching—Enter the names of the files to which you are controlling access.
You can use wildcards here to indicate all of a specific file type. For example, *.exe to specify all executables.
By default, this field has an <all> entry indicating all files. When you click inside this field, the <all> disappears so that you can enter your own file restrictions.
Step 9 but not—Make exceptions to the file names you enter in the Files Matching field. For example, all executables, but not regedit.exe.
By default, this field has a <none> entry indicating no exceptions. When you click inside this field, the <none> disappears so that you can enter your own exceptions.
Note Use @dynamic in the File set text field to indicate all files that have been quarantined by CSA MC. This list updates automatically (dynamically) as logged quarantined files are received.
To view the files that are added to the dynamically quarantined files list and to manually add files to be quarantined, click the Manage dynamically quarantined files link on the Global Event Correlation page. See Manage Dynamically Quarantined Files and IP Addresses, page 7-10 for more information.
Step 10 (UNIX only instruction) File Sets created for UNIX have an additional configuration field: Attributes Matching. In the Attributes Matching edit fields, click the Insert attribute link and optionally select one or more file types to match against. Available file types are as follows:
•block device—A special file used for buffered or block I/O. For example, a disk device.
•character device—A special file used for unbuffered or character I/O. For example, a tty file.
•executable file—A file identified in /etc/magic as being executable.
•interpreter file—A file which contains a script (shell, Perl, etc.) where the first line starts with "#! interpreter [arg]".
•java class file—A file identified in /etc/magic as being executable Java byte code.
•setgid file—A file with the "set group ID on execution" property set in the file mode.
•setuid file—A file with the "set user ID on execution" property set in the file mode.
Step 11 (Windows only instruction) File Sets created for Windows have an additional configuration field: Content matching. The Content matching field allows you to describe a set of files that all have the same tag. Follow these steps to add an AntiVirus tag in the Content matching field. The entry for each AntiVirus tag is placed on its own line in the Content matching box.
a. Next to the Content matching edit fields, click the Insert content link. The File Content Selector pop-up opens.
b. In the Type field, select Virus scanning.
c. In the Tag field, type the virus tag name and click OK. See Using the Correct Syntax, page 2-41 for syntax requirements for the @virusscan token.
If you prefer, you can also edit the Content matching field directly by clicking in the edit box. Follow the syntax guidelines for the @virusscan token.
d. When you have added all the virus scanning tags, close the File Content Selector pop-up box.
For general information about the AntiVirus feature see Chapter 15, "AntiVirus Basics."
Step 12 (Windows only instruction) File Sets created for Windows have an additional configuration field: Content matching. The Content matching field allows you to describe a set of files that all have the same tag. Follow this procedure to add a scanning data tag or static data tag in the Content matching field. The entry for each tag is placed on its own line in the Content matching box.
a. Next to the Content matching edit fields, click the Insert content link. The File Content Selector pop-up opens.
b. In the Type field, select Data Classification.
c. Select a Data Classification tag from the Tag list box and click OK. The Tag list box contains all the enabled scanning data tags and static data tags. Choosing a tag from the Tag list box is the most accurate method of specifying a content type.
You can also click New to create your own scanning data tag in the New Data Classification Setting pop-up box. Once you have created your own tag, click Save. Click OK to add the tag to the Content matching box. See Creating a Scanning Data Tag, page 16-11 for the procedure to create a content tag.
For more information about the Data Loss Prevention feature, see Chapter 9 "Configuring Variables and State Conditions."
Step 13 (Windows only instruction) After specifying an AntiVirus, scanning data tag, or static data tag, you can enter exceptions in the Content Matching but not field. You can type the token and tag into the text field or insert the token and tag using the Insert Content link. Here are two examples of usage:
•You could enter @datascan=<*> in the Content matching field and enter @datascan=<SSN> in the but not field to search for all files with data scanning tags except those tagged <SSN>.
•You could enter, @virusscan=<virus:**> in the Content matching field and enter @virusscan=<Virus:Behavior**> to indicate all files with virus scan tags, except those files tagged with behavior-based AntiVirus tags.
Step 14 When all required information is entered, click the Save button to save your file set in the CSA MC database.
You can now enter this file set name by clicking the Insert File Set link in the application class files field and in the file access control rule files field.
Figure 9-3 File Set Configuration View
Network Address Sets
Configure network address sets for use in network access control rules, network shield rules, and connection rate limiting rules to impose restrictions on specified IP addresses or a range of addresses. Once configured, you can enter the name of the address set in any network access control rules you create.
To configure network address sets, do the following.
Step 1 From the menu bar Configuration drop-down list, move the mouse over Variables. A cascading menu with further selections appears.
Step 2 Select Network Address Sets from the cascading menu. Any existing address set configurations are shown.
Step 3 Click the New button to create a new network address set. This takes you to the configuration view (see Figure 9-4).
Step 4 In the available edit fields, enter the following information (See Using the Correct Syntax, page 2-41. You can also click the Quick Help question mark beside each field for syntax information.):
•Name—This is a unique name for this address set. When using configuration variables in file access rules, network access rules and application classes, you must enter the variable name preceded by a dollar sign:
For example, if you have a network address set variable named Finance systems, you must enter $Finance systems into any edit field where you are using this variable. The dollar sign tells CSA MC that this is a variable value.
•Description—This is a useful line of text that is displayed in the list view and helps you to identify this particular set of addresses.
Step 5 Address ranges matching—In the available edit field, enter a single address, range of addresses, or network address class.
By default, this field has a <all> entry. When you click inside this field, the <all> disappears so that you can enter your own addresses. See Using the Correct Syntax, page 2-41 for a full description of proper IPv4 and IPv6 address syntax.
Note IPv6 addresses can only be used by a rule associated with a Vista rule module.
Use @local to indicate all local addresses on the agent system. You would want to use this if you are allowing different applications on a single system to talk to each other without opening these applications up to network access.
Note Use @dynamic in the Addresses set field to indicate untrusted hosts that have been quarantined by CSA MC. Addresses are added to this list when they are seen as an untrusted host. (The built-in "Processes Communicating with Untrusted Hosts" is triggered in a rule.) This list updates automatically (dynamically) as logged quarantined addresses are received.
Caution On UNIX platforms, IPv6 addresses are not officially supported; however, an IPv6 connection will work as the applied rules dictate if the address in question is covered by the "all" addresses range (0.0.0.0-255.255.255.255 includes IPv6 addresses) or by @local. Local addresses on the agent system (indicated by @local) also include IPv6 addresses.
but not—Use this field to make exclusions to addresses within the address ranges entered in the address matching field.
Figure 9-4 Network Address Set Configuration View
Step 6 When all required information is entered, click the Save button to save your address set in the CSA MC database.
Note You can now enter this network address set name by clicking the Insert Network Address Set in the network access control rule host addresses field.
Step 7 Once you have saved the Network Address Set, open the Tasks drop down menu if you want to change the visibility of the Network Address Set or make it Read-only.
Network Interface Sets
Configure network interface sets for use in network access control rules, network shield rules, and connection rate limiting rules to impose restrictions that take the local system interface into consideration. Once configured, you can simply enter the name of the network interface set in any applicable rules you create.
Note that interface types apply only to your local network and do not apply to remote connections. You can use network interface set in rules to control connectivity based on the manner in which a machine is talking on the network (rather than based on an address). For example, if a type of WiFi network interface type is detected, you can apply rules that deny wireless connections on your internal network.
Note Network interface sets can only be used by rules applied to Windows operating systems.
To configure network interface sets, do the following.
Step 1 From the menu bar Configuration drop-down list, move the mouse over Variables. A cascading menu with further selections appears.
Step 2 Select Network Interface Sets from the cascading menu. Any existing network interface set configurations are shown.
Step 3 Click the New button to create a new network interface set. This takes you to the configuration view (see Figure 9-4).
Step 4 In the available edit fields, enter the following information (Note that you can click the Quick Help question mark beside each field for further information on that field.):
•Name—This is a unique name for this network interface set.
•Description—This is a useful line of text that is displayed in the list view and helps you to identify this particular set of network interfaces.
Step 5 Interface characteristics matching—When you click the Insert Interface Characteristics link you can select one or more of the following interface Types and enter their corresponding Name characteristics. (The default entry for the Name field is "*", meaning all or don't care.):
Note You can obtain the adapter name for a host from the host diagnostics. When you click on the Detailed status and diagnostics link for the host, the current installed interface and named characteristics for the host are displayed (labeled as InterfaceCharacteristics). For example, Wired\3Com 3C920 Integrated Fast Ethernet Controller (3C905C-TX Compatible). Also note, that wildcard entries can be used for interface type names. If you select WiFi, <Don't care> or wildcard entries are valid for all Mode, Encryption, and SSID fields. You can use the Insert Interface Characteristics link to configure these fields or you can enter literals - although it is not recommended that you use literal entries in these fields.
Note <All> is the only valid setting for this field, when the Network Interface Set will be used with a rule protecting a UNIX, Solaris, or Linux system.
Note CSA only deals with IP networks. Therefore, the following list of interface types only pertains to those connection types running over IP.
•Wired - Enter the Name (name is another interface characteristic) or enter a wildcard character (*) if you don't care.
•WiFi - Select a Mode as follows: Don't care, Infra, Adhoc
Select a WiFi Encryption type as follows: Don't care, clear, Encrypted (WEP), Encrypted (ckip), Encrypted (tkip), Encrypted (aes), Encrypted (other), Encrypted (any)
Enter an SSID (Service Set Identifier)
•Virtual - Enter the Name (name is another interface characteristic) or enter a wildcard character (*) if you don't care.
•PPP (Point to Point Protocol) - You have several suboptions for controlling connections based on PPP. PPP connections can also use one of the following device types:
<Don't care>, RAS server, unknown, modem, isdn, x25, vpn, pad, generic, serial, framerelay, atm, sonet, sw56, irda, parallel, PPoE.
All options, except for Ras server and unknown, also have Device name and Connection name fields. These are optional fields that allow for further granularity. It is recommended that you simply leave the default wildcard characters (*) in these fields. They are displayed because the system is able to retrieve this interface data, but it is likely that this is only useful for diagnostic purposes in log files. If you intend to use these fields for highly granular interface controls, note that Device name is referring to the connection device such as "parallel cable", and Connection name is referring to the connection network information for the remote system receiving the connection. This field would contain the remote machine name or profile.
•Bluetooth - Enter the Name (name is another interface characteristic) or enter a wildcard character (*) if you don't care.
•IEEE1394 - This is commonly known as FireWire. This interface connection type offers high-speed communications and isochronous real-time data services.
•Loopback - Routes communication between processes running on the same computer.
•Unknown - If CSA cannot determine the network interface, "Unknown" may appear for the adapter name for a host from the host diagnostics page. Although this should not occur often, you can use this Unknown option to write rules for adapter names that CSA cannot determine.
•Other - This includes any interface type not specifically named here, such as IrDA, WAN, ATM, Token Ring, etc. Enter the name or enter a wildcard character (*) if you don't care. For example, Intel 1394 Net Adapter.
but not—Use this field to make exclusions to the interface characteristics entered in the Interface characteristics matching field.
Network address ranges—By default, this field includes <all> addresses. Click Insert Network Address Set to specify a preconfigured set of network addresses. To specify a specific address or a specific address range, enter that information here. Put each entry on its own line. For a complete description of permitted IPv4 and IPv6 addressing syntax, see Using the Correct Syntax, page 2-41.
Figure 9-5 Network Interface Set Configuration View
Step 6 When all required information is entered, click the Save button to save your configuration.
Network Services
Configure network services for use in network access control rules to add preconfigured protocol and port number restrictions. You can restrict by initial connection ports, and when applicable, by subsequent client/server connection.
CSA MC ships with several pre-configured network services you can use.
To configure network services, do the following.
Step 1 From the menu bar Configuration drop-down list, move the mouse over Variables. A cascading menu with further selections appears.
Step 2 Select Network Services from the cascading menu. Any existing configurations are shown.
Step 3 Click the New button to create a new network service variable. This takes you to the configuration view (Figure 9-6).
Step 4 In the available edit fields, enter the following information (See Using the Correct Syntax, page 2-41. You can also click the Quick Help question mark beside each field for syntax information.):
•Name—This is a unique name for this network service configuration. This name is case insensitive. Generally, it's a good idea to adopt a naming convention that lets you quickly enter network service variables in network access control rule configuration fields. When using configuration Variables in file access rules, network access rules and application classes, you must enter the variable name preceded by a dollar sign.
For example, if you have a network service variable named FTP Service, you must enter $FTP Service into any edit field where you are using this variable. The dollar sign tells CSA MC that this is a variable value.
•Description—This is a useful line of text that is displayed in the list view and helps you to identify this particular configuration.
•Display only in Show All mode—If your lists of variables are growing too long in rule or application configuration pages, clicking the Display only in Show All mode checkbox on a variable page causes that variable to no longer appear in selection lists for that variable type. This feature works in conjunction with Admin Preference settings. You must go the Admin Preferences page to make the item reappear. See Configuring Role-Based Administration, page 2-14.
Step 5 Protocol ports-Destination—Enter a tcp or udp protocol and corresponding port or port range to indicate a restriction.
By default, this field has a <all> entry indicating no ports. When you click inside the edit field, the <all> disappears so that you can enter your own port restrictions.
Use the following syntax:
Protocol ports-Source—(CAUTION: Using a specific source port, rather than the default of <all>, in a Network access control rule may degrade performance.) You can enter a tcp or udp protocol and corresponding port or port range to indicate a restriction if it is necessary. Generally, you will not want specify a specific port here and simply leave <all> as the entry for the source port. You only want to enumerate a specific source port for a data connection that has an ephemeral destination port and a well-known source port.
Since most network connections are keyed off of well-known destination ports, applications that only have well-known source ports, such a multimedia applications or Active FTP data connections, must be controlled off the source port. Therefore, if you are specifying a differentiated service marking for a multimedia connection, you would key off the source port.
Note Some protocols, such as ftp, create additional connections as part of the same session started by the initial connection. The port numbers used for these additional connections must be defined as another Network Service and used appropriately in a rule module to consider callback connections. When a network service is used in an allow rule, once an initial connection is established, the subsequent connections will also be allowed, but only to the process that participated in the initial connection.
In some cases, an application may want to offer a temporary service port for callback data connections. An ephemeral port is a temporary system-assigned port for this purpose. You can specify an ephemeral port range for a Network service as follows (See Using the Correct Syntax, page 2-41 for more details):
Step 6 When all required information is entered, click the Save button to save your event set in the CSA MC database.
You can now enter this network service name by clicking the Insert Network Service link in the network access control rule network services field.
Figure 9-6 Network Services Configuration View
Notification Settings
From the Notification Settings page, you can configure the notification text, radio buttons and check boxes that appear in the pop-up box the end user sees when notification rules are triggered.
To configure a notification pop-up box for use with a notification rule, do the following:
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 From the Configuration menu, navigate Variables > Notification settings.
Step 3 On the Query Settings list page, click the New button to create a new query.
Note CSA MC ships with several preconfigured notifications. You can use an existing one or create a new one.
Step 4 Enter a unique Name for your notification. Names are case insensitive, must start with an alphabetic character, can be up to 64 characters long and can include hyphens and underscores _ . Spaces are also allowed in names. Use a descriptive name that you can easily recognize in the rule selection box when you are selecting a specific notification setting for a rule.
Step 5 Enter a Description of your notification.
Step 6 In the Text used to notify user edit field, enter a description of the issue that likely triggered the notification. This text field allows you to provide localized notification text for agents using the corresponding language on their desktop.
This is the same text that will appear in the notification user pop-up box explaining what is occurring on the system to the user. Therefore, making this information descriptive of the system action that triggered the pop-up is important.
You can use specially designated tokens to represent the corresponding values presented to the end user who is responding to the query. See Notification and Query Tokens and Syntax.
Note All Cisco Security Agent kits contain localized support for English, French, German, Italian, Japanese, Korean, Simplified Chinese, Spanish, Polish, Brazilian Portuguese and Russian language desktops. If you do not select a specific language, the default for query text is English. Click the More languages link to enter text to be displayed in a language other than English. This allows you to provide localized query text for agents using the corresponding language on their desktop. See Localized Language Version Support for more details.
Step 7 The Allowed notification responses multi-select box lets you choose which buttons appear on the notification pop-up box. You can select to display an OK button or a Yes/No button combination.
Step 8 If the notification is not answered by the user within 5 minutes or if the user is not logged in to the system, the Default response you select here is taken.
Step 9 In addition to notifying the user, you can require the user to type in a user justification statement in a pop-up window edit field. This justification text typed in by the end user appears in the event log message on the MC.
Step 10 Click the Save button.
Step 11 By opening the Tasks menu on query settings page you can change the visibility, make this variable read-only, or view more information about the query.
Query Settings
From the Query Settings page, you can configure the query text, radio buttons, and check boxes that appear in the pop-up box the end user sees when query rules are triggered.
Note For a Query setting, the response to the query is relevant to the question, not to the resource. For example, if a File access control rule queries the user for a response and that identical query is also configured for a Network access control rule, the user is not queried again when the Network access control rule triggers. The query response from the previous File access control rule is automatically taken.
To configure a query pop-up box for use with a query rule, do the following:
Step 1 Log on to the CSA MC as a user with configure privileges and switch to Advanced Mode.
Step 2 From the Configuration menu, navigate Variables > Query settings.
Step 3 On the Query Settings list page, click the New button to create a new query. See Figure 9-7.
Note CSA MC ships with several preconfigured queries. You can use an existing one or create a new one.
Step 4 Enter a unique Name for your query. Names are case insensitive, must start with an alphabetic character, can be up to 64 characters long and can include hyphens and underscores _ . Spaces are also allowed in names. Use a descriptive name that you can easily recognize in the rule selection box when you are selecting a specific query setting for a rule.
Step 5 Enter a Description of your query.
Step 6 In the Text used to query user edit field, enter a description of the issue that likely triggered the query. This text field allows you to provide localized query text for agents using the corresponding language on their desktop. This is the same text that will appear in the query user pop-up box explaining what is occurring on the system to the user. Therefore, making this information descriptive of the system action that triggered the pop-up is important.
You can use specially designated tokens to represent the corresponding values presented to the end user who is responding to the query. See Notification and Query Tokens and Syntax.
Note All Cisco Security Agent kits contain localized support for English, French, German, Italian, Japanese, Korean, Simplified Chinese, Spanish, Polish, Brazilian Portuguese and Russian language desktops. If you do not select a specific language, the default for query text is English. Click the More languages link to enter text to be displayed in a language other than English. This allows you to provide localized query text for agents using the corresponding language on their desktop. See Localized Language Version Support for more details.
Step 7 The Allowed query actions multi-select box lets you choose which radio buttons appear on the query pop-up box. For example, you may not want the user to have a "Terminate" option. Therefore, you would only select the Allow and Deny radio buttons to be displayed.
The user reads the information posted on the query and is given the choice to select one of the following possible choices and click Apply:
•Allow (Yes)—Allows the application access to the resource in question.
•Deny (No)—Denies the application access to the resource in question.
•Terminate—Denies the application access to the resource in question and also attempts to terminate the application process. (Some processes cannot be safely terminated, such as winlogon.)
Step 8 Of the radio buttons you decided to display, you also choose one of those buttons to be the Default action. If the query is not answered by the user within 5 minutes or if the user is not logged in to the system, the default action is taken immediately.
Step 9 In addition to deciding which query actions (Allow, Deny, Terminate) are available to the user for the query pop-up, you can also configure the query response to log only when a particular query action is selected by the user. Using the multi-select box available from the Logged query responses section, you can select one or more response types to produce a log message. For example, if all query actions are being made available for the query, you can configure only a Terminate response to produce a log message. (By default, all query responses are logged.)
Step 10 You can also decide to display a Don't ask again checkbox so that the user's query response is remembered. If the user selects that checkbox when he/she responds to the query, and the same action is attempted on the same resource, the remembered response is automatically taken and the user is not queried again.
Step 11 For added security, you can issue a query challenge on the query pop-up box. If the default answer is not selected by the user and the selected answer is weaker than the default, a challenge will appear. This ensures that the user sitting in front of the system is answering the query rather than a malicious remote user or program attempting to respond. To pass the challenge, the user enters the information displayed in a graphic on the pop-up box itself.
Step 12 In addition to querying the user, you can require the user to type in a user justification statement in a pop-up window edit field. This justification text typed in by the end user appears in the event log message on the MC.
Step 13 Click the Save button.
Step 14 By opening the Tasks menu on query settings page you can change the visibility, make this variable read-only, or view more information about the query.
Tip When you phrase the question that will appear to users and select the radio button options to be displayed, make sure that the logic you use is in sync with the response the user should select. For example, you probably should not phrase a question in the following way: "Do you want to prevent this action from occurring?" In this case, if the response is "Yes", this is counterintuitive to how queries should be used. The user is selecting Yes to indicate No. Instead, phrase the question as follows: "Select No to prevent this action from occurring."
Figure 9-7 Query Settings Configuration View
Notification and Query Tokens and Syntax
The edit fields for query text and notification text use the same syntax: These are the rules for that syntax:
•The query and notification text must can be up to 256 characters long including punctuation.
•Any character on your keyboard may be used in the query or notification text.
•You can use specially designated tokens to represent the corresponding values presented to the end user who is responding to the query or notification.
•If tokens are used in one language, they must be used in all languages.
When entering text into the edit field of queries or notifications, you can use the following tokens to represent the values presented to the end user who is responding to the query.
•@ActiveXname - The name of the ActiveX control being downloaded. Use in System API access control rules only.
•@appname - The path of the process triggering the action. Use in all access control rule types.
•@appname_short - The name of the process triggering the action. Use in all access control rule types.
•@child - The path of the process being invoked. Use in Application control rules
•only.
•@clsid - The GUID of the COM object. Use in COM component access control rules only
•@content - For file access control rules and scan event log rules, this is the content of the file being accessed. For other rule types, @content is the content of the file that triggered entry into the dynamic application class.
•@content_clean - For file access control rules and scan event log rules, this is the simplified content of file being accessed. For other rule types, @content_clean is the content of the file that triggered entry into the dynamic application class.
•@dataname - The name of data being filtered. Use in Data access control rules only.
•@filename - The full file path of the file being accessed. Use in File access control rules and scan event log rules. For other rule types, @filename is the file path that triggered entry into the dynamic application class.
•@filename_short - The name of file being accessed by file access. Use in file access control rules and scan event log rules only. For other rule types, @filename_short is the file name that triggered entry into the dynamic application class.
•@fileop - The type of file operation (file/directory, read/write). Use in File access control rules only.
•@funcname - The system API function being called. Use in System API access control rules only.
•@hostaddr - The remote address of a connection. Use in Network access control rules only.
•@hostaddrname - The remote hostname or address of a connection. Use in network access control rules only.
•@localaddr - The local address of a connection. Use in Network access control rules only.
•@mediadevice - The name of the media device being monitored. Use in System API control rules only.
•@mediaport - The port on which the media device is being monitored. Use in System API control rules only.
•@netservice - The service/destination port used by the remote connection end. Use in Network access control rules only.
•@netop - The type of network operation (client/server). Use in Network access control rules only.
•@parent - The path of the parent process. Use in Application control rules only.
•@progid - The ProgID of the COM object. Use in COM component access control rules only.
•@regname - The registry entry being accessed. Use in Registry access control rules only.
•@targetapp - The path of the application being targeted for code injection or modification. Use in System API access control rules only.
Localized Language Version Support
On systems running multiple locales, (for example, Multilingual User Interface installations or Terminal Services), queries and notifications are displayed in the supported language used for the Windows desktop on which the query is shown. Events appear in the Windows Event Log in the default systems language.
For example, on a Windows 2000 Multilingual User Interface (MUI) installation, if a user is running a Japanese language version desktop, queries and notifications will appear in Japanese. But the Windows Event Log on this system will store events formatted in US English because the system language on a Windows MUI system is English.
On a localized Japanese system, the queries, notifications, and the events appearing in the Windows Event Log appear in Japanese.
Registry Sets
A variety of viruses invoke themselves using registry settings. Use the preconfigured registry sets in registry access control rules to prevent viruses from writing to registry values popular with viruses.
This variable is not available for UNIX configurations.
Caution If you attempt to create your own registry sets to include in a rule, you should note that the ability to restrict registry access is an extremely powerful tool. Critical applications may not function as a result of a misconfigured registry restriction. Therefore, registry values should be as specific as possible. All rules restricting registry access should first be run in
Audit Mode to ensure that no unintended restrictions have been configured.
Registry sets are groupings of registry keys and settings under one common name. This name is then used in rules that allow or deny registry write operations. All the registry restriction parameters that exist under that name are then applied to the rule where the name is used.
To view preconfigured registry sets or to create a new registry set, do the following.
Step 1 From the menu bar Configuration drop-down list, move the mouse over Variables. A cascading menu with further selections appears.
Step 2 Select Registry Sets from the cascading menu. Any existing registry set configurations are shown.
Step 3 To view an existing registry set, click the link for that item. Click the New button if you would like to create a new registry set variable. This takes you to the configuration view (see Figure 9-8).
Step 4 Enter the following.
•Name—This is a unique name for this registry set.
•Description—This is a line of text that is displayed in the list view helping you to identify this particular registry set configuration.
•Display only in Show All mode—If your lists of variables are growing too long in rule or application configuration pages, clicking the Display only in Show All mode checkbox on a variable page causes that variable to no longer appear in selection lists for that variable type. This feature works in conjunction with Admin Preference settings. You must go the Admin Preferences page to make the item reappear. See Configuring Role-Based Administration, page 2-14.
Step 5 Registry keys matching—You must enter a value in this field if you are creating a registry set.
It is recommended that there be at least one non-wildcarded component in a registry key other than the hive itself. Otherwise, the specified key might be overly generalized.
Hives are one of the following strings:
HKLM—refers to the HKEY_LOCAL_MACHINE
HKCR—refers to HKEY_CLASSES_ROOT
HKCC—refers to HKEY_CURRENT_CONFIG
HKU—refers to HKEY_USERS (HKU\* refers to all users)
Table 9-1 Example valid and invalid registry key entries
|
This is a valid entry.
|
|
This is a valid entry.
|
|
This is invalid (FOO is not a hive).
|
|
This is a valid entry.
|
Note Note that the wildcard syntax explained in Wildcard notation for directories and filenames, page 2-44 also applies to registry sets.
Note The asterisk is a valid single character in a registry key. For example, HKEY_CLASSES_ROOT\*\OpenWithList is a registry key. If you want to represent the * with a wildcard, use the "?" character instead of a * character.
The @reg shorthand notation may be used in the Registry keys matching field. See Referencing Values Stored on Clients, page 2-58 for more information on the @reg notation. This is an example of valid syntax for the @reg token.
@(reg HKLM\SOFTWARE\MyKey\CustomKey\StringValue)
Step 6 but not—Make exceptions to registry keys.
Step 7 Registry values matching— In the Registry values matching field, enter the values, one per line, to which you are controlling access. CSA MC will look for the value you put in this field in the key you defined in the previous Registry keys matching field. Examples of valid registry values are as follows:
BootExecute
run
load
Step 8 but not—Make exceptions to registry values.
Step 9 When all required information is entered, click the Save button to save your registry set in the CSA MC database.
You can enter this registry set name by clicking the Insert Registry Set link in the registry access control rule registry entries field.
Figure 9-8 Registry Set Configuration View
Included Registry Sets
CSA MC ships with several pre-configured registry sets you can use in your registry access rules. Some are application specific, others are operating system specific. This section describes a sample of the included operating system specific registry keys.
•Run Keys are used to register programs so that the system will invoke them as a service. Viruses can make use of this key to become persistent.
Protecting this registry value by creating a rule to prevent writing to run keys can prevent the type of virus described above from invoking and propagating itself.
Note It is important to note that if users have administrator privileges on their systems and are installing software, this type of rule may trigger and prevent that installation. In such cases, using a Query User rule would be most effective. This way, if users are installing software, they themselves can prevent the agent from stopping the installation by answering "Yes" to the query to allow the install. However, if users are not installing software, this type of Query User rule triggering on a system could be treated as a serious issue and the user should answer "No to all" to disallow the action.
•Shell commands are used to tell your system how to open a file based on the file format. This is how the system knows which application to use when opening a particular file.
Viruses can exploit this by having the registry setting invoke the virus along with the application being opened. In this case, the application would open correctly and the virus could silently begin doing harm.
BootExecute tells the system which executables should be run at system startup time.
•Reboot operations tell the system which operations should begin at system startup time. If programs have been uninstalled, the reboot operation also tells the system which files and services should be deleted on the next reboot and startup.
Viruses can exploit this registry setting by marking particular files for copying, overwriting, or deleting on startup. For example, a virus may attempt to delete a system service that could possibly detect the virus itself. By deleting this service at startup, the virus can go undetected.
Note It is important to note that if users have administrator privileges on their systems and are uninstalling software, this type of rule may trigger and prevent the uninstall. In such cases, using a Query User rule would be most effective. This way, if users are uninstalling software, they themselves can prevent the agent from stopping the uninstall by answering "Yes" to the query to allow the action. However, if users are not uninstalling software, this type of Query User rule triggering on a system could be treated as a serious issue and the user should answer "No to all" to disallow the action.
Setting State Conditions
System State and User State conditions let you write conditional rules based on the state of a system or the user of the system. Therefore, rules are only applied if the configured conditional settings are met.
System State Sets
System state parameters let you dictate conditions based on detected machine settings. When a machine is operating an agent with a configured system state, the rules associated with that state apply only when the state parameters are met. They are conditional rules. For example, if you apply a system state to a rule module, you can dynamically "activate" and "deactivate" rule modules based on the changing state of a system. For example, you can apply special boot time rules that apply only at boot time. After booting is complete, normal operation rule modules are applied. Also, for example, you can apply a more lenient set of rules if an installation is occurring on a system. Once the installation is complete, a more stringent, normal operating set of rule modules are applied.
Note You do not have to specify a setting for every field in the System State page. If you do specify multiple settings, note that within single fields, multiple selections are "or-ed". If settings are specified for multiple fields, they are "and-ed".
Configure a System State Set by doing the following:
Step 1 Move the mouse over Configuration>Variables in the menu bar. Select System State Sets from the cascading menu that appears.
Step 2 Click the New button to create a new system state. See Figure 9-9.
Step 3 Enter a unique Name for your system state. You will select this name in the Rule Module page. Names are case insensitive, must start with an alphabetic character, can be up to 64 characters long and can include hyphens, underscores, and spaces.
Step 4 Enter a Description.
Step 5 In the Network Admission Control section, you can select one or more Cisco Trust Agent posture state conditions for a system to ensure that corporate security requirements are met on that system. This feature works in conjunction with the capabilities of Cisco's Network Admission Control (NAC) functionality.
Note Currently, the Cisco Trust Agent is only supported on pre-Vista Windows platforms and Linux platforms. CTA is not supported on Windows Vista platforms.
Note Before setting a Cisco Trust Agent posture, check with your NAC system administrator to learn what the different posture choices imply for your network security.
Step 6 In the System Security section, you can select one or more (Hold the Shift key down while you click the mouse to choose multiple, concurrent options. Hold the Ctrl key down to select non-concurrent options.) Security level conditions. If the end user has an agent UI, you can have a Security level condition apply which allows the user to set the security slidebar on their UI to a specific level. This provides some degree of user control to manage false positives or to control security when operating remotely or on the local network. This allows the user to decide, again to some degree, how much security they require.
Step 7 In the System Location section, you can use the Network Interface field to enter one or more network interface sets to create a state condition based on system address or location or connection type. By default, no restrictions are set here. If you enter interface conditions here, the condition applies if at least one interface matches what is specified. If you enter multiple interfaces here, only one interface has to match for the system state to apply. The interface types apply only to your local network and do not apply to remote connections. You can use this feature to control connectivity based on the manner in which a machine is talking on the network (rather than based on an address). For example, if a type of WiFi network interface type system state is triggered, you can apply rules that deny wireless connections on your internal network. See Network Interface Sets for Network Interface configuration details.
Step 8 You can use the DNS suffix matching field to set a condition based on the suffix of the DNS server domain name. If any DNS server domain suffix matches an item specified in the DNS suffix matching field, the condition is applied. You can use the but not field to make specific exclusions to DNS suffix matching parameters you configure.
These are examples of proper syntax that will match a DNS server with domain suffix, regional.acme.com:
You can enter the entire suffix: regional.acme.com
You can also enter the suffix expressed with a wildcard: *.acme.com.
Step 9 In the Data Classification area, you can use the Data Classification matching field to set a state condition based on the presence of a scanning data tag or static data tag.
Click the Insert Tag link to add a scanning data tag or static data tag to the Data classification matching any (or all) of these tags field. The Tag list box contains all the enabled scanning data tags and static data tags. If multiple tags are entered, use the drop-down box to choose whether the state condition should be set upon matching any or all of these tags. You can use the but not field to make specific exclusions to data classification tag parameters you chose.
Step 10 In the Custom State Conditions area you can specify one or more custom state tags or leave the field with the default <Don't care> tag. These custom state tags are available to CSA MC administrators to configure if the system states provided do not suit their needs. The custom state conditions are defined using rule types which make use of the "Set" attribute. See Attribute: Custom-made state condition, page 5-27 for information on how these states are defined.
Step 11 In the Additional State Conditions area, you click the Add State link to add one or more of the following additional states to this page. (Use the pulldown menus that appear to select an option. Then use the pulldown to the right of your selected option to choose one of the following settings: <Don't care>, Yes, No.)
•Select the Management Center reachable option to set a state condition based on whether the Cisco Security Agent can communicate with the Management Center. Based on this condition, rules are applied or not applied. When the agent service first starts, it assumes that the management center is unreachable. When it attempts to communicate with the management center to receive rule changes or to upload events, if it can communicate with the management center at that time, it is then considered reachable.
•Select the Installation process detected option to set a state condition to apply if an installation is in progress on a system. For example, perhaps you want to apply a less restrictive set of rules to allow an installation when it is detected on a system.
•Select the Untrusted rootkit detected option to set a state condition if a driver is seen attempting to dynamically load. Based on this condition, rules are applied or not applied. This state condition could be met if you are using a "Set-detected rootkit-Untrusted" rule in a rule module. When this "Set" rule type triggers, the system state consequently takes effect. See Attribute: detected rootkit trust status, page 5-32 for more information on this setting.
Note that this is a persistent state. This state condition, once set, can only be removed by using the Reset feature. See Resetting Cisco Security Agents, page 3-9. (Most states are not persistent in this way. Most states can be switched in and out using rule triggers. A persistent states can only be switched "on" using rules and must be switched "off" manually.)
•Select the Virus detected option to set a state condition to apply if a signature-based or behavior-based virus is detected on a system. Based on that virus detection, a state condition setting can enforce a designated set of rules.
•Select the Unprotected access detected option to set a state condition when an application or service, or other system component that is marked as Unprotected does not have a corresponding Protected rule and is therefore not being protected by the agent. See Attribute: detected access, page 5-30 for more information on this setting.
•Select the System booting option to set a state condition to apply for the time frame in which the system is booting. Based on this condition, a set of designated rules apply only during boot time.
•Select the Insecure boot detected option to set a state condition to apply if a previous system boot occurred in a non-standard manner. For example, the system was booted from a peripheral device (CD ROM) rather than from the hard drive. This type of boot can be considered non-standard and therefore possibly suspicious. (This is one way of introducing a Trojan to a system.) This type of peripheral device insecure boot detection works in conjunction with a particular type of compatible BIOS on compliant systems. The compatible BIOS detects a non-standard boot and on the next normal boot, if you have an appropriately configured Kernel Protection rule (see Kernel Protection, page 6-53), a message is sent to the MC which logs this insecure boot detection. This, in turn, causes the system state (if configured) to trigger. A Safe Mode boot also falls into this insecure boot category. Compatible BIOS is not required for a Safe Mode boot detection. But, Safe Mode boot detection is only supported on Windows platforms.
This state condition could be met if you are using a "Set-detected boot-as insecure" Kernel Protection rule. When this "Set" rule type triggers, the system state consequently takes effect. See Using the Set Action, page 5-25 for more information on this setting.
Note that this is a persistent state. This state condition, once set, can only be removed by using the Reset feature. See Resetting Cisco Security Agents, page 3-9. (Most states are not persistent in this way. Most states can be switched in and out using rule triggers. A persistent states can only be switched "on" using rules and must be switched "off" manually.)
Step 12 Click the Save button.
Note The system states you configure are additive. All specified state conditions are used as part of the requirement(s) to be met for the state to trigger.
Caution Remote VPN Clients - System Location and Management Center Reachable system states are checked by the agent whenever the network configuration changes on the system. Some VPN clients may make network configuration changes on a system that cause a system state to trigger. Such VPN clients can make use of System Location and Management Center Reachable settings to change the policy depending upon whether a tunnel is up or not. Other VPN clients, such as the Cisco VPN client V3.6, do not change network configurations on a system. Therefore, you cannot use System Location and Management Center Reachable states to detect tunnels with these types of VPN clients. You should understand how your VPN client operates if you want to use these system states.
Figure 9-9 System State Conditions
User State Sets
User state parameters let you dictate conditions based on detected user and/or group settings. When a machine is operating an agent with a configured user state, the rules associated with that state apply only when the state parameters are met. They are conditional rules. Keep this in mind when assigning a user set to a rule module.
You should also keep in mind that the process of checking user states is an expensive one for the system. You should use these settings judiciously.
An example of when you might want to employ a user state is as a restriction dictating who can alter web server pages. The web server application itself should only serve pages, not edit them. You could use a setting here to ensure that only authenticated administrators using a specific application (e.g. FrontPage) are allowed to alter web server content.
Another example of appropriate user state setting usage is a situation where groups of users are restricted from performing certain tasks that you only want to allow administrators to perform, such as suspending agent security.
Configure a User State Set by doing the following:
Step 1 Move the mouse over Configuration>Rule Modules in the menu bar. Select User State Sets from the cascading menu that appears.
Step 2 Click the New button to create a new user state. See Figure 9-10.
Step 3 Enter a unique Name for your user state. You will select this name in the Rule Module page. Names are case insensitive, must start with an alphabetic character, can be up to 64 characters long and can include hyphens and underscores _ . Spaces, parentheses, and periods are also allowed in names.
Step 4 Enter a Description.
Step 5 In the Users matching field, if you choose to set a condition based on user information, enter the user string data using machine name or domain name\user account. For example, entries in this field might appear as follows:
•Domain_Accounting\Administrator This represents the administrator in the Windows domain "Domain_Accounting."
•W2K-jefe\Administrator This represents user "Administrator" defined locally on the computer "W2K-jefe."
•*\Administrator This represents any user administrator.
•Domain_Accounting\* This represents all users in the domain "Domain_Accounting".
You can use wildcards in the Users matching/but not fields.
Step 6 You can use the but not field to make specific exclusions to user matching parameters you configure.
Step 7 In the Groups matching field, if you choose to set a condition based on group information, an entry in this field might appear as follows:
•NT AUTHORITY\SYSTEM
•Domain_Accounting\Administrators
For Windows, you can also enter SID (Security Identifier) numerical classifications into the Group matching field. Using a SID rather than a group name is useful when writing states that will apply across international versions of operating systems. Group names may be different across languages, but a SID classification is always the same.
You cannot use wildcards in the Groups matching/but not fields. If users belong to multiple groups, they only need to match one named group to meet the criteria of the user state.
Note User and Group names are case sensitive for UNIX. They are not case sensitive for Windows.
Note It is recommended that you use Group permissions rather than User permissions because Group designations are more widely applicable.
Step 8 You can use the but not field to make specific exclusions to group matching parameters you configure.
Step 9 Click the Save button.
Note In addition to user information found in logged events, you may use the host diagnostic feature to retrieve a record of observed user/group credentials on a given host. This may useful in troubleshooting policies. It's important to note that the record of credentials that is displayed does not imply that a rule fired in that user's context.
Figure 9-10 User State Conditions
