Using Management Center for Cisco Security Agents 6.0.1 - Using Application Classes [Cisco Security Agent]

Table Of Contents

Using Application Classes

Overview

About Application Classes

Types of Application Classes

Processes Created by Application Classes

Membership in Application Classes is Ephemeral

Managing Application Classes from the List Page

Shell Scripts and Application Classes

Built-in Application Classes

Built-in Configurable Application Classes

Configuring Static Application Classes

Dynamic Application Classes

Building Classes as Rule Consequences

Removing Processes from Classes

Effective Dynamic Application Classes

Configuring Dynamic Application Classes

Configure Application-Builder Rules

Configure a Rule Using a Dynamic Application Class

Create New Application Classes from Rule Pages

Application Class Management

Using Application Classes

Overview

This chapter explains the application classes shipped with CSA MC and provides instructions for creating new static and dynamically defined application classes.

This section contains the following topics:

•About Application Classes

–Processes Created by Application Classes

–Membership in Application Classes is Ephemeral

–Shell Scripts and Application Classes

•Built-in Application Classes

–Built-in Configurable Application Classes

•Configuring Static Application Classes

•Dynamic Application Classes

–Effective Dynamic Application Classes

–Configuring Dynamic Application Classes

–Configure Application-Builder Rules

–Configure a Rule Using a Dynamic Application Class

•Create New Application Classes from Rule Pages

•Application Class Management

About Application Classes

Application classes are groups of similar application files that are identified with a unique name. For example, the Web Browser Applications application class, that is shipped with this release, contains commonly used web browser applications such as Internet Explorer, Firefox, and Safari.

Consider the applications your enterprise uses and the manner in which you want to limit those applications' abilities to perform undesired actions. Then, create an application class for groups of similar applications.

Access control rules specify which applications, or application classes, can access resources, such as directories, files, network addresses, registry keys, or COM components. By specifying an application class in an access control rule, the freedoms and restrictions of the rule are applied uniformly to all applications included in the application class.

Types of Application Classes

Built-in Application classes are shipped with this release of CSA MC. You can view them at the bottom of the Application class list page. Built-in application classes in brackets like, <Network Applications> cannot be edited. Built-in application classes in brackets with an asterisk, such as <*Installation Applications> are dynamically defined by rules. See Built-in Application Classes and Built-in Configurable Application Classes for more information.

Static application classes identify a group of designated applications. The list of applications in the class can be modified but it cannot be redefined "on the fly." See Configuring Static Application Classes for more information.

Dynamic Application Classes are populated when a rule is triggered. For example, Active Internet Application is an application class included with this release. It is defined by a rule which acts in this way: If any application, acting as a client, and requesting TCP or UDP services, attempts to reach an external IP address, then add that application to the Active Internet Application class. See Dynamic Application Classes for more information.

Processes Created by Application Classes

When applications are invoked, they often spawn other processes as part of the action they are performing. Therefore, when you create an application class, CSA MC gives you the option of including or excluding processes created by the original applications you define as part of the application class.

Membership in Application Classes is Ephemeral

Processes are part of a configured application class when they are running on the system. When the process stops running, the CSA MC application classification for that process also ends. Should the process begin again, it may or may not fall into the same application class depending on the process's behavior and on the definition of the application class. Therefore, all application classifications are ephemeral and are constantly being re-evaluated and classified on the system.

The application class configuration page lets you control how long a process maintains a certain application classification. In general, you do not have to specify a time frame. You should only put a time limit on an application classification if you are configuring rules that require it for a particular reason. For example, you may want to create special process start rules for an application. The classification of the process could be configured to time out once the system is finished booting.

Managing Application Classes from the List Page

From the Application Class list page, you can create new application classes, view existing application classes, delete, clone and compare application classes. See Creating, Saving, and Deleting Data, page 2-23 for more information.

Shell Scripts and Application Classes

On UNIX systems, the agent allows control over shell scripts which satisfy both of the following conditions:

•the script begins with an interpreter string (e.g., #!/bin/bash)

•the script is executed directly on a command line,
e.g., "$foo.sh".

Therefore, if you have an application class "foo.sh", a process satisfying the
above conditions becomes a member of that application class.

Note that a shell may be launched by various methods which do not meet those conditions, e.g., "$ . foo.sh", or "$ cat foo.sh | /bin/sh". Note also that if you happen to have an application class for a script's interpreter -- say,
/bin/bash -- when you invoke the script, the process becomes a member of
the /bin/bash application class.

If a user has write access to the disk, and can execute commands, then
using the name of a shell script in a rule to DENY actions may not make
sense. For example, denying access by foo.sh to modify /etc/hosts does
not improve the protection of /etc/hosts as the user could just run 'vi /etc/hosts'. It would make more sense to deny everything access to a
file, and then permit known good scripts access to that file.

Note In general, with scripts such as perl scripts, the agent's ability to place the script in a configured application class depends upon whether the interpreter executes the script (via exec) or simply reads it. In the first case, the agent does recognize the script. In the latter case, it cannot.

Caution If the user can copy a script (or re-implement it) to a file of their choice, then any Deny rules would be avoided.

Note On Windows, when writing rules for script application classes, you can create the rule for either the script itself or for the interpreter. (Scripts are handled by script interpreters.) If you write the rule for the interpreter, it will include the script handled by that interpreter.

Built-in Application Classes

CSA MC ships with several built-in application classes. Those application classes appear inside brackets, such as <First Time Application Execute> (see Figure 9-1). Some built-in class are also marked with asterisks, such as <*Installation Applications>. An asterisk indicates that the built-in application class is configurable. See Built-in Configurable Application Classes. You can view all application classes in the Application Class list page.

To access this page, mouseover Configuration in the menu bar and navigate Applications > Application Classes.

Figure 9-1 Built-in Application Classes

Some included application classes are:

•First Time Application Execute—This includes the first invocation of any application which has never been observed to execute on the system.

•Network Applications—A network application would include any process that connects as a client or accepts a connection as a server and has in some manner accessed the network. The process would fall into this network application class after it has accessed the network. (This does not include applications that communicate only with other applications on the same system.)

•Processes created by Network Applications—This includes any process that is launched by a network application. For example, one network process may create another process that attempts to download code. This is one way viruses are propagated.

•Processes created by Servers (TCP and UDP)—This includes any TCP or UDP process invoked by a server (falling into the categories detailed in the two following bullet points).

•Server (TCP based)—This application class includes all processes that have accepted an inter-box connection on a non-ephemeral port.

•Server (UDP based)—This application class includes all processes that have accepted an inter-box connection on a non-ephemeral port.

•Processes Monitoring the Keyboard—This includes all processes which continuously monitor keystrokes over an extended period of time.

•Processes with elevated privileges—This application class is only available for UNIX rule types. It includes processes that have elevated user privileges for users other than root, such as ping. Using such processes is a common way to attempt a system break-in. Note that this elevated privilege designation does not apply to processes when the user is logged in as root.

•Processes performing a Print Screen—This includes all processes that access the print screen function. This class is available in the Clipboard access control rule to provide further protections to clipboard data by including print screen captured data.

•Recently created untrusted content—This includes executables that are newly created by <Processes writing untrusted content> and are immediately invoked.

•Remote clients—When a remote machine accesses resources over the network that are protected locally by an agent, the agent sees the remote access attempt as coming from a "remote application." The actual application that is used to open the resource in question cannot be determined on the local system. All remote access attempts are seen by the local system as being invoked by a remote application.

Therefore, if you are writing rules for a machine that other machines can access over the network, you must include <All Applications> or <Remote clients> as your application class. Otherwise, the rule will not work as expected in regard to remote access to those resources.

•System Process (available only in Network Access Control rules)—Using this application class, you can control network access for the operating system itself (as opposed to applications running on the operating system).

Caution Any application class that you define does not include the system process. If you want to include the system process in a rule, you must select the included, built-in <All applications> or <System process> classes.

Built-in Configurable Application Classes

The Management Center for Cisco Security Agents also ships with built-in application classes that are built by policy rules. These application classes appear inside brackets with asterisks before them (*) in the rule application class selection list boxes (see Figure 9-1). This means that you should only use them in conjunction with a rule module that dictates the parameters that causes processes to become classified as one of these application types. CSA MC ships with pre-configured policies to define these classes. You can change these policies, if necessary.

•Installation Applications—This includes processes installing software.

•Processes Executing Untrusted Content—This includes any downloaded executable or any process that is interpreting downloaded content.

•Processing requiring Kernel Only Protection—This is intended to remediate interoperability issues with CSA's user component and other third party software products. Processes in this class will not enforce COM component checks and some buffer overflow checks.

•Processes requiring OS Stack Execution Protection—This application class is only available for UNIX rule types. This is intended to enable native Solaris operating system stack execution protection emulation. This enables additional buffer overflow protection.

•Suspected Virus Applications:—This application class includes processes dynamically defined as being suspect by specified, exhibited behavior. Being classified as belonging to this application causes a quarantine message to be sent to CSA MC.

•Third Party Security Applications:—This application class is used to mark other security products which may attempt to control similar resources as CSA. This application class provides certain built-in permissions to facilitate interoperability and system stability.

Configuring Static Application Classes

See About Application Classes for information on Static Application Classes and how they compare to Dynamic Application Classes and Built-In Application Classes.

See also Built-in Application Classes and Effective Dynamic Application Classes.

To create an application class, do the following:

Step 1 Log in to the CSA MC as a user with configure privileges and switch to Advanced Mode.

Step 2 From the CSA MC menu bar, mouseover Configuration and navigate Applications > Application Classes.

Step 3 Click the New button to create a new application class.

Step 4 If you have not set an operating system admin preference, select whether this is a Windows or a UNIX rule module from the pop-up box that appears.

Note UNIX generically refers to both Solaris and Linux operating systems.

This takes you to the application class configuration view (see Figure 9-2).

Step 5 Enter a Name and a Description for the new application class. The description appears in the application class list view. Optionally, expand the +Detailed field to enter a longer description.

Step 6 In the OS list box, select a particular Windows or UNIX operating system for which this application class is intended. To specify all UNIX-type operating systems, select <UNIX>. To specify all Windows-type operating systems, select <Windows>.

Step 7 Under Add process to application class, for a static application class, do the following:

Leave the default when created from one of the following executables radio button selected. Then enter the executable file names (one per line) for the applications you are grouping together in this application class. See Directory and Filename Syntax Requirements, page 2-30 for more information about entering literal file names in the field.

Note You can enter preconfigured File Set variables in the executables edit field by clicking the Insert File Set link. To learn more about File Sets, see File Sets, page 8-9.

Step 8 Remove process from application class—Select the checkbox beside After and enter a time frame in seconds to configure an application classification which expires after a period of time. Only use this feature if you have a rule that requires it. In general, you do not have to specify a time-out for application classifications. See Membership in Application Classes is Ephemeral for details.

For UNIX application classes, you have the additional option of selecting the When session association is voided checkbox. Selecting this checkbox causes the application classification to be removed when a process disassociates itself from the current TTY session. For example, when an application class exists for applications descended from "superuser", you might not want the process to continue having the application class of the superuser shell.

Step 9 This application class includes: When applications are invoked, they often spawn other processes as part of the action they are performing. When you create an application class, select one of the following radio buttons to determine when processes spawned by the applications in the application class are also included.

•Only this process

•This process and all its descendents

•Only descendents of this process

Note Creating an application class for "Only descendents of this process" is useful when making exceptions to a rule that is written for the main process itself. For example, you can write a rule allowing IIS to talk on the network, but create another rule denying descendents of the IIS process from talking on the network.

Step 10 When you are finished, click the Save button. The new application class name now appears in the application list view and in the application selection fields for rule configurations.

Tip There is a red Tasks menu in the upper right corner of the page. Clicking the down arrow, expands the menu. This menu provides quick links to common tasks that are relevant to this application class.

Figure 9-2 Static Application Class

Dynamic Application Classes

Dynamic application classes are made up of applications or processes that have exhibited a behavior defined by a rule. In contrast, static application classes are made up of a list of executable file names or process names. There are built-in dynamically defined application classes in this release of CSA MC. For example, the <*Processes Executing Downloaded Content> application class is a "built-in" dynamically defined class. By viewing the references for this built-in dynamic application class, and other built-in dynamic application class, you can see which rules add applications and processes to the application class. See About Application Classes for more information on static, dynamic and built-in application classes.

One example of an instance in which you might use a dynamic application class would be if you are writing rules for email clients but you do not know all the different email applications that are being used throughout your corporate network. In this case, you could use a dynamic application class. Any process appearing to act as a client for SMTP (you can use whatever criteria you decide to define what an email application is) would fall into a dynamic email application class that could be used in rules quarantining dangerous email messages.

Note A dynamically defined application class can be used in any rule where a static application class can be used.

Building Classes as Rule Consequences

You can also build a dynamic application class as a consequence of rules triggering. This way, for example, you can configure a query user rule in which a process is added to an application class as a result of a specific user response (yes, no, terminate). For example, you can build a "suspected virus" application class based on the end user being queried when untrusted content arrives on the desktop and the Terminate button on a query box is clicked to disallow it. But if the user clicked Yes to allow it, the process would not be added to the suspected virus application class.

Removing Processes from Classes

You can also use a dynamic "remove process" capability in conjunction with dynamically adding a process. For example, you can dynamically add a process to a "suspicious web server descendents" class if a web server spawns a process. Then, if that spawned process attempts to read a script from a normally accessed directory, you can decide this isn't a dangerous process and have the process removed from the class after the attempt. But if the spawned process attempts to read a script from a directory it should not be accessing, the process should remain in the suspicious web server descendents class.

Effective Dynamic Application Classes

Effective dynamic application classes work together with application builder rules and enforcement rules. To use a dynamic application class effectively, you need to configure the following objects:

Step 1 Create the new dynamic application class by following the Configuring Dynamic Application Classes. A dynamic application class is populated by processes defined in an application-builder rule.

Step 2 Configure an application-builder rule to identify the processes to add to the dynamic application class. See Configure Application-Builder Rules for more information.

Step 3 Configure other rules to control the actions of all the applications added to the dynamic application class. See Configure a Rule Using a Dynamic Application Class.

Configuring Dynamic Application Classes

This procedure describes how to create a dynamic application class. For a dynamic class to be effective, administrators also need to Configure Application-Builder Rules and Configure a Rule Using a Dynamic Application Class. This procedure is the first of three that describe how to create an effective dynamic application class.

To better illustrate how the dynamic application class and rules interact, these three procedures are written with a common example in mind and, where noted, make specific choices to achieve the goal of the example.

Example: You want to write rules quarantining dangerous email messages but you do not know all the different email applications that are being used throughout your corporate network.

To create a dynamic application class, do the following:

Step 1 Log in to the CSA MC as an administrator with configure privileges and switch to Advanced Mode.

Step 2 From the CSA MC menu bar, mouseover Configuration and navigate Applications > Application Classes.

Step 3 Click the New button to create a new application class.

Step 4 If you have not set an operating system admin preference, choose whether this is a Windows or a UNIX rule module from the pop-up box that appears. Note: UNIX generically refers to both Solaris and Linux operating systems.

Step 5 Enter a Name and a Description for the new application class. The description appears in the application class list view. Optionally, expand the +Detailed field to enter a longer description. For our email client example, name the dynamic application class Email_clients_dynamic.

Step 6 In the OS list box, select a particular Windows or UNIX operating system for which this application class is intended. To specify all UNIX-type operating systems, select <UNIX>. To specify all Windows-type operating systems, select <Windows>.

Step 7 In the Add process to application class area, for a dynamic application class, select the when dynamically defined by policy rules radio button.(Do not enter any process names in the edit field.)

Step 8 Remove process from application class: Select the checkbox beside After and enter a time frame in seconds to configure an application classification which expires after a period of time. Only use this feature if you have a rule that requires it. In general, you do not have to specify a time-out for application classifications. See Membership in Application Classes is Ephemeral for details.

For UNIX application classes, you have the additional option of selecting the When session association is voided checkbox. Selecting this checkbox causes the application classification to be removed when a process disassociates itself from the current TTY session. For example, when an application class exists for applications descended from "superuser", you might not want the process to continue having the application class of the superuser shell.

Step 9 When applications are invoked, they often spawn other processes as part of the action they are performing. When you create a dynamic application class, you can select one of the following radio buttons (just as you can when you create a static application class) to determine when processes spawned by the applications in the dynamic application class are also included.

For the email client example, we will leave the default, Only this process, selected.

•Only this process

•This process and all its descendents

•Only descendents of this process

Step 10 When you are finished, click the Save button. This dynamic application class name now appears in the pulldown list beside the Add to application class radio button in access control rules and in all application selection fields.

Next we will use this dynamic application class in an application-builder rule. Continue with Configure Application-Builder Rules.

Figure 9-3 Dynamic Application Class

Configure Application-Builder Rules

This procedure describes how to create an application builder rule. This is the second of three procedures that describe how to create effective dynamic application classes. This procedure will be more meaningful if you have already completed Configuring Dynamic Application Classes. After this procedure, go to the Configure a Rule Using a Dynamic Application Class.

To better illustrate how the dynamic application class and rules interact, these three procedures are written with a common example in mind and, where noted, make specific choices to achieve the goal of the example.

Example: You want to write rules quarantining dangerous email messages but you do not know all the different email applications that are being used throughout your corporate network.

In this procedure, we are going to use a Network access control rule to define our dynamic application class. You can use any access control rule type as your application-builder rule. (Remember, your dynamic application class is not populated with applications until an application-builder rule is triggered by the process's behavior and added to the class.) This rule type takes precedence over all others in the policy. This rule type does not override other rules in the policy the way allow, deny, and query rules do when triggered.

Note Defining dynamic application classes from the Application control rule is a bit different than creating them from other rule types. Because this rule has two application class fields, you can choose to add the current application to the dynamic class or choose to add the new application that is invoked by the first application to the dynamic class.

Caution Dynamic application class process membership is temporary and is based on a running process meeting the criteria in the application-builder rule. When the process is no longer running on a system, it is no longer included in the dynamic class.

To prevent errors or unexpected behavior, you should avoid selecting the dynamic application class for a rule within a policy that does not also include the corresponding application-builder rule. Both the application-builder rule and the subsequent rule(s) that use the dynamic application class should co-exist within the same policy—although this is not required.

Step 1 Log on to the CSA MC as an administrator with configure privileges and switch to Advanced Mode.

Step 2 Rules can only be added to existing rule modules. For our email client example, create a rule module called Email Client Example using Configuring Rule Modules, page 5-2.

Step 3 Open the Email Client Example rule module you just created.

Step 4 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.

Step 5 Select Network Access Control rule from the list of rules. This takes you to the configuration view for this rule type.

Step 6 Follow the procedure for creating a Network Access Control rule on page 6-20. For our email client example, make the following configuration choices:

•Enter a description

•In the Take the Following Action listbox, select Add process to application class from the pulldown list as the rule action. Select the dynamic application class, Email_clients_dynamic, from the corresponding pulldown list. This rule type takes precedence over all other types. The only action of this rule is to build the application class for any subsequent rules within the policy that make use of it.

•In the When - An enforcement action of the following type occurs field, leave the default, <All Applications>, selected in the Application class field. This way, all applications that trigger the rule have the potential of being added to the dynamic class. You could select a specific application class here if you only want members of that application class to fall into the dynamic class.

•Select client from the pulldown list and select the pre-configured variable, $Email, from the list of configured Network services.

•In the Communicating with host address field, leave the default <all>.

•In the Use these local interfaces field, leave the default <all>.

•Specify all the enforcement actions: Allow by default, Terminate, Deny, Allow. This means that the tag will apply when the request is made regardless of the action that occurs. All actions apply. If you make a specific selection here, you are determining to create your dynamic application class based on that action occurring when the request is made (perhaps via another configured rule). You should note that all resource requests always result in either an allow, deny, or terminate occurring. Even if there is no rule governing the resource, for example, the implicit action is allow.

Step 7 Click Save.

Now, based on the application-builder rule we've just configured, any application which uses the network services, SMTP, POP3, IMAP3 or IMAP2 as a client to access any system on the network, will fall into the Email_clients_dynamic application class.

Next we will use this dynamic application class in a rule that will control its actions. Continue with Configure a Rule Using a Dynamic Application Class.

Configure a Rule Using a Dynamic Application Class

This procedure describes how to define a rule that uses a dynamic application class. This is the third of three procedures that describe how to create effective dynamic application classes. This procedure will be more meaningful if you have already completed Configuring Dynamic Application Classes and Configure Application-Builder Rules.

To better illustrate how the dynamic application class and rules interact, these three procedures are written with a common example in mind and, where noted, make specific choices to achieve the goal of the example.

Example: You want to write rules quarantining dangerous email messages but you do not know all the different email applications that are being used throughout your corporate network.

In this example, we are going to use a File Access Control Rule to control the actions of a dynamic application class.

Step 1 Log on to the CSA MC as an administrator with configure privileges and switch to Advanced Mode.

Step 2 Open the Email Client Example rule module that you created in the Configure Application-Builder Rules procedure.

Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up.

Step 4 Select File Access Control from the list of rules. This takes you to the configuration view for this rule type.

Step 5 Follow the procedure for creating a File Access Control rule on page 6-16. For our email client example, make the following configuration choices:

•Enter a description

•From the Take the Following Action list box, select the Deny action.

•In the Applications in any of the following applications classes list box, select the dynamic application class you created in Configuring Dynamic Application Classes, Email_clients_dynamic.

•Select the read file and write file checkboxes in the Attempt the following operations area.

•Enter @dynamic in the On any of these files field.

Step 6 Click Save.

For the Email_clients_dynamic dynamic application class, the Email Client Example rule module, and the network access control and file access control rules to take affect, you would need to join the Email Clients Example rule module to a policy, join the policy to a group, and generate rules.

After doing those things, this rule will prevent any email application that falls into the selected Email_clients_dynamic class from reading or writing any dangerous, quarantined files.

Create New Application Classes from Rule Pages

You can create a new application class from a rule page and have that application class be available to the rule you're currently configuring and to all other rules as well.

From the rule page, click the New link beside the Application class selection field to access configuration window. Configure your new application class and click Save. It is now available for selection in the rule page.

Also available for Application classes from the rule page, is the ability to view the configuration parameters for a selected application class. Double-click an application class in the rule page to view its configuration page.

Application Class Management

The Application Class Management page allows you to pare down the application class selection fields in the rule pages and in the Analysis feature pages. If you have a long list of application classes and you only want to view specific classes in rule configuration pages or only view them in the rule pages or only view them for analysis, you can choose to have application classes appear or not appear in features you select.

Note that selecting certain application classes to not appear in certain products does not delete those application classes. They will still appear in the main Application Class list page. They simply will not appear in the application class selection fields in the product in question. By default, all application classes appear in all application class fields in all feature sets.

To enable or disable an application class for general configuration or for analysis purposes, do the following:

Step 1 Log in to the CSA MC as a user with configure privileges and switch to Advanced Mode.

Step 2 In the CSA MC menu bar, mouseover Configuration and navigate Applications > Application Class Management.

Step 3 Use the "Show [All, UNIX, Windows] application classes that apply to [<All features>, Management Center for Cisco Security Agents, Application Behavior Investigation, Application Deployment Investigation]" area to narrow the application class categories to specific features. Selecting <All features> will display three sets of swap boxes, one for each feature.

Step 4 In the Application Class Management page, there are vertical swap box fields for CSA MC and for Application Behavior Investigation and Application Deployment Investigation.

The application classes appearing in the white swap box(es) (the bottom swapbox for each category) are enabled for the feature in question. Those appearing in the gray swap box(es) (the top swapbox for each category) will not appear in the feature in question.

Select an application class and click the up arrow or down arrow buttons to move the selected class to the other swap box. This action enables or disables the application class for the feature in question. (It does not delete the application class.)

Figure 9-4 Application Class Management Window

	Using Management Center for Cisco Security Agents 6.0.1
	Using Application Classes
Using Management Center for Cisco Security Agents 6.0.1 Title Page Preface Overview Management Center for Cisco Security Agents Administration Configuring Groups and Managing Hosts Building Policies Rule Module Configuration Available Rule Types Using Global Settings Configuring Variables and State Conditions Using Application Classes Event Logging and Alerts Generating Reports Using Management Center for Cisco Security Agents Utilities Using Cisco Security Agent Analysis Automatic Signature Generation AntiVirus Protection Data Loss Prevention Cisco Partner and Third Party Product Integration Using the Scripting Interface (CSAAPI) Cisco Security Agent Overview System Components Open Source License Acknowledgements and Third Party Copyrights	Download this chapter Using Application Classes Download the complete book Using Management Center for Cisco Security Agents 6.0.1 (PDF - 9 MB) Table Of Contents Using Application Classes Overview About Application Classes Types of Application Classes Processes Created by Application Classes Membership in Application Classes is Ephemeral Managing Application Classes from the List Page Shell Scripts and Application Classes Built-in Application Classes Built-in Configurable Application Classes Configuring Static Application Classes Dynamic Application Classes Building Classes as Rule Consequences Removing Processes from Classes Effective Dynamic Application Classes Configuring Dynamic Application Classes Configure Application-Builder Rules Configure a Rule Using a Dynamic Application Class Create New Application Classes from Rule Pages Application Class Management Using Application Classes Overview This chapter explains the application classes shipped with CSA MC and provides instructions for creating new static and dynamically defined application classes. This section contains the following topics: •About Application Classes –Processes Created by Application Classes –Membership in Application Classes is Ephemeral –Shell Scripts and Application Classes •Built-in Application Classes –Built-in Configurable Application Classes •Configuring Static Application Classes •Dynamic Application Classes –Effective Dynamic Application Classes –Configuring Dynamic Application Classes –Configure Application-Builder Rules –Configure a Rule Using a Dynamic Application Class •Create New Application Classes from Rule Pages •Application Class Management About Application Classes Application classes are groups of similar application files that are identified with a unique name. For example, the Web Browser Applications application class, that is shipped with this release, contains commonly used web browser applications such as Internet Explorer, Firefox, and Safari. Consider the applications your enterprise uses and the manner in which you want to limit those applications' abilities to perform undesired actions. Then, create an application class for groups of similar applications. Access control rules specify which applications, or application classes, can access resources, such as directories, files, network addresses, registry keys, or COM components. By specifying an application class in an access control rule, the freedoms and restrictions of the rule are applied uniformly to all applications included in the application class. Types of Application Classes Built-in Application classes are shipped with this release of CSA MC. You can view them at the bottom of the Application class list page. Built-in application classes in brackets like, <Network Applications> cannot be edited. Built-in application classes in brackets with an asterisk, such as <Installation Applications> are dynamically defined by rules. See Built-in Application Classes and Built-in Configurable Application Classes for more information. Static application classes identify a group of designated applications. The list of applications in the class can be modified but it cannot be redefined "on the fly." See Configuring Static Application Classes for more information. Dynamic Application Classes are populated when a rule is triggered. For example, Active Internet Application is an application class included with this release. It is defined by a rule which acts in this way: If any application, acting as a client, and requesting TCP or UDP services, attempts to reach an external IP address, then add that application to the Active Internet Application class. See Dynamic Application Classes for more information. Processes Created by Application Classes When applications are invoked, they often spawn other processes as part of the action they are performing. Therefore, when you create an application class, CSA MC gives you the option of including or excluding processes created by the original applications you define as part of the application class. Membership in Application Classes is Ephemeral Processes are part of a configured application class when they are running on the system. When the process stops running, the CSA MC application classification for that process also ends. Should the process begin again, it may or may not fall into the same application class depending on the process's behavior and on the definition of the application class. Therefore, all application classifications are ephemeral and are constantly being re-evaluated and classified on the system. The application class configuration page lets you control how long a process maintains a certain application classification. In general, you do not have to specify a time frame. You should only put a time limit on an application classification if you are configuring rules that require it for a particular reason. For example, you may want to create special process start rules for an application. The classification of the process could be configured to time out once the system is finished booting. Managing Application Classes from the List Page From the Application Class list page, you can create new application classes, view existing application classes, delete, clone and compare application classes. See Creating, Saving, and Deleting Data, page 2-23 for more information. Shell Scripts and Application Classes On UNIX systems, the agent allows control over shell scripts which satisfy both of the following conditions: •the script begins with an interpreter string (e.g., #!/bin/bash) •the script is executed directly on a command line, e.g., "$foo.sh". Therefore, if you have an application class "foo.sh", a process satisfying the above conditions becomes a member of that application class. Note that a shell may be launched by various methods which do not meet those conditions, e.g., `"$ . foo.sh"`, or `"$ cat foo.sh \| /bin/sh"`. Note also that if you happen to have an application class for a script's interpreter -- say, `/bin/bash --` when you invoke the script, the process becomes a member of the `/bin/bash` application class. If a user has write access to the disk, and can execute commands, then using the name of a shell script in a rule to DENY actions may not make sense. For example, denying access by foo.sh to modify `/etc/hosts` does not improve the protection of `/etc/hosts` as the user could just run `'vi /etc/hosts'`. It would make more sense to deny everything access to a file, and then permit known good scripts access to that file. Note* In general, with scripts such as perl scripts, the agent's ability to place the script in a configured application class depends upon whether the interpreter executes the script (via exec) or simply reads it. In the first case, the agent does recognize the script. In the latter case, it cannot. Caution If the user can copy a script (or re-implement it) to a file of their choice, then any Deny rules would be avoided. Note On Windows, when writing rules for script application classes, you can create the rule for either the script itself or for the interpreter. (Scripts are handled by script interpreters.) If you write the rule for the interpreter, it will include the script handled by that interpreter. Built-in Application Classes CSA MC ships with several built-in application classes. Those application classes appear inside brackets, such as <First Time Application Execute> (see Figure 9-1). Some built-in class are also marked with asterisks, such as <Installation Applications>. An asterisk indicates that the built-in application class is configurable. See Built-in Configurable Application Classes. You can view all application classes in the Application Class list page. To access this page, mouseover Configuration* in the menu bar and navigate Applications > Application Classes. Figure 9-1 Built-in Application Classes Some included application classes are: •First Time Application Execute—This includes the first invocation of any application which has never been observed to execute on the system. •Network Applications—A network application would include any process that connects as a client or accepts a connection as a server and has in some manner accessed the network. The process would fall into this network application class after it has accessed the network. (This does not include applications that communicate only with other applications on the same system.) •Processes created by Network Applications—This includes any process that is launched by a network application. For example, one network process may create another process that attempts to download code. This is one way viruses are propagated. •Processes created by Servers (TCP and UDP)—This includes any TCP or UDP process invoked by a server (falling into the categories detailed in the two following bullet points). •Server (TCP based)—This application class includes all processes that have accepted an inter-box connection on a non-ephemeral port. •Server (UDP based)—This application class includes all processes that have accepted an inter-box connection on a non-ephemeral port. •Processes Monitoring the Keyboard—This includes all processes which continuously monitor keystrokes over an extended period of time. •Processes with elevated privileges—This application class is only available for UNIX rule types. It includes processes that have elevated user privileges for users other than root, such as ping. Using such processes is a common way to attempt a system break-in. Note that this elevated privilege designation does not apply to processes when the user is logged in as root. •Processes performing a Print Screen—This includes all processes that access the print screen function. This class is available in the Clipboard access control rule to provide further protections to clipboard data by including print screen captured data. •Recently created untrusted content—This includes executables that are newly created by <Processes writing untrusted content> and are immediately invoked. •Remote clients—When a remote machine accesses resources over the network that are protected locally by an agent, the agent sees the remote access attempt as coming from a "remote application." The actual application that is used to open the resource in question cannot be determined on the local system. All remote access attempts are seen by the local system as being invoked by a remote application. Therefore, if you are writing rules for a machine that other machines can access over the network, you must include <All Applications> or <Remote clients> as your application class. Otherwise, the rule will not work as expected in regard to remote access to those resources. •System Process (available only in Network Access Control rules)—Using this application class, you can control network access for the operating system itself (as opposed to applications running on the operating system). Caution Any application class that you define does not include the system process. If you want to include the system process in a rule, you must select the included, built-in <All applications> or <System process> classes. Built-in Configurable Application Classes The Management Center for Cisco Security Agents also ships with built-in application classes that are built by policy rules. These application classes appear inside brackets with asterisks before them () in the rule application class selection list boxes (see Figure 9-1). This means that you should only use them in conjunction with a rule module that dictates the parameters that causes processes to become classified as one of these application types. CSA MC ships with pre-configured policies to define these classes. You can change these policies, if necessary. •Installation Applications—This includes processes installing software. •Processes Executing Untrusted Content—This includes any downloaded executable or any process that is interpreting downloaded content. •Processing requiring Kernel Only Protection—This is intended to remediate interoperability issues with CSA's user component and other third party software products. Processes in this class will not enforce COM component checks and some buffer overflow checks. •Processes requiring OS Stack Execution Protection—This application class is only available for UNIX rule types. This is intended to enable native Solaris operating system stack execution protection emulation. This enables additional buffer overflow protection. •Suspected Virus Applications:—This application class includes processes dynamically defined as being suspect by specified, exhibited behavior. Being classified as belonging to this application causes a quarantine message to be sent to CSA MC. •Third Party Security Applications:—This application class is used to mark other security products which may attempt to control similar resources as CSA. This application class provides certain built-in permissions to facilitate interoperability and system stability. Configuring Static Application Classes See About Application Classes for information on Static Application Classes and how they compare to Dynamic Application Classes and Built-In Application Classes. See also Built-in Application Classes and Effective Dynamic Application Classes. To create an application class, do the following: Step 1* Log in to the CSA MC as a user with configure privileges and switch to Advanced Mode. Step 2 From the CSA MC menu bar, mouseover Configuration and navigate Applications > Application Classes. Step 3 Click the New button to create a new application class. Step 4 If you have not set an operating system admin preference, select whether this is a Windows or a UNIX rule module from the pop-up box that appears. Note UNIX generically refers to both Solaris and Linux operating systems. This takes you to the application class configuration view (see Figure 9-2). Step 5 Enter a Name and a Description for the new application class. The description appears in the application class list view. Optionally, expand the +Detailed field to enter a longer description. Step 6 In the OS list box, select a particular Windows or UNIX operating system for which this application class is intended. To specify all UNIX-type operating systems, select <UNIX>. To specify all Windows-type operating systems, select <Windows>. Step 7 Under Add process to application class, for a static application class, do the following: Leave the default when created from one of the following executables radio button selected. Then enter the executable file names (one per line) for the applications you are grouping together in this application class. See Directory and Filename Syntax Requirements, page 2-30 for more information about entering literal file names in the field. Note You can enter preconfigured File Set variables in the executables edit field by clicking the Insert File Set link. To learn more about File Sets, see File Sets, page 8-9. Step 8 Remove process from application class—Select the checkbox beside After and enter a time frame in seconds to configure an application classification which expires after a period of time. Only use this feature if you have a rule that requires it. In general, you do not have to specify a time-out for application classifications. See Membership in Application Classes is Ephemeral for details. For UNIX application classes, you have the additional option of selecting the When session association is voided checkbox. Selecting this checkbox causes the application classification to be removed when a process disassociates itself from the current TTY session. For example, when an application class exists for applications descended from "superuser", you might not want the process to continue having the application class of the superuser shell. Step 9 This application class includes: When applications are invoked, they often spawn other processes as part of the action they are performing. When you create an application class, select one of the following radio buttons to determine when processes spawned by the applications in the application class are also included. •Only this process •This process and all its descendents •Only descendents of this process Note Creating an application class for "Only descendents of this process" is useful when making exceptions to a rule that is written for the main process itself. For example, you can write a rule allowing IIS to talk on the network, but create another rule denying descendents of the IIS process from talking on the network. Step 10 When you are finished, click the Save button. The new application class name now appears in the application list view and in the application selection fields for rule configurations. Tip There is a red Tasks menu in the upper right corner of the page. Clicking the down arrow, expands the menu. This menu provides quick links to common tasks that are relevant to this application class. Figure 9-2 Static Application Class Dynamic Application Classes Dynamic application classes are made up of applications or processes that have exhibited a behavior defined by a rule. In contrast, static application classes are made up of a list of executable file names or process names. There are built-in dynamically defined application classes in this release of CSA MC. For example, the <Processes Executing Downloaded Content> application class is a "built-in" dynamically defined class. By viewing the references for this built-in dynamic application class, and other built-in dynamic application class, you can see which rules add applications and processes to the application class. See About Application Classes for more information on static, dynamic and built-in application classes. One example of an instance in which you might use a dynamic application class would be if you are writing rules for email clients but you do not know all the different email applications that are being used throughout your corporate network. In this case, you could use a dynamic application class. Any process appearing to act as a client for SMTP (you can use whatever criteria you decide to define what an email application is) would fall into a dynamic email application class that could be used in rules quarantining dangerous email messages. Note* A dynamically defined application class can be used in any rule where a static application class can be used. Building Classes as Rule Consequences You can also build a dynamic application class as a consequence of rules triggering. This way, for example, you can configure a query user rule in which a process is added to an application class as a result of a specific user response (yes, no, terminate). For example, you can build a "suspected virus" application class based on the end user being queried when untrusted content arrives on the desktop and the Terminate button on a query box is clicked to disallow it. But if the user clicked Yes to allow it, the process would not be added to the suspected virus application class. Removing Processes from Classes You can also use a dynamic "remove process" capability in conjunction with dynamically adding a process. For example, you can dynamically add a process to a "suspicious web server descendents" class if a web server spawns a process. Then, if that spawned process attempts to read a script from a normally accessed directory, you can decide this isn't a dangerous process and have the process removed from the class after the attempt. But if the spawned process attempts to read a script from a directory it should not be accessing, the process should remain in the suspicious web server descendents class. Effective Dynamic Application Classes Effective dynamic application classes work together with application builder rules and enforcement rules. To use a dynamic application class effectively, you need to configure the following objects: Step 1 Create the new dynamic application class by following the Configuring Dynamic Application Classes. A dynamic application class is populated by processes defined in an application-builder rule. Step 2 Configure an application-builder rule to identify the processes to add to the dynamic application class. See Configure Application-Builder Rules for more information. Step 3 Configure other rules to control the actions of all the applications added to the dynamic application class. See Configure a Rule Using a Dynamic Application Class. Configuring Dynamic Application Classes This procedure describes how to create a dynamic application class. For a dynamic class to be effective, administrators also need to Configure Application-Builder Rules and Configure a Rule Using a Dynamic Application Class. This procedure is the first of three that describe how to create an effective dynamic application class. To better illustrate how the dynamic application class and rules interact, these three procedures are written with a common example in mind and, where noted, make specific choices to achieve the goal of the example. Example: You want to write rules quarantining dangerous email messages but you do not know all the different email applications that are being used throughout your corporate network. To create a dynamic application class, do the following: Step 1 Log in to the CSA MC as an administrator with configure privileges and switch to Advanced Mode. Step 2 From the CSA MC menu bar, mouseover Configuration and navigate Applications > Application Classes. Step 3 Click the New button to create a new application class. Step 4 If you have not set an operating system admin preference, choose whether this is a Windows or a UNIX rule module from the pop-up box that appears. Note: UNIX generically refers to both Solaris and Linux operating systems. Step 5 Enter a Name and a Description for the new application class. The description appears in the application class list view. Optionally, expand the +Detailed field to enter a longer description. For our email client example, name the dynamic application class Email_clients_dynamic. Step 6 In the OS list box, select a particular Windows or UNIX operating system for which this application class is intended. To specify all UNIX-type operating systems, select <UNIX>. To specify all Windows-type operating systems, select <Windows>. Step 7 In the Add process to application class area, for a dynamic application class, select the when dynamically defined by policy rules radio button.(Do not enter any process names in the edit field.) Step 8 Remove process from application class: Select the checkbox beside After and enter a time frame in seconds to configure an application classification which expires after a period of time. Only use this feature if you have a rule that requires it. In general, you do not have to specify a time-out for application classifications. See Membership in Application Classes is Ephemeral for details. For UNIX application classes, you have the additional option of selecting the When session association is voided checkbox. Selecting this checkbox causes the application classification to be removed when a process disassociates itself from the current TTY session. For example, when an application class exists for applications descended from "superuser", you might not want the process to continue having the application class of the superuser shell. Step 9 When applications are invoked, they often spawn other processes as part of the action they are performing. When you create a dynamic application class, you can select one of the following radio buttons (just as you can when you create a static application class) to determine when processes spawned by the applications in the dynamic application class are also included. For the email client example, we will leave the default, Only this process, selected. •Only this process •This process and all its descendents •Only descendents of this process Step 10 When you are finished, click the Save button. This dynamic application class name now appears in the pulldown list beside the Add to application class radio button in access control rules and in all application selection fields. Next we will use this dynamic application class in an application-builder rule. Continue with Configure Application-Builder Rules. Figure 9-3 Dynamic Application Class Configure Application-Builder Rules This procedure describes how to create an application builder rule. This is the second of three procedures that describe how to create effective dynamic application classes. This procedure will be more meaningful if you have already completed Configuring Dynamic Application Classes. After this procedure, go to the Configure a Rule Using a Dynamic Application Class. To better illustrate how the dynamic application class and rules interact, these three procedures are written with a common example in mind and, where noted, make specific choices to achieve the goal of the example. Example: You want to write rules quarantining dangerous email messages but you do not know all the different email applications that are being used throughout your corporate network. In this procedure, we are going to use a Network access control rule to define our dynamic application class. You can use any access control rule type as your application-builder rule. (Remember, your dynamic application class is not populated with applications until an application-builder rule is triggered by the process's behavior and added to the class.) This rule type takes precedence over all others in the policy. This rule type does not override other rules in the policy the way allow, deny, and query rules do when triggered. Note Defining dynamic application classes from the Application control rule is a bit different than creating them from other rule types. Because this rule has two application class fields, you can choose to add the current application to the dynamic class or choose to add the new application that is invoked by the first application to the dynamic class. Caution Dynamic application class process membership is temporary and is based on a running process meeting the criteria in the application-builder rule. When the process is no longer running on a system, it is no longer included in the dynamic class. To prevent errors or unexpected behavior, you should avoid selecting the dynamic application class for a rule within a policy that does not also include the corresponding application-builder rule. Both the application-builder rule and the subsequent rule(s) that use the dynamic application class should co-exist within the same policy—although this is not required. Step 1 Log on to the CSA MC as an administrator with configure privileges and switch to Advanced Mode. Step 2 Rules can only be added to existing rule modules. For our email client example, create a rule module called Email Client Example using Configuring Rule Modules, page 5-2. Step 3 Open the Email Client Example rule module you just created. Step 4 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up. Step 5 Select Network Access Control rule from the list of rules. This takes you to the configuration view for this rule type. Step 6 Follow the procedure for creating a Network Access Control rule on page 6-20. For our email client example, make the following configuration choices: •Enter a description •In the Take the Following Action listbox, select Add process to application class from the pulldown list as the rule action. Select the dynamic application class, Email_clients_dynamic, from the corresponding pulldown list. This rule type takes precedence over all other types. The only action of this rule is to build the application class for any subsequent rules within the policy that make use of it. •In the When - An enforcement action of the following type occurs field, leave the default, <All Applications>, selected in the Application class field. This way, all applications that trigger the rule have the potential of being added to the dynamic class. You could select a specific application class here if you only want members of that application class to fall into the dynamic class. •Select client from the pulldown list and select the pre-configured variable, $Email, from the list of configured Network services. •In the Communicating with host address field, leave the default <all>. •In the Use these local interfaces field, leave the default <all>. •Specify all the enforcement actions: Allow by default, Terminate, Deny, Allow. This means that the tag will apply when the request is made regardless of the action that occurs. All actions apply. If you make a specific selection here, you are determining to create your dynamic application class based on that action occurring when the request is made (perhaps via another configured rule). You should note that all resource requests always result in either an allow, deny, or terminate occurring. Even if there is no rule governing the resource, for example, the implicit action is allow. Step 7 Click Save. Now, based on the application-builder rule we've just configured, any application which uses the network services, SMTP, POP3, IMAP3 or IMAP2 as a client to access any system on the network, will fall into the Email_clients_dynamic application class. Next we will use this dynamic application class in a rule that will control its actions. Continue with Configure a Rule Using a Dynamic Application Class. Configure a Rule Using a Dynamic Application Class This procedure describes how to define a rule that uses a dynamic application class. This is the third of three procedures that describe how to create effective dynamic application classes. This procedure will be more meaningful if you have already completed Configuring Dynamic Application Classes and Configure Application-Builder Rules. To better illustrate how the dynamic application class and rules interact, these three procedures are written with a common example in mind and, where noted, make specific choices to achieve the goal of the example. Example: You want to write rules quarantining dangerous email messages but you do not know all the different email applications that are being used throughout your corporate network. In this example, we are going to use a File Access Control Rule to control the actions of a dynamic application class. Step 1 Log on to the CSA MC as an administrator with configure privileges and switch to Advanced Mode. Step 2 Open the Email Client Example rule module that you created in the Configure Application-Builder Rules procedure. Step 3 To add rules to your module, expand the rules area of the rule module and click the Add button. A menu of available rule types pops-up. Step 4 Select File Access Control from the list of rules. This takes you to the configuration view for this rule type. Step 5 Follow the procedure for creating a File Access Control rule on page 6-16. For our email client example, make the following configuration choices: •Enter a description •From the Take the Following Action list box, select the Deny action. •In the Applications in any of the following applications classes list box, select the dynamic application class you created in Configuring Dynamic Application Classes, Email_clients_dynamic. •Select the read file and write file checkboxes in the Attempt the following operations area. •Enter @dynamic in the On any of these files field. Step 6 Click Save. For the Email_clients_dynamic dynamic application class, the Email Client Example rule module, and the network access control and file access control rules to take affect, you would need to join the Email Clients Example rule module to a policy, join the policy to a group, and generate rules. After doing those things, this rule will prevent any email application that falls into the selected Email_clients_dynamic class from reading or writing any dangerous, quarantined files. Create New Application Classes from Rule Pages You can create a new application class from a rule page and have that application class be available to the rule you're currently configuring and to all other rules as well. From the rule page, click the New link beside the Application class selection field to access configuration window. Configure your new application class and click Save. It is now available for selection in the rule page. Also available for Application classes from the rule page, is the ability to view the configuration parameters for a selected application class. Double-click an application class in the rule page to view its configuration page. Application Class Management The Application Class Management page allows you to pare down the application class selection fields in the rule pages and in the Analysis feature pages. If you have a long list of application classes and you only want to view specific classes in rule configuration pages or only view them in the rule pages or only view them for analysis, you can choose to have application classes appear or not appear in features you select. Note that selecting certain application classes to not appear in certain products does not delete those application classes. They will still appear in the main Application Class list page. They simply will not appear in the application class selection fields in the product in question. By default, all application classes appear in all application class fields in all feature sets. To enable or disable an application class for general configuration or for analysis purposes, do the following: Step 1 Log in to the CSA MC as a user with configure privileges and switch to Advanced Mode. Step 2 In the CSA MC menu bar, mouseover Configuration and navigate Applications > Application Class Management. Step 3 Use the "Show [All, UNIX, Windows] application classes that apply to [<All features>, Management Center for Cisco Security Agents, Application Behavior Investigation, Application Deployment Investigation]" area to narrow the application class categories to specific features. Selecting <All features> will display three sets of swap boxes, one for each feature. Step 4 In the Application Class Management page, there are vertical swap box fields for CSA MC and for Application Behavior Investigation and Application Deployment Investigation. The application classes appearing in the white swap box(es) (the bottom swapbox for each category) are enabled for the feature in question. Those appearing in the gray swap box(es) (the top swapbox for each category) will not appear in the feature in question. Select an application class and click the up arrow or down arrow buttons to move the selected class to the other swap box. This action enables or disables the application class for the feature in question. (It does not delete the application class.) Figure 9-4 Application Class Management Window
	Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks