Correlation is done in 3 different ways:
- Correlation of different events (Logical Correlation)
- Correlation of events and vulnerabilities (Cross Correlation), and
- Correlation of events and operating systems-services (Inventory Correlation)
Correlation can lower the number of events from millions a day to less than a dozen by checking each one of them before reporting it. It gives intelligence to the Console as it can report more human readable abstract and complex alarms.
RIMICI “ONE Source” Security Operations Center’s logical correlation engine approach is to check every event. As we can have millions of alerts a day we can’t rely on them unless we can check them, the correlation engine will look for evidences or symptoms to prove if the attack is real or a false positive.
1. Logical Correlation
Logical Correlation’s main purpose is to look for evidences in order to check if a security event is true or a false positive. This is a main subject in security systems this days.
We can have millions of events a day but almost all of them false positives. We need automatic processes to check if an attack is really going on.
RIMICI “ONE Source” Security Operations Center Logical Correlation engine features:
- Hybrid source, accepting both pattern input from detectors and indicator input from monitors
- Recursive architecture as the output will be events which can be correlated again by other Correlation Directives
- Hierarchical distributed architecture, as we can define n levels of correlation in a distributed topology
- Flexible object oriented and time ranges definitions for each directive stage
Logical Correlation is implemented by Correlation Directives which implement a tree of logical condition nodes. This kind of structure is also known as an AND/OR tree, usually used in artificial intelligent systems.
When a node condition is matched, the correlation engine will jump to the first children, if it’s not matched will jump to the next “brother” (node on the right with the same father). This implements the “AND” operation in the Y axis and the “OR” operation in the X axis (An example will make this easier to understand later)
Reliability variable grows as the correlation engine advances through nodes matching the conditions: the more evidences we have, the more possibilities we have that the attack is true.
Each directive defines a new event type (which inherits it’s name from the Directive) and has an specific priority, as most of the times they define wider patterns than the events that trigger them. This new event will be a normal RIMICI “ONE Source” Security Operations Center event (probably with a high reliability) which will be sent to the collector as if it came from any external agent, creating a recursion path where different levels of correlation can be implemented.
2. Cross Correlation
Cross Correlation allows to prioritize or deprioritize events for which we know we are (or we are not) vulnerable by crossing information from Detectors and Vulnerability Scanners.
RIMICI “ONE Source” Security Operations Center Cross Correlation depends on specific Vulnerability Databases and Detector Cross Correlation Tables for each detector.
3. Inventory Correlation
Launched attacks are always targeted to specific OS and/or services.
Inventory Correlation checks if the attacked machine uses that OS and/or Service for which the attack is launched. If it uses them, we will be sure that a risk exists, but if not, we can confirm that the event is a false positive attack.
This type of Correlation depends on the accuracy of the Inventory, RIMICI “ONE Source” Security Operations Center has manual and automatic Inventory capacities as explained in Automatic Inventory and Inventory Management.