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.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to