Behavior-based Correlation

Threat Defender uses behavior-based correlation, also called inline real-time correlation, to analyze traffic and correlate events across multiple traffic flows. The single-pass correlation and policy engine of Threat Defender correlates current traffic flows as well as historical information from previous flows. Based on the detected behavior, granular multi-level policy rules can be created and dynamically executed.

Attacks are often hard to detect as attackers hide in seemingly harmless communication to prevent detection by network security systems, such as next-generation firewalls. The only way to detect such threats is to analyze the behavior of the network to spot subtle changes in the communication. Once relationships between seemingly unrelated events are discovered, they can be analyzed further to determine if they contain any threats or abnormal behavior which may indicate that the network is under attack.

1. The Approach of Threat Defender

Threat Defender correlates current traffic flows with historical information from previous flows. It expands the policy language to track attributes of communication events. This means correlation takes place inline, inside the policy engine. Data is correlated in real time, i.e. the moment it is generated. Reactions to any identified threats are immediate and applied to the flow that triggered them.

To achieve meaningful behavior-based correlation, the policy and correlation engine enriches each flow with relevant information extracted from the data, such as basic layer 2-4 attributes but also information on layer 7 protocols and applications, IPS events and IoC/IoA events.

The behavior-based correlation of Threat Defender is implemented using an in-memory database. This database contains event tracking tables, which store combinations of attributes and track the properties of communication events across traffic flows and over time. The expanded policy engine queries these tables and inserts entries. The entries in event tracking tables have individual retention times that are specified by the administrator. They are removed automatically when this timeout expires. This enables event tracking tables to track changes in the behavior of assets/users over time.

Using behavior-based correlation via event tracking tables requires at least two rules: One rule adds a pair of flow attributes (such as IP/MAC addresses, URLs, IDS hits, etc. ) to the table. Another rule evaluates the table: A counting condition counts the number of entries with the same attribute. A distinct counting condition counts entries with a particular timestamp. Rules can also query if a specific attribute pair is contained in the table; based on the result rule actions are carried out or not.

With behavior-based correlation, Threat Defender gives you the tools to build complex scenarios of multi-staged policies to detect similar or related events in all network flows, both in real time and historically (limited to the retention time of the event tracking tables). All scenarios are evaluated for each network flow and no traffic can pass Threat Defender without being handled by the correlation engine.

2. Example Workflow

The following is a simplified example workflow using behavior-based correlation:

  • Threat Defender tracks the network traffic using event tracking tables. You can specify what kind of traffic will be tracked by the indicating traffic source and destination, used protocols and applications, etc.
  • Threat Defender evaluates the entries in the event tracking table by comparing traffic to the events (an event is a combination of one primary attribute and its secondary attributes) stored in the table or by counting the number of events and/or attributes.

  • If Threat Defender identifies the specific behavior that is described by the correlation scenario, it performs the defined actions, such as adding the concerned hosts to a dynamic network object.

  • You can then enforce further rules on the hosts in the dynamic network object. For example, you can block their traffic, limit their bandwidth, isolate them from the remaining network, etc.

Additional References:

results matching ""

    No results matching ""