Click here to expand

    Understanding correlation

    What is correlation?

    Correlation is the process of identifying a sequence of multiple events, across one or more devices, which are all related, and form a single large incident. The main reason correlation is so useful is because, in many cases, the individual events may not seem suspicious on their own, but when taken in relation to the other events, a larger picture emerges which points to a potential security incident.

    For instance, the two events "employee logs on to Device A" and "employee logs on to Device B" seem perfectly normal.

    However, "same employee logs on to two different devices (Device A and Device B) at almost the same time" may indicate a possible account sharing incident.

    What is a correlation rule?

    A correlation rule is a pattern or a template used to relate multiple logs and identify a security incident. The rule specifies a series of events that make up a larger incident, the time window between events, and specific conditions if any. The following illustrates the various parameters that can be specified in a correlation rule:

    • Correlation rule: A correlation rule is an ordered sequence of network actions.
    • Actions: An action corresponds to a network log. It contains several fields with unique values such as username, device name, and so on.
    • Time window between actions: Each action has to follow the previous action within a specified time window.
    • Threshold for an action (optional): A single action may have to occur several times continuously for a specific rule to hold true. A threshold can be specified for the minimum number of repetitions that need to be observed within the specified time window.
    • Filters for an action (optional): Conditions can be imposed on the fields within each action, with the use of filters.

    For more information on constructing a correlation rule using these parameters, see Constructing custom correlation rules.

    Example:

    Correlation Rule:Brute force

    A brute force attack occurs when an attacker tries to gain access to a device in your network, by trying several logon credentials until one succeeds. It is characterized by several failed logons on a device, followed by a successful logon:

    General pattern: Failed logon -> Failed logon -> Failed logon -> (...) -> Successful logon (all within a few minutes, to the same device)

    Specific pattern: At least 10 failed logons to a single device within 2 minutes -> (within the next 1 minute) -> Successful logon to the same device

    The rule can thus be configured as below:

    Action 1: Failed logon - an employee fails to log on to a network device.

    • Threshold: This action should occur a minimum of 10 times within 2 minutes.
    • Filters: The device name should be the same for all occurrences of Action 1.

    Time window between Action 1 & Action 2: 1 minute

    Action 2: Successful logon - an employee logs on to a network device.

    • Threshold: None.
    • Filters: The device name should be the same as the device name from Action 1.

    Comparison between correlation rules and alert profiles

    • A correlation rule specifies one or more events, occurring on one or more devices. An alert profile can only specify a single event, from a single device type.
    • A correlation rule provides more power than an alert profile in defining a scenario. As a correlation rule can include more than one event, it allows you to specify the ordering of the events, time windows between events, and make use of various conditions.
    • Threshold limits can be specified in both correlation rules and alert profiles. However, while a correlation rule can check that a specific field's value is the same throughout all repetitions of an action, an alert profile cannot.

    Best practices for correlation

    • Correlation is a memory intensive process. If you enable the correlation engine, be sure to enable/create rules only for your most important business use cases.
    • Before creating a new rule, ensure that the same rule cannot be created as an alert profile instead. Please configure your use case as an alert profile instead of a correlation rule, if your answer is "yes" to all items in the below checklist:
      • Your use case consists of only one action.
      • You only need to specify the devices to which the use case is applicable, and don't need to check for a specific value for other fields (like username).
      • In case you specify a threshold value for the action, you don't need to check for a constant field value for any field (username, device name, etc.).
    • Periodically review the logic for your correlation rules. If any rule is generating too many false positives, you can adjust the rule parameters to reduce them.

    To know more about correlation, check out the following pages:

    1. Managing correlation rules
    2. Session activity
    3. Viewing last 10 incidents
    4. Creating custom correlation rules

    Some examples

    Correlation Rule : Excessive application crashes (Windows)

    A series of application crashes on a device over a short time-frame may point to a faulty device. Further, this check should not be applied to a specific device named "Device-1234" as it is used for application crash testing purposes and may generate too many false positives.

    General action flow: Application crash -> Application crash -> (...) -> Application crash (all within few hours on a single device, not applicable to Device-1234)

    Specific action flow: At least 5 application crashes on a single device within 180 minutes (except for Device-1234)

    The rule can thus be configured as below:

    Action 1: Application crash - an application crashes on a Windows device.

    • Threshold: This action should occur a minimum of 5 times within 180 minutes.
    • Filters:
      • The device name should be the same for all occurrences of Action 1.
      • The device name should not equal Device-1234.

    Correlation Rule: Possible ransomware activities (Windows)

    A ransomware attack typically progresses with a newly started process modifying several files on a network devices (in order to encrypt them). It can be identified with a process being started, shortly followed by multiple file modifications.

    General action flow: Process started -> File modified -> File modified -> (...) -> File modified (all within a few minutes, on the same device)

    Specific action flow: Process started -> (within the next 5 minutes) -> At least 15 file modifications on the same device, by the same process

    The rule can thus be configured as below:

    Action 1: Windows Process started - a process is started on Windows.

    • Threshold: None.
    • Filters: None

    Time window between Action 1 & Action 2: 5 minutes

    Action 2: File modified - a file is modified on a Windows device.

    • Threshold: 15 times within 30 minutes.
    • Filters:
      • The device name should be the same for all occurrences of Action 2.
      • The process name should be the same for all occurrences of Action 2.
      • The device name should be the same as the device name from Action 1.
      • The process name should be the same as the process name from Action 1.

    Don't see what you're looking for?

    •  

      Visit our community

      Post your questions in the forum.

       
    •  

      Request additional resources

      Send us your requirements.

       
    •  

      Need implementation assistance?

      Try onboarding

       
    Get download link