Hi, thanks so much for the detailed response. I will study your recommendations in order to improve the rule engine. My concerns are about the CPU/memory usage. This feature requires a deep research and it has implications at a very technical level.
I will let you know when we improve something related with the rule engine. Thanks. Regards. On Tuesday, March 7, 2017 at 12:35:12 AM UTC-8, InfoSec wrote: > > Hello Jesus, > > Following is the design recipe for an *advanced* OSSEC correlation engine. > > The engine is to have the following capabilities: > i) Look forward and look back: Wait a certain time for next events, > -or- look back a certain time for previous events. > ii) Conditions based on the content of decoded fields. > iii) More than one condition can be specified simultaneously. > iv) Boolean logic (at least the basic AND, OR, NOT) can be used in > conditions. Add regex to provide a further boost in capabilities. > v) Stickiness: multiple occurrences of events with a field content that > matches (or does not match) that of the previous event in the sequence. > Ex: Look for multiple occurrences of same events with same > IP/different port, or different IP/same port. > vi) Generate a new custom event with a predefined alert level when a > correlation level is matched. > vii) Alert by e-mail (&/or SMS) when a correlation level is matched. > > *Example*: > Correlation Trigger: > - Rule Level 1: X occurrences of event A matching one or more conditions > within a specified timeout period. > Can be a single occurrence, at which time the Level 1 timeout becomes > irrelevant, level 2 timer kicks in. > - Rules Level 2: Within XX seconds of matching Level 1 -or- in the XX > seconds preceding matching of Level 1, look for: > - Branch A - XX occurrences of: > - Event B with 1 or more conditions relating to Level 1; -and- > - Event C with 1 or more conditions relating to Level 1; -or- > - ... > - Rules Level 3: Within XX seconds of matching Level 2 Branch A > -or- in the XX seconds preceding matching Level 2 Branch A, look for: > - Branch C - XX occurrences of: > - Event D with 1 or more conditions relating to higher-level > events in this tree; -and- > - Event E with 1 or more conditions relating to higher-level > events in this tree; -or- > - ... > *OR* > - Branch D - XX occurrences of: > - Event F with 1 or more conditions relating to higher-level > events in this tree; -and- > - Event G with 1 or more conditions relating to higher-level > events in this tree; -or- > - ... > *OR* > - Branch B - XX occurrences of: > - Event H with 1 or more conditions relating to Level 1; -and- > - Event I with 1 or more conditions relating to level 1; -or- > - ... > - Rules Level 3: Within XX seconds of matching Level 2 Branch B > -or- in the XX seconds preceding matching of Level 2 Branch B, look for: > - Branch E - XX occurrences of: > - Event J with 1 or more conditions relating to higher-level > events in this tree; -and- > - Event K with 1 or more conditions relating to higher-level > events in this tree; -or- > - ... > *OR* > - Branch F - XX occurrences of: > - Event L with 1 or more conditions relating to higher-level > events in this tree; -and- > - Event M with 1 or more conditions relating to higher-level > events in this tree; -or- > - ... > > Conditions for Branches at the same correlation level must be *mutually > exclusive*. > > Example: if a condition for Branch A is 'audit success', for Branch B it > would be 'audit failure'. An event can be an audit success, or an audit > failure, *it cannot be both*. So at level 2 and below, the correlation > engine logic must branch to *only one Branch at a given level*. There can > be NO overlap between Branches at the same level. It is the responsibility > of the individual designing the correlation logic to ensure the sanity of > the logic behind it. Within a Branch, it is OK if more than one rule > matches. > > Level 3 comes below Level 2 Branch A, and another Level 3 may come below > Level 2 Branch B. Since Branch A and Branch B are mutually exclusive, > Branch C and Branch D at level 3 could be the same under branch A and > Branch B. Following the same principles, level 4 comes below level 3, > etc... As many levels as necessary can be defined. > > Such an engine would allow alerting to: > - Suspicious low and slow activity that attempts to remain below the > security monitoring radar -- provided one knows what to look for. > - Scenarios with exponential growth in network connections (such as a > worm infection spreading). > - Scenarios where a rapid recurrence of specific events occurs on hosts > (such as a ransomware infection). > - Network footprinting: scans for a specific destination port on > multiple destination IPs. > - Network footprinting: scans for a wide range of destination ports on a > single destination IP. > - Dictionary attacks: repeated authentication failures from same source > targeting the same account name for all occurrences. > - Dictionary attacks: repeated authentication failures from same source > targeting a different account name for each occurrence. > > - When a correlation level is matched, if within the specified timeout > period (forward or backward) all the branches for the > level below do not match, remove from correlation. > - A match at any level may need to trigger an email alert and/or create a > new correlation engine generated event. > - Correlation engine generated events may be used to trigger other > correlations. > - Correlation engine generated events may be used in other correlations. > > Almost *any* suspicious activity use case could be modeled in an engine > that has the capabilities detailed above. The logic can be simple (single > level) or convoluted (as many levels and branches as one wishes to put in > it). > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
