Introducing Variables

Variables provide the CSA MC administrator a way of grouping items together to ease configuration. These variables, typically referred to as lists or sets, provide reusable objects that you can apply to many rules and alerts. You can group several objects together into variables. Once defined, you can edit these objects very easily at any point. Any rule or policy that makes use of the variable inherits the changes without you having to change every individual rule or policy directly.

Available variable types are as follows:

• Network address sets

• Network services sets

• Data sets

• File sets

• Dynamic file sets

• Query settings

• COM component sets

• Registry sets

The next sections explore each variable type, the sorts of objects they include, and how they are used. The sections also include configuration examples for each type. To configure variables, you must choose Configuration > Variables and then the appropriate variable you want to configure. (See Figure 5-12.)

Network Address Sets

Network address sets are groups of specific IP addresses or IP networks. You can apply these groups to network access control rules, as discussed in Chapter 4. Creating a network address set enables you to group devices, such as engineering workstations, by network range or specific IP addresses. You then can use the set during rule creation instead of repeatedly typing out the addresses or ranges per each similar rule. From that point onward, you can change the addresses in the set (variable definition) if the IP addresses change, which means you do not have to edit every rule that makes use of that set.

The next steps and Figure 5-13 show you how to configure a network address set for a fictitious engineering department:

Step 1.	Choose Configuration > Variables > Network Address Sets.
Step 2.	Click New.
Step 3.	Name the new network address set. Always use descriptive names. This example uses Engineering Workstations.
Step 4.	Enter a description. This example uses The Engineering Group s PCs.
Step 5.	Add the network addresses you want to group. You can only enter one IP address or one network range per line. To show the flexibility allowed, this example uses the following in the set: 150.1.1.51, 182.20.5.1-128, 190.5.1.1-4.255.
Step 6.	Click Save to commit the changes to the new set.

You have now created a network address set that you can use throughout your rules without fear of having many rules with incorrect addressing or other inconsistencies. All of the addresses in the group are maintained in a single set that you can easily edit in the future.

To complete the example, attempt to use the network address set in a network access control rule, which will deny attempts to access web servers residing in the Engineering group networks. Return to a module and create a new rule by choosing Add Rule > Network Access Control. Then follow these steps and refer to Figure 5-14:

Step 1.	Add a description.
Step 2.	Choose the desired action and whether to log the occurrence.
Step 3.	Choose Attempt to Act as a Client > for Network Services $HTTP [V4.5]. (You learn about network services sets in the next section.)
Step 4.	Under Communicating with Host Addresses, choose Insert Network Address Sets > $Engineering Workstations.
Step 5.	Remove 0.0.0.0-255.255.255.255 from the Communicating with Host Address section. This was the default and should not be there for the purpose of this example rule.
Step 6.	Finally, click Save.

The CSA MC includes several predefined network address sets, such as All IP Addresses, Authorized Port Scanners, External IP Addresses, and Internal IP Addresses. You can use these to ease deployment, but you might need to tune them to your specific enterprise IP deployment.

Network Services Sets

Network services sets are groups of specific IP services that you can apply to network access control rules. Creating a network services set enables you to define protocol-specific connection information such as initial ports and subsequent inbound or outbound connections the protocol may use. After defining the variable, you can refer to the set as the variable name (variable names always start with $) so that you do not have to list the ports separately in every rule. Instead of defining a new network services set, this section looks at the $HTTP set, which is a predefined set used in the preceding example:

Step 1.	Choose Configuration > Variables > Network Services. A list of the predefined network service variables appears, as shown in Figure 5-15. Figure 5-15. Network Services Variable List [View full size image]
Step 2.	Choose HTTP.
Step 3.	View the configuration and note that the $HTTP set includes both TCP/80 and TCP/443 for the HTTP and HTTPS protocols respectively, as shown in Figure 5-16. If you regularly use ports other than those for web servers in your architecture, you can either create another network services set or add your ports to the $HTTP set. Figure 5-16. The $HTTP Network Services Variable [View full size image]

Some protocols use dynamically assigned source or destination port numbers as part of additional sessions. Some of these applications are related but not limited to file and video transfer on networks. To deal with temporary ports that need to be opened as a result of one of these connections, you can use ephemeral ports in your protocol definition of CSA rules. To use ephemeral ports, use either TCP/ephemeral or UDP/ephemeral, depending on your specific needs. (See Figure 5-17.)

You can use the network services variables anywhere you would use specific ports, such as in network access control rules. The use of these variables is not mandatory but will greatly ease your administration.

Data Sets

Data sets are variables that you can use as data access control rules. These sets are sets of strings that you can group together. Their only purpose is to be matched against the Uniform Resource Identifier (URI) in HTTP requests. You can use several data sets that come preconfigured in the CSA MC to match sets of meta characters. Meta characters are known classes of attacks and web server-specific exploits. Follow these steps to configure a sample data set:

Step 1.	Choose Configuration > Variables > Data Sets. A list of the predefined data sets displays, as shown in Figure 5-18. Figure 5-18. Predefined Data Set Listing [View full size image]
Step 2.	Choose Common Windows File Exploits from the list. Notice that the screen shown in Figure 5-19 does not differ much from the other variable configuration screens. This time, however, you are defining strings for this set to match. For the set selected in this example, the following strings are listed: *root.exe*, *cmd.exe*, *autoexec.bat*, *win.ini*, *boot.ini*, *config.sys*, *system32LogFiles*, * epair*, *system32*sam*, and *nobody.cgi*. These are all files and directories that are regularly targeted by many remote URI-based exploits. Figure 5-19. Common Windows File Exploits Data Set [View full size image]
Step 3.	To see how this data set or others like it can be applied, click Show Reference List at the bottom of the page.
Step 4.	Choose the number of the rule listed to go directly to the configuration page for that rule.

You can see that the data access control rule displayed in Figure 5-20 will deny Apache and IIS applications (per the application classes selected) the ability to access the data set defined by $Common Windows File Exploits. This data set enabled us to create a single rule to prevent many negative occurrences through the use of a reconfigurable variable.

File Sets

File sets are groupings of files and directories that you can link as a variable for a special purpose. You can apply file sets to file access control rules, which can control directory and file access permissions. Follow these steps to configure a sample file set:

Step 1.	Choose Configuration > Variables > File Sets [Windows]. A list of the predefined file sets for Windows displays, as shown in Figure 5-21. Figure 5-21. Predefined File Set Listing [View full size image]
Step 2.	Choose Command Shells from the list of file sets. Once again, this is very similar to what you would expect from any other variable; however, the data expected this time is related to directory paths and filenames. Notice that you do not need to specify the directory in this particular case, but you do specify the command shells you want to match. (See Figure 5-22.) Figure 5-22. Command Shells File Set [View full size image]
Step 3.	To see how the Command Shells file set can be applied, choose Show Reference List and then choose a numbered rule from this list, which will take you to the rule configuration page for that rule. The rule displayed in Figure 5-23 is Rule 12 from the installation file access control rule, described as follows: e-mail applications, user-invoked applications, and command shells. This rule is a high-priority deny for e-mail applications that attempt to read or write files that match any part of the Command Shells file set as well as another specific file set. Figure 5-23. Application of a File Set to a Rule [View full size image]

You can easily see the power of file sets as applied to file access control rules. You can create and use groups of file and directory strings, which can be extremely granular through the use of include and exclude matching patterns, that you then link to rules and application classes for very specific permissions.

When configuring UNIX file sets, you have an additional configuration option: content matching. By clicking Insert Content, you can select file types to match, which would be any of the following:

• Executable objects (binary executable files)

• Interpreter files (all files starting with she-bang; that is, #!)

• Java class files

Dynamically Quarantined Files and IP Addresses

Dynamically quarantined files and IP addresses are not natively configurable, but are manageable. This list, which is referred to as @dynamic, is dynamically populated when triggered rules exceed thresholds defined on the Global Event Correlation page shown in Figure 5-24. From this page, you can edit the thresholds and link to both the @dynamic list of current files and IP addresses.

When you click the link to view the current @dynamic list for files or IP addresses, you can then add to, remove from, or refresh the list. You will find this a very helpful place to visit when a new virus or worm has penetrated your network through an unprotected machine or has attempted to execute but was blocked.

Query Settings

Query settings is, a list of queries that users may be prompted with when asked about a particular action occurring on their machine. You can rephrase these queries as you deem appropriate for your environment and user base. It is extremely important that users under-stand what action they are taking when queried. Without a clear and precise message, a user might not select the desired response and, therefore, place the computing resource at risk. For example, this section looks at the query message For File Access - Downloaded Script Accessing Local System Resources, as shown in Figure 5-25. For this particular issue, the message shown to the user is “The Downloaded Script @appname is trying to access local system resources. This is potentially dangerous.” This message is very straightforward and simple. Messages presented to the end user should never be vague or too wordy.

To display specific information about what is occurring, you can use a feature called query tokens. Query tokens, such as @appname, are variables that contain information about processes and the local user or machine and can be used in the wording when laying out the text that displays to the user. The tokens and their descriptions are available in the CSA documentation, but some examples are @appname, @filename, and @localaddr.

To see how to apply a message to a rule, choose Show Reference List, and then choose a rule number to view. From the rule chosen, as shown in Figure 5-26, you can sees that when a rule has an action of query user, another drop-down box appears to the right asking you to select the appropriate query message to display.

When configuring a query message, you can choose which options the user should have available as well as the default action to take place if the user does not choose an action in the allotted timeframe. The three options are as follows:

• Allow (Yes)— Allows the application to access the resource

• Deny (No)— Denies the application access to the resource

• Terminate— Denies the application access to the resource and attempts to terminate the associated process

Other options that you can configure when creating query messages include the following:

• More Languages— Provides a query message in another language for localization based on end-user language.

• Don t Ask Again— Allows users to say that this action is either normal or abnormal at the time they are queried and to say remember my response instead of prompting me again. This type of caching lasts approximately one hour.

• Query Challenges— Ensures that a user is answering the query and not a malicious process. When Query Challenge is chosen, the query message displays a graphically produced string of characters that the user must manually enter into a text box for verification. If the user correctly enters the same string as seen in the graphic of the query response, the action is accepted by the local agent.

COM Component Sets

COM components sets are groups of COM program IDs and COM class IDs, which are typically referred to as PROGIDs and CLSIDs, respectively. When these are grouped into a COM component set, you can apply this new grouping to COM component access control rules to control access to COM objects matching this list. Like all the other sets discussed thus far, this type of set can also use wildcard pattern matching to create a more broad set of COM objects with fewer actual string definitions.

To show the typical configuration of a COM component set, first look at the appropriate configuration page in the CSA MC. To get to the correct page, choose Configuration > Variables > COM Component Sets. This page provides a listing of all COM component sets currently available, as shown in Figure 5-27.

Now that you have a list, choose the MS Office Objects set. Again, you see that this variable type is really no different in configuration from the other objects. At this point, you know that the only real difference between any of the variable types is related to the strings used for matching on that particular object and within what type of rule the particular set can be used. In this particular set, you can see the IDs you are matching listed one per line. Also note the wildcard pattern matching (*) used instead of listing every object possible. Figure 5-28 shows more detail.

To see how a COM object is used in a COM object access control rule, once again choose Show Reference List and link directly to a specific rule that is making use of this set. In Figure 5-29, you can see that this particular rule allows Microsoft Office applications (defined in an application class) to access the COM objects listed matched by the COM component set.

To assist in locating the COM object names that you will need to control access, every installation of CSA software includes a COM Object Extraction utility that enables you to view the COM objects available on the system in the CiscoCSAgentin directory. The executable to run on the system is extract_com.exe. In Figure 5-30, you see what it looks like when you run the COM Object Extraction utility from a command line. The file created by the utility, which you can open in a text editor such as Notepad, shows you the output provided. Specifically, this portion of the text file shows both PROGIDs and CLSIDs. The PROGIDs are at the top of the screen, and the CLSIDs are at the bottom.

Registry Sets

Registry sets are groups of explicit or wildcard strings that match registry keys and hives. Many programs, including viruses and worms, place keys throughout the registry, which provide them with configuration information at the next execute time. Also if certain keys are placed in the correct location, the application auto-executes at system boot.

Because the registry is a Microsoft-only concept, this set is available only to Windows agents. Be very careful when creating custom registry sets. If you inadvertently enter the wrong information to filter registry access, you could cause many issues with the function of the workstation or server. For this reason, always initially deploy registry access control rules in Test Mode.

When matching a registry key(s), you must first understand the syntax allowed and the rules necessary:

• Use of wildcards— Although you may use wildcards throughout the strings created to match keys, at least one of the entries in a string must not be a wildcard.

• Hive names— Here is a list of the acceptable hive names:

  • HKLM = HKEY_LOCAL_MACHINE

  • HKCR = HKEY_CLASSES_ROOT

  • HKCC = HKEY_CURRENT_CONFIG

  • HKU = HKEY_USERS (HKU* is all users)

In Figure 5-31, you can see an example registry set configuration. Here you can that this example is going to match using wildcards **SOFTWAREMicrosoftWindowsCurrentVersionRun**. This string will match any of the Run or RunOnce keys in the registry. When applied to a registry rule, you can deny the ability of applications to write to these keys. This would prevent many malware applications from installing themselves to auto-execute at boot.