Are you new to SIEM?
Are you trying to write a Correlation Rule in SIEM and don’t know where to start?
Are you stuck with several jargons from the SIEM Administrator guide?
If your answer is “YES” to any one of the above questions, please continue.

Rules are the staple ingredient for any SIEM tool or Technology. A Rule is nothing but a set of logical instructions for a System to follow before it determines What to do and What not to do. As we all know, SIEM is a passive system. All it does is a pattern matching of the Logs received and follows the instructions on what to do (trigger) and what not to do (Not Trigger). This pattern matcher is also called as Correlation Rules or Real time Rules. These Correlation Rules are nothing but “your visualization of how an attack would look in an IT Infra”.

Generally, Rule Writing or Rule Development is a process similar to SDLC.
It all starts with the Requirements Phase.
Requirement Phase: In this phase, the Rule Author should collect the exact requirements of putting a rule in place. This requirements should also tell what is the “Intent” of the rule. It also captures the Response such a Rule Trigger would elicit. It is at this Requirements Phase, where the “visualization” actually starts. Remember, without a goal your Rules will not mean anything.

Once you gather the requirements, you enter into the Design phase.
Design Phase: In the design phase, you do the rough skeletal layout of the rule itself. Things like,

• What logs to use for creating this specific rule?
• What log attribute is more suitable for rule trigger?
• What are the various attributes to collect/represent?
• What type of rule to write?
• What type of alerting to be configured? (Read Email, SNMP Traps, Dashboard Trigger, Response Action etc)

are laid out in this phase. This is the Most crucial phase. When it comes to Selecting Rule Types, you need to know what are all the available features from your SIEM tool or Technology. Generally as an All-Purpose guide, I would broadly classify the rules for any SIEM tool or Technology into the following:

1. Single Event Rule – If Condition 1, 2, 3 up to N match, trigger. Typically used rule type as it is straight forward pattern matching of Event Type, Event ID, IP etc.
2. Many to One or One to Many Rules – If a Condition matches and One Source Several Targets or One Target Several Sources scenarios are in play
3. Cause and Effect Rules or “Followed by” Rules or Sequential Rules – If Condition A matches and leads to Condition B. This will typically we a “Scan Followed with an Exploit” type scenarios, “Password Guessing Failure followed by Successful login” type scenarios etc.
4. Transitive Rules or Tracking Rules – If Condition A matches for Attacker to Machine A and within some time, Machine A becomes the Attacker for Machine B (again matching Condition A). This is typically used in Worm/Malware Outbreak Scenarios. Here, the Target in the first event becomes the Source in the second event.
5. Trending Rules – These rules are tracking several Conditions over a time period, based on thresholds. This happens in DoS or DDoS Scenarios.

In the design phase, the selection of the above happens. If this Rule Type selection is messed up here, you will have to revisit the Requirements phase again. Hence it is important to understand and choose wisely.

Now that we have got the requirements and the design out, we can move to the Development phase.
Development Phase: This is where we actually write the rule. Remember, once the logical understanding is there for the Conditions required to match (generally using Boolean Operators), writing a Rule is very simple and straightforward (of course you need to know the SIEM Tool Menus to do so)

Finally, Testing Phase and Deployment Phase follow. Testing is critical to validate the logic involved in the Rule. Simulating the Rule Conditions in Development Environment/Testing Environment will help to iron out the Chinks in the Rule.

Finally, Post Implementation Phase kicks in.
Post Implementation Phase: Once the rule is implemented, we need to manage them. By manage, I mean ensure that the rule is tightened based on feedback from Security Analysts. This may involve adding additional conditions to the rule, whitelisting, Threshold adjustments, etc. This is what makes the rule better and efficient in achieving the “INTENT”. This is typically based like a “Waterfall Model” where you keep going back to the rule again and again to tune it according to the exact needs.

Finally, Rule Refresh Phase is another phase I would like to add in the mix. This is a stage where the Rules you put in place may no longer be applicable, or may have become obsolete and have to be replaced by better rules. Periodic clean up of old/obsolete rules is also one of the best practices in the world of SIEM Rules.

Indeed Rules Rule init??

 [pdf]Save as PDF[/pdf]