-
Using Management Center for Cisco Security Agents 5.1
-
Title
-
Preface
-
Overview
-
Management Center for Cisco Security Agents Administration
-
Configuring Groups and Managing Hosts
-
Building Policies
-
Rule Module Configuration
-
Available Rule Types
-
Using Event Correlation
-
Using Application Classes
-
Configuring Variables
-
Event Logging and Alerts
-
Generating Reports
-
Using Mangement Center for Cisco Security Agents Utilities
-
Using Cisco Security Agent Analysis
-
Third Party Product Integration
-
Cisco Security Agent Overview
-
System Components
-
Open Source License Acknowledgements and Third Party Copyright Notices
-
Table Of Contents
Additional Notes on Learn Mode
Merging or Copying Rule Modules
Attaching Rule Modules to Policies
Common Rule Page Configuration Items
Rules: Action Options and Precedence
Rules: Manipulating Precedence
Attribute: Differentiated Service (Trusted QoS)
Query Rule Priority Information
Rule Module Configuration
Overview
Rule modules consist of one or more rules. One or more rule modules are meant to be attached to a policy. This module of rules is generally configured for a particular "modular" purpose. It is in this manner that several rules can be moved together from one policy to another or exist as part of several policies.
Rule module are generally OS specific while policies are not. This way, you can scale a great many rule modules to a lesser number of policies to simplify your basic product configuration view. For example, you could have one policy for all Apache servers, but that policy would consist of several OS specific rule modules containing hundreds of rules. As an administrator, you may only be interested in your Apache policy which you can attach to a general servers groups and deploy in this manner.
This section contains the following topics.
•
Adding Rules to a Rule Module
•
•
•
•
•
About Rule Modules and Rules
Rules are the foundation of your security policies. CSA MC lets you create several rule types. Each rule type requires you to enter varying combinations of information using a specific syntax. Most Policies and Rule Modules use a combination of Enforce and Detect rules. Enforce rules are primarily access control rules that allow, deny, or terminate a process. Detect rules are monitoring, and tagging rules. In rule display lists, enforce rules are shown at the top of the list and detect rules are shown at the bottom. These rule types work together to monitor actions, build application classes, and protect systems.
For example, the following basic enforcement rules require information as follows:
Use file access control rules to allow or deny what operations(read, write) selected applications can perform on files and directories according to:
•
•
•
Use network access control rules to control access to specified network services according to:
•
•
•
•
•
Use registry access control rules (Windows only) to allow or deny selected applications from writing to specified registry keys according to:
•
•
•
Use COM component access control rules (Windows only) to allow or deny selected applications from accessing specified COM components according to:
•
•
Other types of enforcement rules shipped with CSA MC provide event correlation and heuristic features which can be enabled on a per group basis, like portscan detection, SYN flood protection, the prevention of predictable TCP sequence numbers, and the blocking of malformed IP packets. (These features are located on the Network shield rule page.) This is especially useful for network servers. (See Chapter 7, "Using Event Correlation" for more information.)
The following basic detection rules work as follows:
Use various tagging rule types with "Add process to application class" or "Remove process from application class" selected to build application classes based on process behavior rather than executable name. Once applications are built or "tagged" they are used in other enforcement rules.
Use rules such as NT Event log and Sniffer and protocol detection to log designated event types when they occur.
By tying together the controlling and monitoring of various system functions and by operating under the direction of assigned policy rules, agents provide overall system protection,
Rule Module Components
The following sections describe the various components you must configure as part of the rules modules that will form your policies.
Configuring Rule Modules
Rule modules are the building blocks for your policies. Modules are made of several different types of rules. See Chapter 6, "Available Rule Types" for information on rule types.
Note
Caution
To configure a rule module, do the following.
Step 1
Step 2
Tip
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Refer to the following sections for details on adding, copying, and configuring rules.
Step 10
Figure 5-1 New Rule Module
Using Test Mode
Test Mode is useful when you are installing a new host or are modifying a host configuration and want to understand the ramifications without actually impacting host operation. When operating in test mode, the agent will not deny any action or operation even if an associated policy says it should be denied. Instead, the agent will allow the action but log an event if a deny or query rule is triggered (if logging is enabled for the rule) and log an event when an allow rule with logging enabled is triggered. This helps you to understand the impact of deploying a policy on a host before enforcing it. If examining the logs shows you that the policy is working as intended on a group, you can then remove the Test Mode designation.
When using Group test mode (available from the Rule Overrides category), you may also want to enable Verbose logging mode. This way, the agent will not suppress any log messages as it normally does when several of the same log messages are received.
When an agent running in test mode sends events to CSA MC, event log messages are preceded with the words "Test mode". There are some exceptions to this. For example, event log messages related to detected events such as port scans and malformed packets are not preceded by the words "Test mode." Event detection (not prevention) messages appear the same in the event log regardless if test mode is on or off.
Group Test Mode
You can turn on test mode in two places within the MC. If it is enabled on the group level (see Figure 5-2), all rules on hosts within test mode groups are in test mode.
If a host belongs to a group with test mode selected, all policies associated with that host are in test mode (even if the host is part of another group that does not have test mode selected), not just the policies applied to the test group. Therefore, test mode applies to the host as a whole, not to specific policies.
Note
Figure 5-2 Group Test Mode
Rule Module Test Mode
You can also use test mode on the rule module level (see Figure 5-3). This way, you can have the rules within the test mode module operating in test mode while rules from other modules assigned to the same host are operating in a live mode. This is useful for testing new rule modules or changes to existing modules without having to turn off all protections for the hosts in question.
Caution
Figure 5-3 Rule Module Test Mode
Using Learn Mode
Learn mode is intended to localize policies on individual systems, eliminating the initial flurry of pop-up queries that users may experience when the agent is first installed on a system. This flurry of queries is a result of query rules that are deployed to let end users decide when an unknown system action is normal or abnormal. When the agent is first deployed, these pop-up queries can be numerous since the agent is seeing system actions for the first time. Unfortunately, this initial bombardment of queries for actions that are likely benign (in most cases) can train the user to respond Yes to the majority of queries they see.
To solve this problem without removing useful query rules from your deployment, you can enable Learn mode for a temporary period of time. Learn mode directs the agent not to display query pop-ups, and to instead take an immediate Allow query response when a query rule is triggered, and to persistently save the allow response.
If you intend to use Learn mode, the queries that qualify for learning must have certain options enabled. While Learn mode is enabled from either the Group page or the Rule module page, queries are defined from the Configuration>Variables>Query Settings menu. There are several pre-configured queries listed on the Query Settings page. In order for Learn mode to work, you must do the following:
•
Like Test mode, Learn mode can be enabled for all persistent queries in all policies running on hosts (Group Learn mode) or enabled for specific persistent queries located in a particular Rule module (Rule module Learn mode).
•
–
–
Once query responses are taken, and Learn mode is turned off, the majority of queries no longer appear and system security provided by the agent is normalized to the individual system. At this point, users should only see query pop-ups for unusual or suspicious system behavior.
Additional Notes on Learn Mode
•
•
•
•
•
•
Note
Setting State Conditions
System State and User State conditions let you write conditional rules based on the state of a system or the user of the system. Therefore, rules are only applied if the configured conditional settings are met.
System State Sets
System state parameters let you dictate conditions based on detected machine settings. When a machine is operating an agent with a configured system state, the rules associated with that state apply only when the state parameters are met. They are conditional rules. For example, if you apply a system state to a rule module, you can dynamically "activate" and "deactivate" rules modules based on the changing state of a system. For example, you can apply special boot time rules that apply only at boot time. After booting is complete, normal operation rule modules are applied. Also, for example, you can apply a looser set of rules if an installation is occurring on a system. Once the installation is complete, a more stringent, normal operating set of rule modules are applied.
Note
For a more detailed description of system state setting options, read the configuration instructions here.
Configure a System State Set by doing the following:
Step 1
Step 2
Step 3
Step 4
Step 5
Note
The Cisco Trust Agent checks the status of a system and reports this status back to the Cisco Secure Access Control Server (ACS). Based on this status check, ACS returns a "posture state" that the Cisco Security Agent can act upon.
For example, if a machine is running anti-virus software that is not up-to-date or is disabled, the Cisco Trust Agent can report this status to ACS which can then return an "Unknown" or a "Quarantine" state. The Cisco Security Agent will then take action based on that posture state and enforce a stricter policy to protect that system or even quarantine the system from the network. Refer to your ACS documentation for information on posture states and what they mean. Possible posture states are:
•
•
•
•
•
•
•
•
Step 6
Step 7
Step 8
Step 9
•
This state condition could be met if you are using a "Set-detected boot-as insecure" Kernel Protection rule. When this "Set" rule type triggers, the system state consequently takes effect. See Using the Set Action for more information on this setting.
Note that this is a persistent state. This state condition, once set, can only be removed by using the Reset feature. See Resetting Cisco Security Agents, page 3-8. (Most states are not persistent in this way. Most states can be switched in and out using rule triggers. A persistent states can only be switched "on" using rules and must be switched "off" manually.)
•
•
•
•
•
Note that this is a persistent state. This state condition, once set, can only be removed by using the Reset feature. See Resetting Cisco Security Agents, page 3-8. (Most states are not persistent in this way. Most states can be switched in and out using rule triggers. A persistent states can only be switched "on" using rules and must be switched "off" manually.)
•
Step 10
Note
Caution
Figure 5-4 System State Conditions
User State Sets
User state parameters let you dictate conditions based on detected user and/or group settings. When a machine is operating an agent with a configured user state, the rules associated with that state apply only when the state parameters are met. They are conditional rules. Keep this in mind when assigning a user set to a rule module.
You should also keep in mind that the process of checking user states is an expensive one for the system. You should use these settings judiciously.
An example of when you might want to employ a user state is as a restriction dictating who can alter web server pages. The web server application itself should only serve pages, not edit them. You could use a setting here to ensure that only authenticated administrators using a specific application (e.g. FrontPage) are allowed to alter web server content.
Another example of appropriate user state setting usage is a situation where groups of users are restricted from performing certain tasks that you only want to allow administrators to perform, such as suspending agent security.
Configure a User State Set by doing the following:
Step 1
Step 2
Step 3
Step 4
Step 5
•
Domain_Accounting\AdministratorThis represents the administrator in the Windows domain "Domain_Accounting."•
W2K-jefe\AdministratorThis represents user "Administrator" defined locally on the computer "W2K-jefe."•
*\AdministratorThis represents any user administrator.•
Domain_Accounting\*This represents all users in the domain "Domain_Accounting".You can use wildcards in the Users matching/but not fields.
Step 6
Step 7
•
NT AUTHORITY\SYSTEM•
Domain_Accounting\AdministratorsFor Windows, you can also enter SID (Security Identifier) numerical classifications into the Group matching field. Using a SID rather than a group name is useful when writing states that will apply across international versions of operating systems. Group names may be different across languages, but a SID classification is always the same.
You cannot use wildcards in the Groups matching/but not fields. If users belong to multiple groups, they only need to match one named group to meet the criteria of the user state.
Note
Note
Step 8
Step 9
Note
Figure 5-5 User State Conditions
Adding Rules to a Rule Module
First, click the Modify rules link at the top of the Rule Module page to go to the Rules page. See Figure 5-6.
To add rules to this policy, click the Add rule link in the Rules page. A menu list of the available rule types appears. Click on one to select it. This takes you to the configuration view for this rule type. Note that this rule contains no parameters until you create them.
Figure 5-6 Rule Module, Modify Rules
Note
Use the Enable and Disable buttons in the rule module configuration view to enable or disable rules within a module without having to navigate to the configuration view for that particular rule. Select the checkbox for the rule you want to enable or disable and click the corresponding button. See Figure 5-7.
The ID column in the Rules section is the rule ID number assigned to the particular rule in question. This number increments each time a new rule is created. It is only used as an identifier for the rule. This ID is referenced in Event Log messages and can help you refer back to a particular rule.
The Events column in the Rules section (see Figure 5-8) displays the number of events generated by the rule in the last 24 hours. Clicking this number link takes you to a list of the events themselves.
Figure 5-7 Rules List
Filtering the Rules Display
The Groups configuration page, Policy configuration page, and the Rules configuration page each display a table listing either the rules attached to the group or the rules included in the module (see Figure 5-8). On all of these pages, there is a View All rules item above the table. Clicking the All link here lets you filter your view of this rule list by selected rule type. When you click All, a pop-up appears listing the rule types present in the module or modules. Select a rule type from the pop-up, and that is now the only rule type displayed in the table. You can also select to view only enabled rules by selecting the show enabled rules only checkbox and then select the rule type you wish to view.
Note
This filtering feature is useful when lists of rules grow extensive and you want to pare down your view to specific rule types.
If you have user or system states applied to rule modules, you can also filter the display based on those settings. This is useful to view which rules are applied when particular states are active.
Copying Rules between Modules
Use the Copy button in conjunction with the pulldown lists at the bottom of the Rule Module page to copy selected rules to another rule module that you designate. Copying rules across modules works similar to the way cloning configurations works. (You can also clone rules within policies using the Copy button that will be described in this section.)
To copy selected rules from one module to another module, do the following:
Step 1
Step 2
Step 3
All checked rules are copied to the selected module.
To clone rules within a module, repeat step 1 above. Then, rather than selecting another module in the rule module pulldown list, select the current module you are in from that same pulldown. Selected rules are cloned within the same module when you click the Copy button.
Select from in the pulldown menu beside the Copy button to copy ALL the rules from the selected module (in the rule module pulldown list) to the current module.
Figure 5-8 Copy Rules between Modules
Comparing Configurations
When you select the checkbox next to 2 items (you cannot compare more than 2 configurations at a time) and click the Compare button, CSA MC displays the configurations side by side and highlights the differences in red (see Figure 5-9). Once you've examined how the configurations compare, you can select to merge specific rules, to copy rules to another module, or to copy rules to a new module. Additionally, you can attach and detach groups and policies. (You can compare application classes and variables, but you can only copy and merge rules from the compare page.)
The purpose of this compare tool is to assist you after you've imported configurations or upgraded CSA MC. These processes can cause you to have duplicate or very similar configuration items. Comparing and merging configurations can help you to more easily consolidate duplicate items. This Compare utility is also available for Groups, Policies, Application Classes, and Variables.
Feature notes:
•
•
•
Figure 5-9 Compare Rule Modules
Merging or Copying Rule Modules
Merge or copy rules by selecting the available checkbox above the rule or rules in question. When you click the Copy button in the bottom frame, a pop-up window appears. From this window, you select to do one of the following:
•
•
•
Figure 5-10 Copy Rule Module Pop-up Box
View Change History
At the top of each rule page, there is a View change history link. Click this link to go to a page which lists all the changes that have been made to this rule. This View change history link is also available for Application classes, Variables, Rule Modules, and Policies.
Explanation of Rules
CSA MC provides an explanation, in paragraph form, of the policy in question, describing each rule and its role in the policy. Clicking the Explain rules link in the Groups, Host, Rule Modules, or Policy page, takes you to this paragraph explanation. See Figure 5-11.
Figure 5-11 Rule Module Explanation Page
Consistency Check
The main rule module page provides an OS consistency check for variables that are part of the rule. For example, it makes sure that Linux applications classes are attached to a UNIX module that has Linux or All UNIX as its target OS. If the rule module has a target OS of Solaris, the consistency check will fail if the application class is marked as Linux.
This consistency check also ensures that modules of a specified OS type are attached to similar OS policies. You are allowed to save modules that do not pass the consistency check so that you can clone items or make multiple policy edits, but you are not allowed to attach and deploy inconsistent items.
Attaching Rule Modules to Policies
Note
When you configure a rule module, you are combining access control rules and/or tagging and monitoring rules under a common name. That rule module name is then attached to a policy. That policy uses the rules that comprise the module to control the actions that are allowed and denied on hosts. See Configuring Rule Modules.
CSA MC gives you the option of attaching a rule module to a policy using the Modify policy associations link in the Rule Module configuration page or attaching a policy to a rule module using the Modify rule module associations link in the Policy list view page.
To attach a rule module or rule modules to an existing policy using the Modify policy associations link in the rule module configuration page, do the following.
Step 1
Step 2
Step 3
Step 4
Note
Caution
Figure 5-12 Rule Module Associations
Generating Rule Programs
Caution
The Generate rule programs view displays the status of all non-distributed database items with the name of the administrator who made the configuration changes. A Details link appears beside each edited configuration item. Click this link to view what modifications were made to the configuration in question.
Once you've checked these modifications, you can either go back and change or delete configurations or you can click the Generate button (in the bottom frame) to distribute all updates.
Note
Figure 5-13 Generate Configuration
Common Rule Page Configuration Items
The following sections provide information on the common fields found on most rule type pages. These include the action options that determine rule precedence as well as a description of how query rules work. The unique rule types themselves are described in the next chapter.
Rules: Action Options and Precedence
When you configure certain rule types, you select an action for that rule (allow, deny, etc.). When you add your rule modules to policies, CSA MC orders individual rules from multiple modules according to action, in the following manner within each policy.
The priority listings beside each item indicate the manner in which CSA processes rules. All priority 1 enforcement rules (Priority Terminate Process) are checked first and priority 8 enforcement rules (Deny) are checked last and that is only if no other higher priority rules have already been triggered by a system action. Detection rules, such as Monitor rules, are always checked, even in the presence of a priority enforcement rule which governs the same resources triggering first.
Note
Rules: Action Definitions
When you configure your access control rules, you must select an action for that rule. The following is a description of all possible action types. You should note that not all action types are available for all rules.
Enforcement Actions
•
•
•
•
•
•
Text used to query user—If you are configuring a Query User rule, you must also configure query settings. The text you type into the query settings field is the same text that will appear in the Query User pop-up box to explain what is occurring on the system to the user.
•
•
Detection Actions
Note that Detection rules are always checked, even in the presence of a priority enforcement rule which governs the same resources triggering first.
Note
•
•
•
•
Note
For every rule module you configure, the default action of that rule is Allow. All rule modules allow all system actions until you write a rule denying a specific action. Following that logic, it is unlikely that you would write allow rules unless they are to make exceptions to deny rules you are writing within a module or for monitoring purposes (see The Monitor Action). If you do write a stand-alone allow rule, because the default action is allow, the allow rule itself is then essentially irrelevant.
A good model for configuring rules within modules would be to take the priority levels into account and work from the bottom up, lowest priority to highest priority. Before you even add a single parameter to a rule, by default, it allows all system actions. First, write a deny rule and then if you want to make any exceptions to that particular deny, write an allow rule. Next consider using query rules for access controls that allowing the user to decide if an action should be allowed or denied. Lastly write any high priority rules you might need.
Rules: Manipulating Precedence
In addition to using the selected "action" type to order rules within a policy, CSA MC uses the selected logging type as a way to suborder similar rules within a policy. Logging automatically takes precedence over disabled logging if the action type is the same for multiple rules in a policy. Therefore, for rules of a given priority, e.g. Allow, a Log rule will be evaluated before a No Log rule.
For most policies, this automatic ordering and subordering of rules provides the desired effect when policies are combined and deployed. However, there are cases when the CSA MC ordering scheme causes policies to behave in an undesired manner. For this reason, most rule types provide a checkbox that allows you to manipulate how similar rule types are subordered within a policy. This checkbox, called Take precedence over other <similar action> rules, is located in the rule configuration page. A rule with this precedence checkbox selected is evaluated before similar rules that do not have this checkbox selected.
Here is an example of two rules within the same policy which do not behave as expected due to automatic rule ordering. There are two Network access control rules in the same policy as follows:
•
for TCP/1-65000•
for TCP/1900The rule that involves connections on TCP/1900 would be denied and logged despite the fact that logging is not selected for that rule. This is because the rule involving connections on TCP/1-65000 would be evaluated within the policy first and connections made on TCP/1900 would go to the event log even though the rule did not have logging selected.
In this example, using the Take precedence over other <action> rules checkbox in the TCP/1900 rule would allow you to designate its precedence as higher than other deny rules in the policy, giving you the ability to suppress log messages for actions you want to be denied but for which you do not want to be continually notified due to another rule within the policy.
Caution
* Action type
* Precedence checkbox On/Off
* Log checkbox On/Off
Note
Note
The Monitor Action
Most rule types provide a "Monitor" action. You may want to write monitor rules to produce events for certain resource accesses without having to write an explicit allow or deny rule about that resource. You can also write monitor rules in the presence of other similar rules dictating the availability (allow, deny, etc.) of a resource. For example, you can write a monitor rule for a resource and if the monitor rule is triggered, any subsequent rules about the resource in question will trigger as well. This allows you to configure general alerts about resources regardless whether the resource access action is an allow or a deny.
Additionally, you can configure monitor rules to trigger only when an enforcement action of a certain type occurs. This way, you are only monitoring "deny actions on a file resource", for example.
Using the Set Action
Set is a singular configuration action that causes a particular, one-time, configuration item to occur when the criteria configured in the rule triggers on a system. For example, when a rule with "Set" configured triggers, a specific action occurs, such as the security level being set to low. This is different from Add and Remove process tagging. Add and Remove process tagging cause a tag to be bound to a process for the life of that process or until the tag is removed. Set causes a one-time action to occur.
Note
Note
When you select Set as the action type for a rule, an Attribute pulldown menu and a Value pulldown menu appear. For every attribute you can set, there are corresponding values that must also be set. There are several attribute and value pairs you can set for a rule.
Note
Possible attribute and value pairs are:
Attribute: detected access
Values: Protected, Unprotected
This attribute is intended to notify you (via the event log) and optionally take action (via a system state) when an application or service, or other system component that is marked as Unprotected does not have a corresponding Protected rule and is therefore not being protected by the agent.
To use this as a protection auditing tool, you would include a rule that is configured with "Set-detected access-Protected" for the resource that you are protecting in a policy. This rule marks the resource as being protected by the agent.
Subsequently, if you want to make sure that certain resources are being protected on systems, you would configure a "Set-detected access-Unprotected" rule for the resource in question and include it, for example, in a policy attached to the <All OS type> groups. This way, if a resource that requires protection is accessed on a system and there a "Set-detected access-Unprotected" rule without a corresponding "Set-detected access-Protected" rule for that resource, a message is sent to the event log informing you that the resource is not protected.
For example, you could use this feature to ensure that hosts running Web servers are properly protected. To accomplish this, you would write a set rule in the All Windows Group that said "Set-detected access-Unprotected" when any application acts as a server for TCP/80. Another rule would be added to the Microsoft IIS Web Server module specifying to "Set-detected access-Protected" when IIS accepts a connection for TCP/80. (A similar rule could be added for Apache in the corresponding module.) Hosts running an IIS Web Server that have both policies attached would meet the protection criteria and no event would be logged. Hosts with policies that specify the requirement for protection (Unprotected) with no corresponding protection provided (Protected) would have a policy mismatch and would generate an event as a result.
You can configure a System State to apply if a corresponding Set rule of this type triggers. See System State Sets.
Attribute: detected boot
Values: Insecure, Secure
This attribute is intended to detect when a previous system boot occurred in a non-standard manner. For example, the system was booted from a peripheral device (CD ROM) rather than from the hard drive. This type of boot can be considered non-standard and therefore possibly suspicious. (This is one way of introducing a Trojan to a system.) This type of peripheral device insecure boot detection works in conjunction with a particular type of compatible BIOS on compliant systems. The compatible BIOS detects a non-standard boot and on the next normal boot, if you have an appropriately configured Kernel Protection rule (see Kernel Protection, page 6-54), a message is sent to the MC which logs this insecure boot detection. This, in turn, causes the system state (if configured) to trigger. A Safe Mode boot also falls into this insecure boot category. Compatible BIOS is not required for a Safe Mode boot detection.
You can configure a System State to apply if a corresponding Set rule of this type triggers. See System State Sets.
Attribute: detected rootkit
Values: Trusted, Untrusted
A rootkit may be detected when module loads after boot time or a module attempts to modify kernel functionality. Note that if a rootkit gets marked as both trusted and untrusted, a trusted rootkit gets precedence over an untrusted rootkit tag.
You can configure a System State to apply if a corresponding Set rule of this type triggers. See System State Sets.
Attribute: Differentiated Service (Trusted QoS)
Values: priority Best Effort (0,0), priority Scavenger (8, CS1), application specified, IP routing (48, CS6), Voice (46, EF), Interactive Video (34, AF41), Streaming Video (32, CS4), Mission Critical Data (26, AF31), Call Signaling (24, CS3), Transactional Data (18, AF21), Network Management (16, CS2), Bulk Data (10, AF11), Best Effort (0,0). Scavenger (8, CS1)
You specify Differentiated Service for a certain traffic flow by setting a QoS marking which is a recognizable value in an IP packet. This allows routers and switches to identify and take action on QoS-marked traffic, providing finer granularity of control in forwarding traffic.
The available markings provide a DSCP (Differentiated Services Code Point) setting and a PHB (Per Hop Behavior) setting. The DSCP value matches the service field in the IP header. The PHB value matches the way routers and switches handle traffic on a hop by hop basis. These values appear in parenthesis beside each value option in the following order (DSCP,PHB).
Note
Important Details about CSA Differentiated Service Functionality
In the absence of any rules on the agent that provision QoS markings, the general default of all systems is to mark traffic flows as "application specified". In the presence of rules on the agent that provision QoS markings, the agent will select and provision DSCP markings accordingly. If there is a Differentiated Service rule conflict on the agent (i.e. more than one applicable Differentiated Service set rule for a traffic flow), the agent picks the highest marking to provision. (The precedence order of markings is the available pulldown list, top to bottom.)
Note that the agent is only marking packets that it transmits. The agent cannot mark packets that it receives. It is the responsibility of the remote host to mark those packets appropriately.
When the agent is disabled, stopped, or turned to Off using the security slide bar, existing sessions are no longer QoS provisioned by the agent. The agent stops marking existing flows. Existing flows then revert to "application specified". If the agent is re-enabled, authorized flows resume the previous marking provisioned by the agent. If a new session is created during the time the agent is disabled, the new flow is not interfered with when the agent is back in the picture. That flow is automatically given the general system default of allow with an application specified marking and it retains that marking for the life of the connection.
Note that we only authorize at the beginning of a connection.
Note that Test Mode has no bearing on Differentiated Service functionality. The agent provisions the specified markings even if Test Mode is enabled.
Refer to RFC 2475 for general information on Differentiated Services.
You can configure a System State to apply if a corresponding Set rule of this type triggers. See System State Sets. For example, if your network is under attack (i.e. "virus detected") you can configure a system state to trigger that uses rules to downgrade all traffic flows.
Attribute: file
Values: Trusted, Untrusted
A file may be marked as Untrusted Content if it was potentially downloaded from the network or from some other untrusted source. Executable files that are persistently tracked in the agent UI Untrusted Applications window (see The Agent User Interface, page A-8) are localized to each system. Applications that appear in that localized list are automatically added to the built-in application class <*Processes Executing Untrusted Content> (see Built-in Application Classes, page 8-4) and, in turn, that populated built-in application class can be used in rules.
Note that if a file gets marked as both trusted and untrusted, a trusted file tag gets precedence over an untrusted file tag.
Attribute: Host address
Values: Untrusted host (locally and globally), Untrusted host (locally)
This Host address attribute is intended to mark the IP addresses of hosts as untrusted when they violate security policies or exhibit malicious behavior. Being classified as an untrusted host (locally) causes that host to be temporarily added (for one hour) to the @dynamic list on the local machine. Additionally, if the untrusted global attribute is used, an event is sent to CSA MC to make the host address a candidate for global event correlation. If this address is centrally correlated, it's permanently added to the global quarantine list on all hosts (if the configured event correlation threshold is reached).
Tip
You can configure a System State to apply if a corresponding Set rule of this type triggers. See System State Sets.
Attribute: Security level
Values: High, Medium, Low
Set the Security Level attribute to programmatically change the agent security level based on the current running state of the system. For example, if the agent security level is low and a virus is detected on the system, this can trigger a system state policy that will automatically be applied when the state has been moved to high. On a high setting, you may enforce a rule that denies the virus-infected system from making outgoing network connections.
You can configure a System State to apply if a corresponding Set rule of this type triggers. See System State Sets.
Querying the User
When you create access control rules, beyond simply allowing or denying a specific action, you can select to query the user when an action triggers the rule in question. The user can then decide to allow the action, deny it, or terminate the process at that time. When you select to query the user, you are also crafting explanation text to display to the user and whether to allow, deny, or terminate the action by default if the query is not answered within 5 minutes. If the user is not logged in to the system, the default action is taken immediately.
Query configurations are a Variable setting which allows you to decide which radio button options are displayed in the pop-up query box, which action is the default, whether the answer given by the user is to be remembered, and what the query text to be displayed will be.
For a Query setting, the response to the query is relevant to the question, not the resource. For example, if a File access control rule queries the user for a response and that identical query is also configured for a Network access control rule, the user is not queried again when the Network access control rule triggers. The query response from the previous File access control rule is automatically taken.
See Query Settings, page 9-25 for configuration details.
Caution
For Windows and Linux agents, agent settings (including user queries) are configurable by the administrator. If the agent UI is hidden for the group, there are no query user pop-up boxes displayed. The default is immediately taken on all query user rules and heuristics that are present in the assigned polices.
When an action is attempted on a system where a query user rule is triggered, a pop-up box appears on the system where the resource is located.
Figure 5-14 Query User Pop-up Box
From the Query Settings page, accessible from the Configuration>Variables menu, you configure the query text and the query radio buttons that appear in the pop-up box the end user will see. In the Query pop-up box, the user reads the information given on the attempted action and selects one of the following possible choices and clicks Apply:
•
•
•
Default Action—You chose one of the radio buttons displayed in the query pop-up to be the Default action. If the query is not answered by the user within 5 minutes or if the user is not logged in to the system, the default action is taken immediately.
Don't ask me again—In addition to the button s that will appear on the query box, you can decide to also display a Don't ask me again checkbox so that the user's query response is remembered. If the user selects that checkbox when he/she responds to the query, and the same query is triggered, the remembered response is automatically taken and the user is not queried again.
Query challenge—For added security, you can issue a query challenge on the query pop-up box. If the default answer is not selected by the user and the selected answer is weaker than the default, a challenge will appear. This ensures that the user sitting in front of the system is answering the query rather than a malicious remote user or program attempting to respond. To pass the challenge, the user enters the information displayed in a graphic on the pop-up box itself.
(See Query Settings, page 9-25.)
When you configure your query settings for the rule, the text you type into the Query Setting page's Text used to query user field is the same text that will appear in the Query User pop-up box to explain what is occurring on the system to the user. Therefore, making this information descriptive of the system action that triggered the pop-up is important.
Caution
Caching Responses
When users are queried, the agent can remember the response permanently or temporarily. This way, if the same rule is triggered again, the action is allowed, denied, or terminated based on what answer was given previously with no pop-up query box appearing again either permanently or for some period of time.
For example, if a user is queried as to whether an application can talk on the network and the user responds by selecting the Yes radio button and clicking a Don't ask again checkbox, the Yes response is remembered permanently and that response appears in the edit field in the agent UI query response window. But if the user is queried as whether setup.exe can install software on the system and the user responds by selecting the Yes radio button, but there is no Don't ask again checkbox or it is there but the user does not select it, this response is remembered temporarily and it does not appear in the agent UI query response window.
If the user response is only cached temporarily (for approximately an hour) the user can click the Clear button in this window to delete all temporarily cached responses. To clear permanent responses listed in the edit field, the user must select the response in the edit field and press the Delete key.
Notes about Query Caching
•
•
•
•
Query Rule Priority Information
You should note how CSA MC manages rule priority if there are multiple similar query rules which need to be evaluated.
Base Priority: Action=Allow, Deny Terminate/no challenge/no don't ask again/no logging.
Relative priorities for query options that are turned on are as follows (top to bottom):
•
•
•
•
•
•
