-
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
-
Table Of Contents
Merging or Copying Rule Modules
Attaching Rule Modules to Policies
Common Rule Page Configuration Items
Rules: Action Options and Precedence
Rules: Manipulating Precedence
Attribute: Current Application Virus Classification
Attribute: Custom-made state condition
Attribute: Data Payload trust status
Attribute: detected rootkit trust status
Attribute: Differentiated Service (Trusted QoS)
Attribute: Digital signature check
Attribute: Discovery of other CSA nodes
Attribute: file Data Classification
Attribute: Host address trust status
Attribute: Sensitive Data Scan
Attribute: Timer to restore Security
Attribute: Virus scan on CLOSE
Query Rule Priority Information
Identifying Hosts in Audit Mode
Additional Notes on Learn Mode
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 rules that enforce security and detect behavior. Enforcement and detection actions are hierarchical and follow certain rules of precedence. (See Rules: Action Options and Precedence for more information about precedence.)
Examples of enforcement actions are when CSA allows, denies, or terminates a process when it attempts to access a resource. Examples of detection actions are when CSA notifies users, monitors application behavior, and tags resources. One way CSA protects systems is by combining rules that enforce security and detect behavior. For example, a detection rule could be written to add a process to an application class based on the application's behavior. Then, an enforcement rule could be written to deny all the members of the application class from accessing a particular resource.
In rule display lists, enforcement rules are shown at the top of the list and detection rules are shown at the bottom. Figure 5-2, Rules List in Rule Module shows a rule display list with three enforcement rules and one detection rule.
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 Global Settings" for more information.)
Some rule types are common to all operating systems while others are available for a specific operating system. Rule types may be used by both Windows and UNIX operating systems, Windows operating systems only, or UNIX operating systems only. References to UNIX operating systems encompasses both Solaris and Linux operating systems.
Administering Rule Modules
The following sections describe the tasks associated with configuring and managing rule modules.
Configuring Rule Modules
Rule modules consist of one or more rules. One or more rule modules are meant to be attached to a policy. You can attach multiple policies to a single group. A host can belong to multiple groups and inherits the policies from all the groups to which it belongs. When more than one policy is associated with a host, the rules modules in the individual policies are merged as though they were all defined within a single policy. In particular, the rules in the policy are ordered in the same sequence as they would be within a single module.
The policy level is the common ground by which host groups acquire the rules that make up their security policy.
Note
Caution
To configure a rule module, do the following:
Step 1
Step 2
Step 3
Step 4
Note
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
Refer to the descriptions of rule types in Chapter 6, "Available Rule Types" for details on creating the rule you selected.
Note
Adding Rules to a Rule Module
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Figure 5-1 Rule Module, Modify Rules
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-2.
The ID column in the Rules section shows 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-2) 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-2 Rules List in Rule Module
Filtering the Rules Display
The Groups configuration page, Policy configuration page, and the Rule Module configuration page each display a table listing either the rules attached to the group or the rules included in the module. 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
Step 4
Step 5
Step 6
All checked rules are copied to the selected module.
To clone rules within a module, repeat steps 1-4 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.
Comparing Configurations
The purpose of this compare tool is to assist you after you have 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 available for Groups, Rule Modules, Policies, Application Classes, and Variables.
Any CSA MC user can compare rule modules when viewing the CSA MC in Advanced Mode; however, only users with configure privileges can copy, merge, or delete rules in the compared modules.
When you compare 2 items (you cannot compare more than 2 configurations at a time), CSA MC displays the configurations side by side and highlights the differences in red (see Figure 5-3). Once users, with configure privileges, evaluate the differences in configurations, they can select to merge specific rules, to copy rules to another rule module, or to copy rules to a new module; additionally, they can attach and detach groups and policies. They can also compare application classes and variables, but they can only copy and merge rules from the compare page.
Feature notes:
•
•
•
•
To compare two rule modules, follow this procedure:
Step 1
Step 2
Step 3
Figure 5-3 Compare Rule Modules
Merging or Copying Rule Modules
Merging or copying rules from one module to another starts with comparing two rule modules. After you compare the rule modules and evaluate the differences, you can copy rules from one module to another.
Step 1
Step 2
•
•
•
Step 3
Figure 5-4 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-5.
Figure 5-5 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
Step 5
Note
Caution
Figure 5-6 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-7 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
•
•
•
See Log and Notification Settings, page 8-19 for more information.
•
•
Note
For every rule 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.
The Notify User Action
When you configure various rule types, you can notify users if their action triggers the rule. Users must then acknowledge the notification and you can ask them to enter a justification for their action in the notification pop-up. The Notification Settings configuration window (see Notification Settings, page 8-19) lets you choose an OK button or a combination of Yes and No radio buttons to add to the notification pop-up window.
When you select Notify User as the action type for a rule, a Notification Settings pulldown menu appears. You must select one of the preconfigured Notification Setting as part of the rule. You configure a Notification Setting from the Notification Settings configuration page, accessible from the Configuration>Variables menu. There you configure the notification text and the buttons that appear in the pop-up notification box the end user will see. You can also select to have a justification free form text field appear on the pop-up window. See Notification Settings, page 8-19 for configuration information.
Presenting the user with a notification pop-up with various buttons and a justification edit field can serve the following purposes:
•
•
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
The rest of this section describes possible attribute and value pairs.
Attribute: Current Application Virus Classification
The set current application Virus Classification attribute assigns a static behavior-based AntiVirus tag to an application.
After specifying the current application Virus Classification attribute, select one of these values:
•
•
•
•
•
•
Many types of rules can assign a behavior-based antivirus tag to an application when the application interacts with another application an attempts a certain activity. Behavior antivirus tags are "static." The tags can be assigned to an application and they can be configured by the administrator but their names cannot be changed.
If there are two rules with the same tagging requirements and one rule applies a "no static tag" and one rule applies one of the behavior static tags, the rule with the "no static tag" classification takes precedence and the application does not receive a static tag.
For more information about how these tags are used and how behavior-based antivirus works, see AntiVirus Basics, page 15-2.
Attribute: Custom-made state condition
This set action allow you to define custom system states to suit your enterprise's individual needs. After specifying the Custom-made state condition set attribute, select one of the values, Custom 1 through Custom 10.
The custom-made state conditions can be created using many different rule types. This allows administrators to define custom states using a wide variety conditions.
A benefit of custom states is protecting resources without having a host enter a High, Medium, or Low security level system state. If users change the security level on their agent, this will have no affect on the rules that enforce security based on your custom system state.
Hosts can only be in one custom state at a time. If different rules, defining different custom states are triggered for the host, the host moves to the custom state that was triggered last. The host remains in that custom state until system states are reset on the agent. See Resetting Cisco Security Agents, page 3-6 the procedure to reset an agent from the CSA MC. The Detailed status and diagnostics link on the Host Details page lists the system state(s) that the host is in.See the "Host Status" section on page 3-20 for more information.
After you create a custom state, you will need to create a system state set that references the custom state. You can also configure the system state set to include additional factors like scanning data tags or static data tags. In order to protect a resource, you will then need to create a protection rule that specifies the new system state set.
Custom states can be defined by these rule types.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Attribute: Data Payload trust status
Values: After specifying the Data Payload trust status attribute, select one of these values:
•
•
•
•
•
•
•
•
•
By using a rule that sets Data Payload trust status to Untrusted, you are configuring the system to try to create a signature when a specific type of action is detected by a rule. When this detection occurs, the payload is retrieved by the agent and signature generation is attempted. If a signature is generated by a rule that includes a global setting, the agent sends the signature to the MC for global distribution. Agents with rules that enforce restrictions based on global signatures then receive the newly created signature and are protected against that particular attack.
Locally and Globally Explanation
If a data payload is classified as unchanged or untrusted locally, it causes a generated signature to be temporarily added (for one hour) to the @signatures or @highrisk_signature lists on the local machine. Additionally, if the unchanged or untrusted global attribute is used, an event is sent to CSA MC to make the generated signature a candidate for global event correlation. If the signature is centrally correlated, it is added to the global signature list on all similar hosts, if the configured event correlation threshold is reached.
Attribute: Data scan on CLOSE
After specifying the Data scan on CLOSE attribute, select one of these values:
•
•
The Data scan on CLOSE attribute is available for File Access Control rules (FACLs).
If a FACL requires a data scan on CLOSE, CSA compares the content of the file to the scanning data tag patterns when the file is closed. (These tags, and their definitions, may be found by navigating from the Configuration menu, Global Settings > Scanning Data Tags.) If the content in the file matches the pattern of a scanning data tag, the file is given the tag. A file may have more than one scanning data tag. (See Scanning Data Tags and Static Data Tags, page 16-3 for more information on these types of tags.)
If a FACL does NOT require a data scan, the data scan does not occur.
Note
Attribute: Data scan on OPEN
After specifying the Data scan on OPEN attribute, select one of these values:
•
•
The Data scan on OPEN attribute is available for File Access Control rules (FACLs).
If a FACL requires a data scan on OPEN, CSA compares the content of the file to the patterns defined by scanning data tags, when the file is opened. (These tags, and their definitions, may be found by navigating from the Configuration menu, Global Settings > Scanning Data Tags.) If the content in the file matches the pattern of a scanning data tag, the file is given the tag. A file may have more than one scanning data tag. (See Scanning Data Tags and Static Data Tags, page 16-3 for more information on these types of tags.)
If a FACL does NOT require a data scan, the data scan does not occur.
Note
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, page 8-28.
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-39), 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, page 8-28.
Attribute: detected rootkit trust status
After specifying the detected rootkit trust status attribute, select one of these values:
•
•
This set attribute is available for network access control, kernel protection, system API control, buffer overflow, and Rootkit/Kernel protection rules.
A rootkit may be detected when a module loads after boot time or a module attempts to modify kernel functionality.
Use this set attribute with NACLs to detect a rootkit in either of these circumstances:
•
•
A rootkit is designated as "untrusted" if CSA detects malicious behavior and a rule tags the object as "untrusted." If you know an executable behaves like a rootkit but is benign, you can use the set detected rootkit trust status to "unchanged." The Unchanged rootkit trust status takes precedence over an Untrusted rootkit trust status.
You can configure a System State to apply if a corresponding Set rule of this type triggers. See System State Sets, page 8-28.
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
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.
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, page 8-28. 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: Digital signature check
After specifying the Digital signature check, select one of these values:
•
•
The Digital signature check attribute is available for File Access Control rules (FACLs).
If a FACL requires a digital signature check, CSA extracts the digital signature from a file and identifies it. This set action is used in one FACL in the Base - Digital Signatures for Downloaded Executables rule module distributed with this release. In this implementation, the digital signature check is required for untrusted executable files.
If a FACL does NOT require a digital signature check, the digital signature check does not occur.
Note
Attribute: Discovery of other CSA nodes
Values: Disabled, Enabled
This set attribute is available for the following rule types; Buffer Overflow, Connection rate limit, Data access control, Network access control, Network Shield, and System API. It is intended to determine if a host IP address has an active Cisco Security Agent associated with it. If so, a list of active agent systems is maintained and can be used in rules, via a cookie (@csanode) to restrict or allow communication and resource availability based on the presence of an active agent. For example, if an agent is detected on a system, allow the system in question to communicate with "n" systems. Using this set rule type, you can enable/disable csa node detection on a per connection basis.
Attribute: file Data Classification
Values: Static data tags
The set attribute is available for file access control (FACL) protection rules. This attribute allows a file to be tagged with a static data tag without having to scan its contents.
After specifying the file Data Classification attribute you select a static data tag from the values list. Static data tags are distributed with this release of CSA and are available for you to configure and use. See Scanning Data Tags and Static Data Tags, page 16-3 for more information on these types of tags.
You cannot change the names of these tags and you cannot create new static data tags. Static data tags are assigned to files based on what group of applications attempt to access them. You define the parameters for static data tags based on your enterprise's needs. This tagging method may be useful if, for example, you have a specialized application. For example, you my know in advance that any file that your specialized application reads should be considered a <HIPAA Controlled> file.
Attribute: File deletion
After specifying the File deletion attribute, select one of these values:
•
•
The File deletion attribute is available for Scan Event Log rules.
This attribute allows you to mark a file with a scanning data tag, static data tag, or virus scanning tag for deletion by the Security Agent.
Note that if a file gets marked as both requiring and NOT requiring deletion, the delete will not be performed.
Attribute: file trust status
After specifying the file trust status attribute, select one of the following values:
•
•
•
•
•
This list of values is hierarchical. If there are two similar rules that apply to an action and one rule tags a file as Trusted and the other rule tags the file as Untrusted (until CSA AV Scan), for example, the rule that applies the Trusted tag triggers first and applies its tag. The second rule applying the Untrusted (until CSA AV Scan) will not be triggered.
The set attribute is available for file access control (FACL) protection rules.
Unchanged
Use this file trust status to leave the existing trust status of the file unchanged. This could prevent, for example, a network application, such as a backup tool, from changing the trust level of a file because it opens the file.
Trusted
When a file is designated as "Trusted," it is removed from a database of untrusted files that is maintained locally on the host. The file does not receive a Trusted tag, it loses its Untrusted tag.
Only files that were dynamically tagged as Untrusted can be changed to Trusted using the file trust status attribute. Files that are statically defined by a policy as Untrusted can not be designated as Trusted.
Untrusted (until CSA AV scan)
"Untrusted (until CSA AV scan)" is a kind of "Untrusted" classification. The file is treated as Untrusted once the rule triggers and while the file remains on the system. If the file has been on the system for at least 90 days, and then CSA AV scans the file and determines that the file is not infected with a virus, the file will lose its Untrusted (until CSA AV scan) tag and be treated as Trusted.
The Untrusted (until CSA AV scan) tag takes precedence over the general Untrusted tag.
Untrusted
Use the "Untrusted" file trust status attribute to permanently tag a file as untrusted.
When a file is dynamically tagged as Untrusted by the triggering of a rule, the file name is added to a database of untrusted files that is maintained locally on a host.
Applications that are marked as untrusted, which have attempted to run, appear in the Untrusted Applications window of the local agent. These applications are also automatically added to the built-in application class <*Processes Executing Untrusted Content> (see Built-in Application Classes, page 9-3). That populated built-in application class can be used in rules.
Untrusted (temporary)
"Untrusted (temporary)" is a kind of "Untrusted" classification. Downloaded network applications with unrecognized file extensions, are treated as Untrusted for 60 seconds. If the network application runs within those 60 seconds, the network application receives an Untrusted tag. If the file does not run, it loses its Untrusted (temporary) tag and it is treated as Trusted.
All other set file trust status attributes take precedence over the Untrusted (temporary) tag.
Attribute: Host address trust status
After specifying the Host address trust status attribute, select one of these values:
•
•
•
This list of values is hierarchical. If there are two similar rules that apply to an action and one rule tags a file as Unchanged and the other rule tags the file as Untrusted (locally), for example, the rule that applies the Unchanged tag triggers first and applies its tag. The second rule applying the Untrusted (locally) will not be triggered.
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
If you want to prevent a host address from being tagged as untrusted locally or globally, in a certain set of circumstances, you can create a rule that sets the attribute to "unchanged" for those circumstances and that rule will take precedence over other similar rules.
You can configure a System State to apply if a corresponding Set rule of this type triggers. See System State Sets, page 8-28.
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, page 8-28.
Attribute: Stack
Values: recovery
If you are using the Set Stack Recovery action, you are configuring the system to try to recover and unwind the stack back to a safe place when and unhandled exception has occurred. Stack recovery is intended for vital services only. You may simply want to let non-vital services fail.
Attribute: Sensitive Data Scan
Values: being required for this file, NOT being required for this file
A file may be marked as requiring or not requiring a scan for sensitive data.
Attribute: Timer to restore Security
After specifying the Timer to restore security attribute, select a time value or specify that restoring security is NOT being required.
The time value indicates how long after CSA security has been set to "Off" or a after a "net stop csagent" has been performed will CSA security be turned back on automatically.
The Timer to restore security attribute is available for Agent Service Control rules.
If a host is affected by several Agent Service Control rules with differing time values for restoring security, and one of those values is NOT being required then restoring security as NOT being required takes precedence over all other time settings. In this case, CSA will not be restarted automatically.
If there are more than one required time setting specified by various Agent Service Control rules and there are no rules specifying that restoring security is NOT being required, the shortest time configuration required to restart security takes precedence over all others.
Note
Attribute: Virus scan
After specifying the Virus scan attribute, select one of these values:
•
•
The set attribute is available for Application control rules.
When the virus scan is required, an application control rule using this set attribute, causes CSA to perform a virus scan, with Clam AntiVirus, when an application from one application class attempts to run an application from another application class.
When a virus scan is not required, the virus scan does not occur. If a file is affected by a rule which does not require a virus scan and a rule that does require a virus scan, the virus scan does not occur.
When CSA detects a Application control rule on the host with this set attribute, the AntiVirus window, in the agent interface, becomes available to the user. See "AntiVirus Protection" section on page A-12 for a description of the AntiVirus screen in the agent interfaces.
Attribute: Virus scan on CLOSE
After specifying the Virus scan on CLOSE attribute, select one of these values:
•
•
The Virus scan on CLOSE attribute is available for File Access Control rules (FACLs).
When the virus scan is required, A FACL using this set attribute causes CSA to perform a virus scan, with Clam AntiVirus, when an application attempts to write a file, or when an application attempts to create, rename, or delete a directory. The virus scan occurs when the user closes the file. If a virus has infected a file, the infection will be caught immediately after the file has been modified.
When a virus scan is not required, the scan does not occur. If a file is affected by a rule which does not require a virus scan, and a rule that does require a virus scan, the virus scan does not occur.
Note
Attribute: Virus scan on OPEN
After specifying the Virus scan on OPEN attribute, select one of these values:
•
•
The Virus scan on OPEN attribute is available for File Access Control rules (FACLs).
When the virus scan is required, a FACL using this set attribute, causes CSA to perform a virus scan, with Clam AntiVirus, when an application from an application class attempts to Read or Write a file, or when an application from an application class attempts to create, rename, or delete a directory. The virus scan occurs when the file is opened.
When a virus scan is not required, the scan does not occur. If a file is affected by a rule which does not require a virus scan and a rule that does require a virus scan, the virus scan does not occur.
Note
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 8-20 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-8 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.
Logged query responses—In addition to deciding which query actions (Allow, Deny, Terminate) are available to the user for the query pop-up, you can also configure the query response to log only when a particular query action is selected by the user. Using the multi-select box available from the Logged query responses section, you can select one or more response types to produce a log message. For example, if all query actions are being made available for the query, you can configure only a Terminate response to produce a log message. (By default, all query responses are logged.)
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 8-20.)
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
Requesting User Justification—In addition to querying the user, you can request the user enter a user justification statement in a pop-up window edit field. This free-form justification text, supplied by the end user, appears in the event log message on the MC. The presence of this field allows the user to explain why a resource is be accessed or an action is being performed.
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):
•
•
•
•
•
•
Rule Overrides
Audit Mode and Learn Mode are useful tools during piloting or initial deployment of CSA.
Using Audit Mode
Audit 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 audit mode, the agent will not deny any action or operation even if an associated rule indicates that 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 or rule module on a host before enforcing it. If examining the logs shows you that the policy or rule module is working as intended on a group, you can then remove the audit mode designation.
When using Group audit mode (available from the Rule Overrides area), 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 audit mode sends events to CSA MC, event log messages are preceded with the word "Audit". 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 word "Audit." Event detection (not prevention) messages appear the same in the event log regardless if audit mode is on or off.
Group Audit Mode
If audit mode is enabled on the group level, all rules on hosts within audit mode groups are in audit mode.
If a host belongs to a group with audit mode selected, all policies associated with that host are in audit mode (even if the host is part of another group that does not have audit mode selected), not just the policies applied to the audit group. Therefore, audit mode applies to the host as a whole, not to specific policies.
You can determine if a group is in audit mode in one of these ways:
•
•
•
Note
Rule Module Audit Mode
You can also use audit mode on the rule module level. If a rule module attached to a policy is in audit mode, only the rules associated with that rule module are run in audit mode. The rules in the other rule modules of the policy continue to be run in whatever mode they are configured for. 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.
If a rule module is in audit mode, and it is used in more than one policy, the rule module will be in audit mode in every policy to which it is assigned.
Caution
You can determine if a rule module is in audit mode by looking in one of these locations:
•
•
•
Policy Audit Mode
A policy can only be put in test mode in the context of a group. This means that if a policy is in more than one group, the policy could be in audit mode in one group and in live mode in another group. For a group that uses the policy in audit mode, all of the rules in that policy are in audit mode.
If a host uses two identical rules and one is in audit mode and one is in live mode, both rules will trigger. The audit mode rule will have no effect. The live mode rule will enforce whatever action it is designed to enforce.
You can determine if a policy is in audit mode by looking in one of these locations:
•
•
Identifying Hosts in Audit Mode
A host is considered to be in audit mode if any group to which it belongs is in audit mode. Individual rules on a host may be in audit mode if a rule module, or a policy for a group to which the user belongs, is in audit mode. Hosts, themselves, cannot be configured to be in audit mode.
If you want to determine the extent to which a host is auditing rules or enforcing rules, look at these locations:
•
•
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, after the agent is initially installed, there is a non-configurable, automatic, normalization learning period of 72 hours of running time. This learning is for both running applications and unusual system calls. After that, you can 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 Audit 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
•
•
•
•
•
•
•
