Rules written using the Many to One Rule Type are one of those things about SSIM that many security administrators and analysts would like to understand better but don’t. Why? Because this rule type is far too confusing.
So here is my humble attempt to help you understand this rule type.
Let us first look at the fields available on the Conditions Tab. Many to One is one rule type where nothing is grayed out. All the fields on the Condition Tab are available for use.
Event Criteria: This field is used to identify the events. The event characteristics that you define here must be met by each and every event that forms part of the event pattern(series) you want to detect.
Tracking Field: This field is used to decide whether an event needs to be added to an existing conclusion. For example if you have two conclusions based on three wrong passwords on two separate servers and there is a new wrong password event, you would want that event to be added to one of those existing conclusion provided it is on one of those servers. You can leverage this filed to ensure this. What this field does is that whenever an event matches the criteria for a rule, it is checked for the criteria mentioned tracking fields for any existing conclusion for that rule and is added to the same conclusion only if there is a match
Event Count: This field specifies the number of events that must occur within the time frame that is specified in the Span settings in order for the rule to trigger an incident.
Span: This field is used to specify the time frame that is allotted for the number of events that are specified in the Event Count field to occur.
One-Many Field: This field describes the elements that must remain consistent across each event in order for the event to be correlated. What this means is that from second event onward even if the event meets all the criteria specified in the Rules Criteria, it will not be considered for correlation unless the value of the ‘event field’ specified in the One-Many Field matches the value of the corresponding field the earlier events.
Many-One Field: This field describes the elements that must be different for each event in order for the event to be correlated. What this means is that from second event onward even if the event meets all the criteria specified in the Rules Criteria, it will not be considered for correlation unless the value of the ‘event field’ specified in the One-Many Field does not match the value of the corresponding field of each of the earlier events.
Confusion! Confusion! Let us look at an example.
The above rule is for detection of Account Guessing Attack. Before we look at the rule let us first understand what pattern is this rule is looking for. It wants to identify if there are two failed login attempts using different user names on the same server within 10 minutes.
Now how do we achieve this using Many to One Rule Type. We define the event criteria using derived fields. Mechanism must contain Login and Intrusion Outcome ID is equal to fail. This will be the case for all failed login attempts irrespective of the type of device. We also specify two events in 10 minutes using the Event Count and Span fields. Finally we specify IP Destination Address in the One-Many Field. Remember this field needs to be consistent across all events. So using this field we ensure that we are looking at failed login attempts on the same server. We also specify Target Resource (value contains user name for login events) in the Many-one Field. Remember this field must be different across all event. So using this setting we ensure that the user name must be different in the two events.
Good so you think you are starting to understand this better. Let us look at one more example.
You want to write a rule to detect port scan i.e. Single Source trying to connect to single destination on 10 different ports within a span of 10 minutes.
Looking at the rule, Event Criteria is used to filter out false positive sources. One-Many Field states that the source and destination IP addresses must be consistent across all events. Event Count and Time Span define that we are looking for 10 events within a span of 10 minutes. Many-One Field states that the destination port needs to be different for each event-Remember we want to catch a source trying to connect to 10 different ports of a destination.
Great so now you understand the Many to One Rule Type well. Let us look at a couple of more examples before we wrap up.
The Password Guessing Attack looks for two(defined in time span) failed login(defined in event criteria) attempts on the same server(defined in One-Many Field) using the same user name (defined in One-Many Field using Target Resource) within a span of 10 minutes (defined in span field).
All this is fine but what about the Unique Event ID in Many-One Field. Well this is a trick of the trade. You put Unique Event ID in the Many-One Field when your rule requirements do not need anything speicific to be different across multiple events because this field is always Unique.
The Internal Port Sweep looks for a single (defined in One-Many Field) Internal source (defined in event criteria) trying to connect to 10(defined in event count) different destination (defined in Many-One field) on the same port (defined in One-Many Field) within a span of 5 minutes (defined in Span).
Hopefully this article improved your understanding of Many to One Rule Type and helps to edit these rules as per your requirements as well as write new Many to One rule type rules.