Using Application Classes

Application classes are very important components in the CSA Management Console (MC) management architecture. Application classes are groups of applications (executables) that are common in function. This section reviews how CSA rules work so that you may better understand how application classes are applied and how they relate to rules.

When you define a CSA rule, most likely you are creating it so that you can deny or allow an action that might attempt to take place. You also define how and where that rule should be applied. In some cases, you might want a particular rule to apply to every process running on the endpoint. An example of this is a rule that denies an endpoint the ability to use the Telnet (TCP/23) protocol no matter what application is attempting this specific network connectivity. However, when creating the rule, you might more granularly decide to allow Telnet from the endpoint, but only from a specific set of capable applications. To take that a step further, you might also want to monitor the application and subprocesses started by that specific application. Application classes enter the equation at this point. By defining an application class, which includes the specifically allowed Telnet clients (or executables), you can then apply the rule to only those applications and subprocesses.

Do not worry if you do not fully grasp the concept of using application classes just yet. It is a very important concept, and the upcoming sections illustrate application class usage by example.

Purpose of CSA MC Built-In Application Classes

The CSA MC includes some built-in application classes to get you started. These application classes initially serve two purposes:

• Functional The built-in application classes are fully functional and in most cases are being used by many of the predefined rules and policies that come preconfigured on the CSA MC.

• Tutorial Although the main purpose of the built-in application classes is for you to deploy efficient, fully functional predefined policies quickly, they can also serve as a tutorial for those who want to create their own application classes.

To acquaint you with application classes, this section first looks at some of the built-in classes to discover the basic settings and configuration. To see a list of built-in application classes, you need to get to the Application Classes Configuration screen by choosing Configuration > Applications > Application Classes [Windows]. (See Figure 5-1.)

Figure 5-1. Application Classes Menu Selection Location

NOTE

This book uses Windows for the majority of examples to simplify the learning process.

Configuring Application Classes

The Application Classes Configuration screen lists the currently defined application classes, which you can sort to show all, Windows-specific, or UNIX-specific application classes by changing the selection in the drop-down selection box in the upper-left corner of the screen.

You can perform other tasks from this screen, too, such as create a new application class, delete an application class, clone an application class to create a similar application class, or just compare two application classes by clicking the respective buttons at the lower-left corner of the web page. Figure 5-2 shows the drop-down selection field and the action buttons.

Figure 5-2. Application Classes Overview Page

To view the configuration of an already created application class, use the scroll bar until you locate the application class you want to view or edit, and then click the name of the application class.

For example, choose the Command Shell application class to view a basic configuration. Figure 5-3 shows the Configuration page of the Command Shell application class.

Figure 5-3. Example Application Class Configuration: Part 1

You have only a few tunable parameters and clickable links available when configuring an application class. The following list describes this specific application class page from the top to the bottom of the Configuration page:

• View Change History Click this link to view the changes made to this application class. The changes are tracked as part of the local audit process.

• Name Enter a name that is recognizable and descriptive to ease the configuration of rules.

• Description and Detailed Description Type a brief description of the purpose for the application class in the Description field and enter a much more descriptive analysis of the purpose for this object in the Detailed window.

• Operating System Change the drop-down choice to be more specific to the particular Windows operating system, such as NT, 2000, XP, or 2003. (Because this example is for a Windows environment, the Target defaults to All Windows.)

• Display Only in Show All Mode If your application class list is getting unmanageably long, you can use this check box along with the Admin Preferences page that is discussed in Chapter 14, "CSA MC Administration and Maintenance," to hide this application class from the Selection window, which narrows the options when you are choosing classes.

• Add Process to Application Class Define which processes are part of the application class. You have two options:

  • When Created from One of the Following Executables Enter the information regarding what specific executables you want to include in the grouping. You also can check Insert File Set to include an already grouped listing from a file set variable.

  • When Dynamically Defined by Policy Rules Check this option to create a dynamic application class that will be created by application behavior rather than executable name or file set definition.

  Tip

  Occasionally, you might want to group applications or processes by their exhibited behavior such as specific file, registry, or network access rather than by explicit process name. Grouping like this proves especially helpful when attempting to control behavior of any application that matches your application class behavior definition without the upfront knowledge of every application that could behave in such a way.

  
  

• Remove Process from Application Class Click the check box and specify a time in seconds if you want the monitored process to be removed from the application class after a predetermined amount of time. You rarely have a reason to select this option. You might have a process that needs temporary access to protected system resources for a certain time period. You could use this option to temporarily give the application extra access, without permitting the process to continue with the excessive rights over too long a timeframe. A process with excess access to a system might be eventually compromised and could provide other processes proxy access to normally protected resources.

• This Application Class Includes Applications commonly spawn subprocesses to complete tasks. Because these subprocesses could be the application you want to deny, you can dynamically include those processes in the application class while they are active. You have three possible choices under this heading:

  • Only This Process Check this option if you want the application class to include only this process and never dynamically add subprocesses to the application class.

  • This Process and All of Its Descendents Check this option to dynamically include spawned subprocesses. A rogue malicious process commonly launches other processes that might attempt certain undesirable actions. Checking this option ensures that the root process and anything spawned by it are also added to the application class and controlled with the same rules.

  • Only Descendents of This Process Check this option to include only subprocesses and never the listed root application process itself. Most commonly, you use this selection in an exception rule such that you apply a rule to the subprocesses and not the main application.

• Show Reference List Click this link to show the rules that are using this application class. This option proves very helpful when attempting to troubleshoot an application class, because the links provided are clickable and bring you directly to the rule Configuration page you select without the need to search for the rule on the Rules page.

You can see from the predefined Command Shell application class example configuration that this class is Windows specific and enables you to apply rules to the processes related to your specifically named command shells. This particular application class is used in several predefined modules and several rules that are listed by number and are clickable links. (You can display this information by clicking Show Reference List, as mentioned earlier.)

Now that you know the specific rules and modules that this example relates to, take a look at an example of how to apply it. In this example, Rule 121, as shown in Figure 5-4, is a rule within the Required Windows System module that uses the Command Shell application class. You can translate Rule 121 to read as follows: Allow and do not log when desktop interface applications attempt to run applications in the Command Shell application class. You can see that the goal of the rule is to allow desktop applications to launch command shells on your protected endpoints.

Figure 5-4. Rule 121 Using the Example Application Class

Built-In Application Classes

You can use built-in application classes when defining rules, but you cannot edit them in the application class Configuration page. These application classes are also predefined on the CSA MC at installation time, but differ in that they are not configurable but can still be used in your rules. They serve very special purposes and use underlying code to provide classification rather than the CSA MC variables other application classes use. Built-in application classes display differently from other application classes in that they are surrounded by brackets (for example, <All Applications>), as shown in Figure 5-5.

Figure 5-5. Built-In Application Classes

NOTE

There are two types of built-in application classes: editable and noneditable. Editable built-in application classes are identified by the asterisk in the name after the opening bracket, whereas noneditable built-in application classes are in brackets but do not include the asterisk in the name.

Configurable built-in application classes are also surrounded by brackets, but include a leading asterisk in the name (for example, <*Suspected Virus Applications>). You can configure these built-in application classes, but you can use them only with a rule that dictates what causes processes to become classified as one of these particular application types. You can edit the classes with asterisks (*); however, you should do so only if absolutely necessary. Built-in application classes that do not have the asterisk in front of their name have a special purpose; therefore, you cannot edit them.

NOTE

You can find a complete list of the built-in application classes and their descriptions in the CSA MC online Help documents via the Help link at the upper-right corner of all CSA MC web pages.

Here is a list of some of the built-in application classes:

• First Time Application Execute Includes executables the first time they are run on a system since the installation of the CSA

• Network Applications Includes any process that connects as a client or server accessing the network.

• Processes Created by Network Applications Includes any process started by a network application

• Processes Monitoring the Keyboard Includes all processes that monitor keystrokes

The following list includes a few of the built-in configurable application classes:

• Installation Applications Includes processes that are installing software on the protected agent machine

• Processes Copying Untrusted Content Includes processes that copy executables that should not be trusted and have arrived on the system as downloaded content

• Processes Executing Untrusted Content Includes every downloaded executable or running process that interprets downloaded content

Introducing Static and Dynamic Application Classes

Application classes are extremely important to CSA success and past performance. Within application classes, you can explicitly identify certain processes by name; such processes are called static application classes. You can also create an application class whose members dynamically change over time as certain processes exhibit specific behaviors. The next few sections examine these two application class types.

Creating a Static Application Class

Static application classes relate to applications you know are running in your environment that you want to control through CSA rules. You can create an application class by following these steps:

Step 1.	Choose Configuration > Applications > Application Classes [Windows] from the navigation bar.
Step 2.	Click New at the bottom of the page.
Step 3.	Create a name. The example shown in Figure 5-6 uses Test Telnet Application Class. The name should always be fairly descriptive to make future configuration and management tasks easier. Figure 5-6. Static Application Class
Step 4.	Create a brief description. This example includes the following brief explanation of the use for this class: App class to control our known enterprise Telnet apps.
Step 5.	Check Detailed if you want to include a more complete description or other notes.
Step 6.	Choose the target operating system. The main operating system is already shown as Windows because you created this from the Windows page, but you might want to specify the more specific Windows version, such as NT, XP, 2000, or 2003, to which this class will relate. Leave this as All Windows for this example.
Step 7.	Add your specific known Telnet applications to the list under Add Process to Application Class When Created by One of the Following Executables. You will need to add your enterprise applications, which for this example are **\telnet.exe and **\telnet32.exe.
Step 8.	To ensure you are watching subprocesses that the preceding two executables may spawn as well as the main process, check This Process and All of Its Descendents.
Step 9.	Finally, click Save to accept the changes to the newly created application class.

By following these steps, you create a new application class that includes the main process and any subprocesses resulting from executing either telnet.exe or telnet32.exe on a protected Windows system. Now that you have defined this application class, you can apply rules to control the behavior of the included processes.

Configuring Dynamic Application Classes

Dynamic application classes differ from static application classes. Whereas static classes refer to the name of the associated executable or process you want to group, dynamic application classes are grouped based on the behavior of applications and processes. This grouping enables you to benefit from the efficiencies gained through application classes without the need to know exactly which applications are running in your enterprise.

In the example static application class created in the previous section, notice one major issue: You needed to know the exact name of the application you wanted to control via CSA rules. This requirement is fine if you can guarantee that telnet.exe and telnet32.exe are the only two applications on your enterprise workstations that use the Telnet protocol, but having this level of control is unlikely. Other examples of applications that you might want to group via protocol rather than name include the following:

• E-mail (POP, IMAP, and SMTP protocols)

• Web servers (HTTP and HTTPS protocols)

• TFTP servers (TFTP protocol)

Applications that behave "well" from a protocol standpoint are easily mapped to dynamic application classes, but other applications, such as instant messengers and peer-to-peer file-sharing applications, might try several communication protocols to get a connection and might be best grouped via static application classes.

You can also add a process to a dynamic application class via the outcome of a rule that queries a user for a response. By choosing Terminate when a process attempts an action denied by another rule, you can add that new process to an application class that could further control the questionable process.

Consider the Telnet example previously used to demonstrate how static application classes work, but this time use a dynamic application class. Follow these steps to create a dynamic application class:

Step 1.	Choose Configuration > Applications > Application Classes [Windows] from the navigation bar.
Step 2.	Click New at the bottom of the page.
Step 3.	Create a name. The example shown in Figure 5-7 uses Test Telnet Dynamic Application Class. Figure 5-7. Dynamic Application Class
Step 4.	Create a brief description. This example includes the following brief explanation of the use for this class: Dynamic app class to control Telnet apps.
Step 5.	Check Detailed if you want to include a more complete description or other notes.
Step 6.	Choose the target operating system. The main operating system is already shown as Windows because you created this from the Windows page, but you might want to specify a more specific Windows version, such as NT, XP, 2000, or 2003, to which this class will relate. For this example, leave this as All Windows.
Step 7.	In the Add Process to Application Class section, check When Dynamically Defined by Policy Rules. By using policy rules to dynamically create the grouping, you do not need to explicitly define the applications you want to control by name.
Step 8.	To ensure you are watching subprocesses as well as the main process, check This Process and All of Its Descendents.
Step 9.	Click Save to accept the changes to the newly created application class.

Creating the dynamic application class itself is only half of the required configuration for it to be useful. To make the dynamic application class useful to you, you need to identify the processes that should be grouped by this class. To do this, you must create an application builder rule that identifies the processes and adds them to the dynamic application class based on the process behavior. Follow the next steps to create the application builder rule:

Step 1.	Choose Configuration > Rule Modules > Rule Modules [Windows].
Step 2.	Either create a new module or select an existing module.
Step 3.	Choose Modify Rules from the top of the specific module page you either selected or created.
Step 4.	Click Add Rule > Network Access Control (see Figure 5-8). Figure 5-8. Network Access Control Rule Selection
Step 5.	Create a description. This example uses the following description: App builder rule for Telnet. You can also include a detailed description if necessary.
Step 6.	Under Take the Following Action, choose Add Process to Application Class, as shown in Figure 5-9. Figure 5-9. Application Builder Rule
Step 7.	A new drop-down selection box appears to the right. From this new drop-down, choose the previously defined dynamic application class, which was named Test Telnet Dynamic App Class. This process associates this application builder rule with your application class.
Step 8.	Specify enforcement action(s) Terminate, Deny, or Allow to make the process part of the application class based on the specific user response.
Step 9.	Under Applications in the Following Class, leave <All Applications>, which allows any application on the protected endpoint to trigger this rule. You can limit this if desired.
Step 10.	Because you are trying to control Telnet client applications with this particular application class, choose Client from the pull-down list.
Step 11.	In the Network Services box, configure the protocol and port information that you will use to classify your applications as Telnet clients. Type TCP/23 to denote Telnet traffic. Note Alternatively, you can select $TELNET as the network service, which is a predefined variable. You learn more about variables later in this chapter in the "Introducing Variables" section.
Step 12.	The next options relate to the IP addressing of the local host and the remote destination of our communication. For this example, leave 0.0.0.0-255.255.255.255, which applies this application class and rules to all local and remote networks. If you want to apply this application class and the subsequent rules only to Telnet traffic to specific destinations or networks, you can modify these settings.
Step 13.	Finally, to complete the creation of the application builder rule, click Save to make the changes permanent.

You have now completed the creation of an application builder rule that identifies any Telnet (TCP/23) traffic from a protected machine and places the client application (or process/subprocess) into an application class. This dynamic application class will be a list of Telnet client processes that you can now monitor or control with other rules applied to the same clients. You can see that the few extra steps it takes to define these objects and rules gives you greater control over your network endpoints without the need for an exhaustive enterprise application audit and the naming of very specific applications.

To complete this example, the next steps configure a rule that uses the dynamic application class to deny Telnet applications from running on the endpoints. To create this rule, add another application control rule to the same module as you used for the application builder rule, and then follow the remaining steps, which are shown in Figure 5-10:

Step 1.	Add a description and a detailed description if desired.
Step 2.	Under Take the Following Action, choose Terminate Process.
Step 3.	In the Applications in Any of the Following Selected Classes menu, choose the example dynamic group called Test Telnet Dynamic App Class.
Step 4.	As the final step to this entire process, click Save to commit the changes to this new rule.

Figure 5-10. Applying the Dynamic Application Class

You have now completed many steps. Without knowing the exact name of the Telnetcapable clients on your network or the location where they reside in the file structure, you are now certain that if any Telnet client runs and attempts to communicate over TCP port 23, you will terminate that application and send an event to the CSA MC for possible further examination.

Managing Application Classes

If you think you have too many application classes listed in the various application class selection boxes used throughout CSA MC configuration pages for rules, application deployment investigation, and application behavior investigation, you can limit the selection that is viewable on those screens. You control which ones show up by choosing Configuration > Applications > Application Class Management. From the Application Class Management window, you can enable or disable application classes for various portions of the CSA MC. Figure 5-11 shows an example of this screen.

Figure 5-11. Application Class Management

Controlling Shell Scripts

You should control shell scripts on UNIX systems because their execution and compromise could affect the security of your UNIX system. When attempting to use application classes to control shell scripts on UNIX machines, you need to understand a few things.

To succeed, the scripts must satisfy two requirements:

• The script must begin with an interpreter string, such as #!/bin/bash. (#! should be read as she-bang.)

• The script must be executed directly from the command line.

Other methods for launching a script can circumvent your attempt at adding a script to the dynamic application class. It is very important that you use solid UNIX endpoint security to disallow many of these alternative methods to ensure your application classes succeed in achieving your goals.

System Processes

Any application class you create will never include system processes. To include these processes in a rule along with the application class you created, you must include the built-in classes <System Processes> or <All Applications> along with your application class, which would include the nonsystem processes you want to match.