Appologies for the lack of posts this week, but i have been working hard on a NAC Appliance Project with Satisnet.
Rules can be in one of 3 states as described below:
You have an inspection rule that matches a specific IPS alarm. The rule has a single offset that looks for that alarm and has a count of 1. The time range for the rule is 5 minutes. The rule has never fired before and so currently is in the “ready state” and checked every 5 seconds for readiness to fire. At midnight, CSMARS starts receiving that IPS alarm every 3 minutes. A total of 5 alarms are sent and they are exactly the same every time (same tcp 5-tuple).
12:00:00AM. 1st IPS alarm received.
12:00:03AM. Rule checked for readiness to fire. FIRE! Rule state advanced to 5 minute throttle.
12:03:00AM. 2nd IPS alarm received.
12:05:03AM. Rule checked for readiness to fire. FIRE! Rule state still 5 minute throttle.
12:06:00AM. 3rd IPS alarm received.
12:10:03AM. Rule checked for readiness to fire. FIRE! Rule state advanced to 10 minute throttle.
12:09:00AM. 4th IPS alarm received.
12:12:00AM. 5th IPS alarm received.
12:20:03AM. Rule checked for readiness to fire. FIRE! Rule state reset to “Ready”.
Other Important facts:
• Despite a barrage of conflicting information from Cisco, rules appear to work off events and not sessions. This comes directly from Cisco TAC and jives with observed behavior. I can easily create a single session that fires the same rule twice. Each incident will refer to the same session but will have a time range from a subset of the events contained in the session.
• The timing of the readiness checks described above is somewhat vague, but predictable. It is ABOUT 5 seconds, 5 minutes, and 10 minutes.
• Within a 3 second period, if there are multiple events of the same event type (whether or not they are from different devices) belonging to the same session (same flow/five tuple), only the first event will be considered in the rule.
I do have great pleasure though, in providing another Guest Article by Matthew Helman, who works for a fortune 250 financial services company in the US
Inspection Rule Throttling
The inspection rules are truly the heart and soul of the CSMARS system. Each inspection rule represents a particular threat and defines the conditions that, when met, are the realization of that threat. Unfortunately, there doesn’t seem to be detailed technical documentation that describes how the inspection rules work. Conceptually, they’re a relatively easy thing to understand and are described well enough. However, knowing how the various criteria, in particular time range, affect the firing of rules is necessary in order to understand and predict rule behavior. The information below is not complete, but it does at least provide a baseline for validating that CSMARS is working as expected. Specifically, it does not address the complexities of a typical rule, with multiple offsets and using the “special” variables.
Inspection Rule Throttling
The inspection rules are truly the heart and soul of the CSMARS system. Each inspection rule represents a particular threat and defines the conditions that, when met, are the realization of that threat. Unfortunately, there doesn’t seem to be detailed technical documentation that describes how the inspection rules work. Conceptually, they’re a relatively easy thing to understand and are described well enough. However, knowing how the various criteria, in particular time range, affect the firing of rules is necessary in order to understand and predict rule behavior. The information below is not complete, but it does at least provide a baseline for validating that CSMARS is working as expected. Specifically, it does not address the complexities of a typical rule, with multiple offsets and using the “special” variables.
Rules can be in one of 3 states as described below:
- Ready state. The rule is not currently being throttled. It will be checked every 5 seconds. It will fire if new matching events have been received in the last 5 seconds. Once the rule fires, the state automatically advances and throttling starts.
- 5 minute throttle state. The rule is checked every ~5 minutes. It will fire if new matching events have been received in the last 5 minutes. State advances if rule has fired twice while in this state. State resets to “ready” if no matching events in last "time range from rule".
- 10 minute throttle state. The rule is checked every ~10 minutes. It will fire if new matching events have been received in the last 10 minutes. State resets to “ready” if no matching events in last "time range from rule"
You have an inspection rule that matches a specific IPS alarm. The rule has a single offset that looks for that alarm and has a count of 1. The time range for the rule is 5 minutes. The rule has never fired before and so currently is in the “ready state” and checked every 5 seconds for readiness to fire. At midnight, CSMARS starts receiving that IPS alarm every 3 minutes. A total of 5 alarms are sent and they are exactly the same every time (same tcp 5-tuple).
12:00:00AM. 1st IPS alarm received.
12:00:03AM. Rule checked for readiness to fire. FIRE! Rule state advanced to 5 minute throttle.
12:03:00AM. 2nd IPS alarm received.
12:05:03AM. Rule checked for readiness to fire. FIRE! Rule state still 5 minute throttle.
12:06:00AM. 3rd IPS alarm received.
12:10:03AM. Rule checked for readiness to fire. FIRE! Rule state advanced to 10 minute throttle.
12:09:00AM. 4th IPS alarm received.
12:12:00AM. 5th IPS alarm received.
12:20:03AM. Rule checked for readiness to fire. FIRE! Rule state reset to “Ready”.
Other Important facts:
• Despite a barrage of conflicting information from Cisco, rules appear to work off events and not sessions. This comes directly from Cisco TAC and jives with observed behavior. I can easily create a single session that fires the same rule twice. Each incident will refer to the same session but will have a time range from a subset of the events contained in the session.
• The timing of the readiness checks described above is somewhat vague, but predictable. It is ABOUT 5 seconds, 5 minutes, and 10 minutes.
• Within a 3 second period, if there are multiple events of the same event type (whether or not they are from different devices) belonging to the same session (same flow/five tuple), only the first event will be considered in the rule.
Posts
No comments:
Post a Comment