Feedback
Table Of Contents
Example A: Excessive Denies to a Particular Port on the Same Host
Example B: Same Source Causing Excessive Denies on a Particular Port
Example C: Same Host, Same Destination, Same Port Denied
Working with System and User Inspection Rules
Change Rule Status—Active and Inactive
Edit a Rule with Inline Editing
Edit a Rule with the Rule Wizard
Change Drop Rule Status— Active and Inactive
Configure an Alert for an Existing Rule
Rule and Report Group Overview
Global Controller and Local Controller Restrictions for Rule and Report Groups
Adding, Modifying, or Deleting a Rule Group
Adding, Modifying, or Deleting a Report Group
Display Incidents Related to a Rule Group
Create Query Criteria with Report Groups
Use Rule Groups in Query Criteria
Rules
This chapter discusses MARS Inspection and Drop rules, how to construct and employ them, as well as how to set alerts and use rule and report groups.
This chapter contains the following topics:
•
Working with System and User Inspection Rules
Rules Overview
An inspection rule is a real-time filter that detects interesting patterns of network activity. These patterns can signify attacks or false positives, and they inform you of network configuration errors and other anomalous network behavior. Rules on the Global Controller are propagated down to Local Controllers. When these rules are triggered, incidents are sent to the Global Controller.
An attack might be straightforward, or it could be a probe, an attack, and then a follow-up to the attack. Whatever the method of attack, attacks share common traits, and you use rules to define these traits to identify and mitigate attacks.
Rules create incidents. Rules connect the information you receive from your networks' reporting devices, linking them together to form a chain of events that describes an unfolding intrusion. They classify incoming events as firing events by matching them against the rule criteria. They also determine when a false positive is either dropped completely or kept as information in the database.
A rule is either active or inactive. Active means the rule is operating and is being applied to incoming events. Inactive indicates that the rule is inoperative and not consuming CS-MARS resources. For a list of all system inspection rules, see Appendix E, "System Rules and Reports".
Figure 4-1 shows a portion of the Inspection Rules page of the Rules tab.
Figure 4-1 Top Portion of Inspections Rules Page on a Local Controller
Prioritizing and Identifying
Your first order of business is to prioritize your network's assets; in other words, figure out what is going to be the most damaging if it goes down. Next, identify your networks' most exploitable weaknesses. Choose which ones you are willing and able to close, and rank the remaining weaknesses by risk and exploitability.
Use this ranked list to guide your time and energy expenditures when customizing the CS-MARS rule set.
Thinking Like a Black Hat
Ignore for a moment the benign users who do legitimate business on your networks.
Get inside the mind of the black hat that wants to take your network down. The person who should concern you is the one with a plan.
Good plans have a sequence of steps, contingencies, and metrics to determine success or failure. The more fully you can anticipate these plans, the fewer attacks will be able to execute unhindered and unobserved. The black hat is looking for wide-open doors and easy access. Failing that, the black hat is going to look for specific and obvious exploitable weaknesses.
Planning an Attack
Start to detail the plan for how you would attack your network. You want to penetrate a network. You'd like to avoid detection and identification if possible. You want root access on a host.
How do you get root access? You do not have a preexisting account, and physical access isn't feasible. The first few options that come to mind are password guessing, password brute force, or exploiting a known weakness on the host.
You decide to exploit services running on the host, so you need to find out what it is running. To do this, you have a number of techniques: port scans, OS fingerprinting, banner probing, etc.
Once you've identified a vulnerable service or software, you can attack it with a catalogue of exploit software. Depending on what you find and your available exploits, there are a number of different effects, usually allowing you to execute arbitrary code.
You now own the host. What happens next is up to you. You have many options: you can install a root kit, you can crash the machine, etc. You have full access—you can do just about anything to/from/on that host.
Back to Being the Admin
You must now express the plan in terms of information that is reported to you. This attack plan contains an attack with a follow up of some kind. You might write your plan like:
•
•
•
At this point, the black hat has compromised the host. What happens next is up to the attacker. This makes the next few steps especially hard to predict. They want to be able to manipulate the world, they want to make change. Your newly compromised host is the instrument for change. You can specify additional potential steps in the plan that make it even more urgent to take care of the situation immediately. Such as:
•
•
The attacker is now using your compromised host as a launching point for further attacks.
One you've mapped out the anticipated attack to watch for, you can define a monitoring plan. The following task flow outlines the tasks involved in implementing a monitoring plan:
Step 1
Step 2
Step 3
Note
Step 4
Types of Rules
This section details the following types of rules:
Inspection Rules
An inspection rule states the logic by which the CS-MARS tests whether or not a single network event or series of events is a noteworthy incident. An event or series of events with attributes that match the attributes specified in an inspection rule causes the rule to trigger (or "fire") to create an incident. Incidents may be attacks, network configuration errors, false positives, or just anomalous network activity. The over 100 inspection rules that ship with MARS are called System Inspection Rules. The number and structure of system rules are updated in signature upgrades and with more recent software releases. Both types of upgrades are performed from the Admin > System Maintenance > Upgrade page.
You can create custom inspection rules by editing or duplicating system inspection rules, by adding your own from the Inspection Rules page, or by using the Query interface. Customized inspection rules are called User Inspection Rules and are displayed on the Inspection Rules page.
Inspection rules can be created on both the Global Controller and the Local Controllers. Rules on the Global Controller are propagated down to Local Controllers. When these rules are triggered, incidents are sent to the Global Controller.
Global User Inspection Rules
Global Inspection Rules are inspection rules you create on a Global Controller and then push to the Local Controller. From the Local Controller, you can edit only the Source IP Address, Destination IP Address, and Action fields of a Global Inspection Rule. To change the arguments of the other fields, you must edit the rule on the Global Controller. When you edit a global inspection rule on the Local Controller then edit it again on the Global Controller, the Global Controller version overwrites the Local Controller version. Global Inspection Rule names are displayed with the prefix "Global Rule."
Drop Rules
Drop rules enable false-positive tuning on a MARS, and are defined only on the Local Controller Drop Rules page. They allow you to refine the inspected event stream by specifying: 1)events and streams to be ignored and 2)whether those data should be stored in the database or discarded entirely. Drop rules are applied to events as they come in from a reporting device, after they have been parsed and before they have been sessionized. Events that match active drop rules are not used to construct incidents. Because the Global Controller does not receive events from reporting devices, rather it receives them from Local Controllers, you cannot define drop rules for the Global Controller.
Constructing a Rule
Each step of your plan corresponds to a line of a rule. Each line identifies a set of conditions. A rule can have a single line, two lines, or multiple lines. You link these lines together using the logical operators, "AND, OR, FOLLOWED-BY (in time)."
For more information on the conditions and operators found in a rule, see Table 4-1.
The first step of the example plan, identified in Back to Being the Admin, involved probing the target host. You can express a probe by selecting the appropriate event type groups as the line's event type criteria. Also, you want to use dollar variables ($TARGET) to constrain your host to ensure that the probe and attacks that are reported have happened to the same host. Then you need to figure out the logical step for the next line. In this case, the probe could be optional depending on the time frame in which the probe was sent and its subtlety.
Note
•
A variable, such as ($TARGET), serves two purposes in the rule: 1.) It captures the number of times the same cell value is matched upon—the count for that cell, e.g., ten login failures from the same source address. 2.) It correlates the same value of a cell across rule lines, for example, a probe from a source address AND an attack from that same source address.
Identical variables used in different fields mean that the values represented by the variable are the same. For instance, if $TARGET01 were the only argument in the Source IP Address and Destination IP Address fields of an offset, the rule can only fire when the two address of the event are the same. Such a rule may never fire.
•
•
(Probe ANDAttack) ORAttack)
Note
Success likely rules extend the attempt rules by identifying suspicious activities originating from the attacked host. The general structure of these rules is:
((Probe ANDAttack) ORAttack)) FOLLOWED BY(Suspicious Activity[1]..Suspicious Activity[n])Failures identify an event from a reporting device that the device classifies as a failure. Often, these rules simply match to known syslog or SNMP messages indicating some failure on the device. You can define alerts to keep you abreast of device failures. These rules follow one of two general structures: a one line failure—
Failure—or multi-line failures separated by the OR operator—
1.. N Failure ORFailureIn the HTML interface, system rules are displayed in rows and columns. The row number is called the Offset. A rule can have more than one row (or offset), as shown in Figure 4-2.
Figure 4-2 Rule with Multiple Offsets
The flexibility in rule construction is a factor of the rule's fields and arguments; these are detailed in Table 4-1
Table 4-1 Rule Fields and Arguments
The row number.
Identifies the opening of a clause. Clauses are used to compare one or more compound conditions in a rule.
Displays the open braces you create a clauses.
IP address of the packet originator.
Variables
ANY —(Default). Signifies that the IP address for each count is any IP address.
SAME— Signifies that the IP address for each count is the same IP address. This variable is local to its offset.
DISTINCT— Signifies that the IP address for each count is a unique IP address. This variable is local to its offset.
$Target01 to $Target20— The same variable in another field or offset signifies that the IP address for each count is the same IP address.
Network Groups
Defined network groups—Topologically valid network groups as defined under Management > IP Management.
Networks
Topologically valid network groups as defined under Management > IP Management.
Devices
The hosts and reporting devices present in the system.
IP addresses
IP addresses present on devices in the system or user entered dotted quads.
IP ranges
The range of addresses between two dotted quads.
IP address of the packet destination. Often referred to as the target.
Variables
Network Groups—
Defined network groups—Topologically valid network groups as defined under Management > IP Management.
Networks —
Topologically valid network groups as defined under Management > IP Management.
Devices— The hosts and reporting devices present in the system.
The hosts and reporting devices present in the system.
IP addresses—
IP addresses present on devices in the system or user entered dotted quads.
IP ranges— The range of addresses between two dotted quads.
The range of addresses between two dotted quads.
A TCP/IP-based network service, identified by protocol and port, defined within the packet.
Variables
ANY—(Default) No constraint is placed on the source or destination ports or protocol or port.
SAME type variables signify that the specified destination port, source port and protocol are the same for each count. These variables are local to the offset.
•
SAME_TCP_DEST_PORT
SAME_UDP_DEST_PORT•
SAME_TCP_SRC_PORT
SAME_UDP_SRC_PORTDISTINCT type variables signify that the specified destination port, source port and protocol are unique for each count. These variables are local to the offset.
•
Identical variables in different fields or offsets signify that the specified port and protocol for each count are identical to each other.
•
•
•
•
•
•
•
•
•
Defined services —One or more services defined under Management > Service Management.
Service groups —One or more service groups defined under Management > Service Management.
•
•
•
•
•
•
•
•
•
Identifies one or more event types. An event type indicates some type of network activity or condition. Sometimes, events reported from different devices and different device types identify the same activity or condition, and therefore, they map to the same event type within MARS. Event types are sorted into event groups, such as "Probe/PortSweep/Stealth", to catch any of the network conditions identified by the group.
Variables —Signify any single event type defined under Management > Event Management, only useful for lines in tandem with the same variable.
•
•
•
•
Event types —Events that have been merged into types.
•
•
•
•
Event type groups —Groups of event types.
•
•
•
Red Severity Event Types—Displays all severe event types
Yellow Severity Event Types—Displays all yellow event types
Green Severity Event Types—Displays all green event types
The value of this condition can be one of the following:
Variables —Signify any single device defined under Admin > System Management > Security and Monitor Devices, only useful for lines in tandem with the same variable.
•
•
•
•
•
•
Defined Device Types—
Reported User
Identifies the active user on the host when this event was recorded. Not all events include this data. The value of this condition can be one of the following:
•
•
•
•
IPS Risk Rating
Identifies, on a scale of 0 to 100, the Risk Rating (RR) value assigned by an IPS device version 6.0 or greater. The higher the RR the greater the security risk
You can use the IPS RR to filter events in a report.
For additional information see, Cisco IPS Risk Rating Explained.
IPS Threat Rating
IPS Threat Rating (TR) provides a single view of the threat environment of the network.
You can use the IPS TR to minimize alarms and events by customizing the viewer to show only events with a high TR.
IPS Global Correlation Score
Identifies, on a scale of -10 to 10, the Global Correlation Score assigned to a device, if one has been assigned. It indicates the probability that a particular attacker IP address will initiate malicious behavior based on its known past activity.
You can use the IPS Global Correlation Score to filter events in a report.
For additional information see, Configuring Global Correlation.
Severity
The value of this condition can be one of the following:
•
•
•
•
Count
Identifies the number of items the event must occur before the condition is met. The value for this condition is a whole number ranging between 1 and 100. The default value is 1.
Note
Example usage: When a backdoor rootkit install is detected, the count should be 1 as it is only going to be reported once and it is not something you expect to ever see on your network. However, if you are using deny messages to detect infected hosts, you may want the count value to be higher. For example, you may want to allow for several common mistakes, such as password failures, before firing a rule for the event. People accidentally mistype passwords, they don't accidentally install a rootkit.
Close
Identifies the close of a clause.
Operation
The value of this field can be one of the following:
•
•
•
•
Time Range
Identifies the period of time over which the count value is augmented. For rules that have a Count value greater than one, the Time Range value determines how long the period should be before the count value is reset. For example, you can assume that if no more than three login attempts have occurred over a 10-minute period that counter can be reset.
Usage Guideline: The Time Range value combined with the Count value can affect the operation of your MARS. Each time an event is captured that satisfied a unique instance of an inspection rule, a monitoring session is constructed to track possible future occurrences until either the Count value is reached or the time period expires.
Action
Identifies the action that MARS will take when the rule is fired. Actions are user-defined alerts that include an action name and description, which also doubles at the message text provided in the alert. Each action can combine alert techniques, such as email and syslog. Each alert technique can have multiple values. For example, an action can generate two emails, a page, and a SNMP trap. Each rule can have multiple such actions. Alerts can be constructed using one or more of the following techniques:
Note
•
•
•
•
•
•
Working Examples
The examples in this section demonstrate the use of variables, in particular, how to use variables to detect Deny patterns.
Note
Note
Example A: Excessive Denies to a Particular Port on the Same Host
Figure 4-3 Rule for Excessive Denies to a Particular Port on the Same Host
In this example, the rule fires when 100 of the specified events occur from any source IP address to the same destination IP address, and the destination port numbers are identical.
Example B: Same Source Causing Excessive Denies on a Particular Port
Figure 4-4 Rule for Same Source Doing Excessive Denies on a Particular Port
In this example, the rule fires when 100 of the specified events occur that have the source IP address, any Destination IP address, and identical destination port numbers.
Example C: Same Host, Same Destination, Same Port Denied
Figure 4-5 Rule for Same Host, Destination, Same Port Denied
In this example, the rule fires when 20 of the specified events occur that have the same source and destination addresses, and identical destination port numbers.
Working with System and User Inspection Rules
Navigate to the Inspection Rules page by clicking the Rules tab.
You can perform the following actions with inspection rules:
•
•
•
•
•
•
Note
Note
This section contains the following topics:
•
Change Rule Status—Active and Inactive
The MARS correlation engine continuously tests only active rule criteria against incoming events to identify incidents. Inactive rules do not consume resources used for realtime operations.
To change the status of a rule, follow these steps:
Step 1
Step 2
Step 3
The selected rules are made inactive if active, and active if inactive, and are displayed on a different page.
Step 4
Duplicate a Rule
Duplicating a rule creates a new rule that is a copy of an existing system or user inspection rule. You can edit all of the fields of a duplicate rule, but only the Source IP, Destination IP, and Device fields of a system inspection rule. The original rule is left unchanged after duplication.
To duplicate a rule, follow these steps:
Step 1
Step 2
The name of duplicated rule is the name of the original rule extended with a timestamp of when the original was duplicated (for example, System Rule: Client Exploit - Sasser Worm Copied: 05.10.05/16:54:21). The name can be changed by editing the duplicate rule.
Editing a Rule
You can edit rules with inline editing, or with the rule wizard. To edit inline, you click the argument to edit. The rule wizard is invoked by selecting a rule to edit then clicking Edit. The rule wizard begins with the Rule Name field and progresses through each subsequent field.
Note
This section contains the following topics:
•
•
Edit a Rule with Inline Editing
You can perform inline editing to rules from the Incidents Detail page, or from the Inspections Rules page.
To edit a rule with the Inline Editing, follow these steps:
Step 1
The edit page for the selected field appears.
Step 2
Step 3
Step 4
If no parentheses are required, just click Submit.Step 5
Edit a Rule with the Rule Wizard
The Rule Wizard can only be invoked from the Inspections Rule page.
To edit a rule with the Rule Wizard, follow these steps:
Step 1
Step 2
Step 3
•
•
•
•
Step 4
Step 5
Tip
Step 6
Step 7
Note
Add an Inspection Rule
Note
To add a user inspection rule, follow these steps:
Step 1
Step 2
Step 3
Step 4
Figure 4-6 User Inspection Rule Wizard Form
The following numbers correspond to the numbers shown in Figure 4-6.
1.
2.
3.
4.
5.
6.
7.
8.
up icon, or the Not Equal
up icon.
9.
10.
Step 5
Step 6
•
•
•
Step 7
Figure 4-7 Clicking the Activate button
Note
Working with Drop Rules
Navigate to the Drop Rules page by clicking the Rules > Drop Rules tabs.
Drop rules instruct the MARS to either drop a false positive completely from the appliance, or to keep it in the database. On the Drop Rules page, you add, edit, duplicate, activate an inactive rule, or inactivate an active rule. Inactive rules do not fire.
Note
While working with drop rules is similar to working with inspection rules, it is not identical.
This section contains the following topics:
•
Change Drop Rule Status— Active and Inactive
Note
Step 1
Step 2
When you change the status to inactive, the rule displays only on the inactive rules page.
Step 3
Duplicate a Drop Rule
Note
Step 1
Step 2
After duplicating a rule, you can edit the duplicate without altering the original.
Edit a Drop Rule
Note
Step 1
Step 2
Step 3
Step 4
Note
Add a Drop Rule
Note
Step 1
Step 2
Step 3
Figure 4-8 Drop Rule Creation Form
The following numbers correspond to the numbers as shown in Figure 4-8:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Step 4
Step 5
Step 6
Figure 4-9 Clicking the Activate button
Note
Setting Alerts
You have two options for learning about rules that have fired:
•
•
You use actions to provide instructions to MARS on the second method.
Using alerts associated to rules, you can alert a particular person, group, or system that a particular rule has fired. The roles and groups you can choose are determined by the information you have entered in User Management. See Green-field, Multi-box Deployment, page 1-6 for more information.
Configure an Alert for an Existing Rule
Step 1
Step 2
Step 3
Step 4
Step 5
•
•
•
Note
•
Note
Step 6
Step 7
•
•
Step 8
Step 9
Step 10
Note
Rule and Report Groups
This section contains the following topics:
•
•
•
•
•
•
•
Rule and Report Group Overview
Note
Grouping rules and reports helps you by speeding access to those particular rules and reports relevant to your immediate task. You can create groups, or use the groups provided with CS-MARS (System groups). Groups act as filters to limit the display of rules, reports, and incidents in the CS-MARS HTML interface. All groups can be modified or deleted.
CS-MARS provides more than 100 system rules and 150 system reports. You can add more by creating custom rules and reports and by performing periodic software updates. A rule or report group contains, as members, a particular subset of all rules or reports. Usually, rules or reports within the same group have related functions (such as, reconnaissance activities, server attack, etc.). When you select a group from a dropdown filter, only those rules and reports that are members of that group are displayed on the page. When you select a rule group on the Incidents page, only those incidents related to the rules of the selected group display. You can also use report and rule groups when constructing queries.
For instance, there are at least 16 system rules that detect suspicious network access events and incidents, and 15 system reports to report this information. CS-MARS provides a system rule group and a system report group named "Access" that can filter the Inspection Rules, Incidents, and Report pages to display only those rules and reports related to monitoring access events (such as password attacks), thereby eliminating the need to search for the pertinent rules and reports within the complete rule and report pages or dropdown lists. CS-MARS provides system rule and report groups as listed in Table 4-2.
Global Controller and Local Controller Restrictions for Rule and Report Groups
Global Controller and Local Controller rule and report groups have the following restrictions:
•
•
•
•
•
Note
The following behaviors should also be noted:
•
•
•
•
Adding, Modifying, or Deleting a Rule Group
This section details how to operate upon rule groups.
This section contains the following topics:
Add a Rule Group
To add a rule group, follow these steps:
Step 1
Figure 4-10 Inspection Rules Page
Step 2
The Add Group dialog box appears, as shown in Figure 4-11.
Figure 4-11 Add Group Dialog Box
Step 3
Step 4
Tip
Step 5
The selected rules appear in the lefthand pane of the dialog box. To remove a rule from the group, highlight the item in the lefthand pane and click Remove.
Step 6
The new rule group name appears in the Group dropdown filter on the Inspection Rules page, as shown in Figure 4-12. In this example, the new rule group name is "Example Group." Because it is a user-created rule group, the rule group name appears without the prefix "System." You can also click Cancel to return to the Inspection Rules page without creating a new rule group.
Figure 4-12 New Rule Group Appears on the Dropdown List of the Inspections Rules Page
Modify a Rule Group
To edit a rule group, follow these steps:
Step 1
Step 2
Step 3
The Add Group dialog box appears, as shown in Figure 4-11. The rule group name appears in the Name field, and the included rules appear as selected rules in the lefthand pane of the dialog box.
Step 4
Step 5
Delete a Rule Group
To delete a rule group, follow these steps:
Step 1
Step 2
Step 3
The Delete Group dialog box appears listing the rules in the group to be deleted. You are prompted to confirm deletion.
Step 4
The rule group no longer appears in the Group drop-down filters on the Incident and Inspection Rules pages.
Adding, Modifying, or Deleting a Report Group
This section details how to operate upon report groups.
This section contains the following topics:
Add a New Report Group
To add a report group, follow these steps:
Step 1
Figure 4-13 Reports Page
Step 2
The Add Group dialog box appears, as shown in Figure 4-14.
Figure 4-14 Add Report Group Dialog Box
Step 3
Step 4
Tip
Step 5
The selected reports appear in the lefthand pane of the dialog box. To remove a report from the group, highlight the item in the lefthand pane and click Remove.
Step 6
The new report group name appears in the Group dropdown list display filter on the Report page, as shown in Figure 4-15, and on the Query Page. Because it is a user-created report group, the report group name appears without the prefix "system."
Tip
Figure 4-15 The New Report Group Appears on the Dropdown Filter of the Report Page
Modify a Report Group
To modify a report group, follow these steps:
Step 1
Step 2
Step 3
The Add Report Group dialog box appears, as shown in Figure 4-14. The report group name appears in the Name field, and the reports that are in the report group appear in the lefthand pane of the dialog box.
Step 4
Step 5
Delete a Report Group
To delete a report group, follow these steps:
Step 1
Step 2
Step 3
The Delete Report Group dialog box appears listing the reports in the group to delete. You are prompted to verify deletion.
Step 4
The report group no longer appears in the report group dropdown lists on the Report and Query pages.
Display Incidents Related to a Rule Group
To display incidents that occur from the firing of rules in a specific rule group, follow these steps:
Step 1
Step 2
The Incidents page displays only those incidents that occurred from rules firing in the selected rule group.
Figure 4-16 Rule Group on Incidents Page
Create Query Criteria with Report Groups
To create queries from report groups, follow these steps:
Step 1
Step 2
Only the reports that belong to the report group are displayed in the Select Report dropdown list, as shown in Figure 4-18.
Figure 4-17 Selecting A Report Group to Make a Query
Figure 4-18 Selecting a Report Within the Report Group to Make a Query
Step 3
The Query criteria are automatically populated per the selected report.
Use Rule Groups in Query Criteria
To populate the Rule field of the Query Event Data bar using rule groups, follow these steps:
Step 1
Step 2
The Filter by Rule dialog box appears as shown in Figure 4-19.
Step 3
The list of rules will display only those rules in the selected rule group.
Figure 4-19 Rule Group Used to Populate Rule Criterion in Query
Step 4
Step 5
The selected items appear in the lefthand pane of the Query dialog box.
Tip
Step 6
The selected rules appear in the Rules field of the Query Event Data bar.
