AlienVault Unified Security Management™ Solution

Complete. Simple. Affordable

Correlation Reference Guide

DC-00163 Edition 01 Copyright© 2015 AlienVault. All rights reserved. Page 1 of 18

 How to Use This Document
Event Correlation is a key process performed by the AlienVault Unified Security ManagementTM
(USMTM) Server. This document explains how it works. It first describes what Correlation is and why
it is important, followed by a comparison between Correlation and Cross Correlation. Then it
explains how to work with Correlation Directives, a set of correlation rules, and Cross Correlation
rules using the AlienVault USM web interface.
 About Correlation
 About Correlation Directives
 About Cross Correlation Rules

For customizing Correlation Directives or Cross Correlation rules, refer to Customizing Correlation
Directives or Cross Correlation Rules.

Note: Read the Life Cycle of a Log document to understand the full life cycle of logs, and to
learn where Correlation is performed in AlienVault USM.

About Correlation

What Is Correlation
Correlation is a process performed by the correlation engine on AlienVault USM Server. It identifies
potential security threats by detecting behavior patterns across different types of assets, which
produce disparate yet related events. Correlation links different events, turning data into more
useful information.

Why Does Correlation Matter

Event logs that are received from different systems and processed by AlienVault USM are
important for maintaining security. Logs carry important information such as what your users are
doing, what data is being accessed, how your system and network are performing, and if there are
any security threats or attacks taking place. However, reading raw logs has the following
disadvantages:
 Logs vary from system to system or even from version to version on the same system.
 Logs are usually hard to interpret and not easily readable by humans.
 Logs have limited perspective, because each system sees events from its own perspective.
For example, a network firewall sees packets and network sessions, while an application
sees users, data, and requests. While different systems report logs of similar activities, the
way in which they articulate these activities is quite different.
 Logs are static, fixed points in time, without the full context or sequence of related events.

DC-00163 Edition 01 Copyright© 2015 AlienVault. All rights reserved. Page 2 of 18

 Correlation, performed by the AlienVault USM correlation engine, provides answers to these
challenges, thus putting the received events into full context. Event correlation enables security
analysts and incident responders to:
 Make informed decisions on how to respond to security threats.
 Validate effectiveness of existing security controls.
 Measure and report compliance.
 Detect policy violations.

How Does Correlation Work

AlienVault USM implements two types of correlation, Correlation and Cross Correlation, and they
work differently.

Correlation
Correlation typically associates multiple events, with the same or different event types, from the
same data source. A USM Sensor sends normalized events to a USM Server, where policy
evaluation and risk assessment occur, followed by correlation. The correlation engine connects
these events and applies correlation rules to generate new events with higher priority and/or
reliability values. When such an event is generated, as shown below, the event is re-injected into
the USM Server process as if it was coming from the USM Sensor. It is then subject to policy
evaluation and risk assessment as any other event, but with elevated parameter values. An alarm
will be generated if the calculated risk (asset value * priority value * reliability value / 25) is 1 or
above.

Figure 1. Event Correlation process on USM Server.

DC-00163 Edition 01 Copyright© 2015 AlienVault. All rights reserved. Page 3 of 18

 The decision to connect these events is governed by Correlation Directives, which are one or more
correlation rules defined as logical trees. The following figure shows a high-level example of a
Correlation Directive. This directive is used to detect brute force authentication events by
connecting two types of events, Failed Logins and Successful Login. Based on the number of
occurrences of individual events, the correlation engine can conclude that the event is a case of an
administrator mistyping a password (one failed login attempt followed by a successful login), a
successful brute force attack with low reliability (10 failed login attempts followed by a successful
login), or a successful brute force attack with high reliability (100,000 failed login attempts followed
by a successful login). All these events should come from the same IP address and go to the same
IP address, in order for the directive event to be created. The correlation engine can also take into
account the reputation of source and destination IP addresses, such as country of origin, and
match specific rules only if an event is coming from, or destined to, a host with bad reputation.

Figure 2. Correlation Directive example: detecting brute force attacks.

Cross Correlation
The second type of correlation performed by AlienVault USM is Cross Correlation. Cross
Correlation is used to modify the reliability of an Intrusion Detection System (IDS) event, which
subsequently affects the risk assessment of the event.
Cross Correlation is performed on events with destination IP address defined, and the system will
check if any vulnerability has been identified on that destination. The basic rule for Cross
Correlation is: if the IDS has discovered an attack to an IP address, and a related vulnerability has
been found on the same IP, the reliability of the IDS event will be increased to 10.
The figure below provides an example, where the AlienVault Vulnerability Scanner detected the “IIS
remote command execution” vulnerability on the server, and the AlienVault IDS detected an attack
exploiting that vulnerability on the same server.

DC-00163 Edition 01 Copyright© 2015 AlienVault. All rights reserved. Page 4 of 18

 AlienVault Vulnerability
Scanner

Vulnerability: IIS remote

command execution

USM Sensor

Cross-correlated
event

A server

Attack: WEB-IIS multiple

decode attempt
Attacker
AlienVault IDS

Figure 3. Cross Correlation example: IIS remote command execution.

About Correlation Directives

The correlation engine uses Correlation Directives to connect different events. Each correlation
directive contains at least one correlation rule.

Where to Find Them

AlienVault USM provides a web interface for you to examine, modify, or create new correlation
directives. Within the web interface, navigate to Configuration > Threat Intelligence > Directives.
You will see that AlienVault USM provides over 2,000 built-in directives. More are being added
through feed updates every week.
There are some management options at the upper part of the screen that allow you to work with
correlation directives. The options include:
 New Directive: Click this option to create a new directive from scratch.
 Test Directives: Click this option to test if the correlation engine correctly parses modified
or new directives.

DC-00163 Edition 01 Copyright© 2015 AlienVault. All rights reserved. Page 5 of 18

  Restart Server: Click this option to restart the ossim-server process, not the entire USM
Server. Restart is required after creating new directives or modifying existing ones. The
Restart Server option will become red, indicating that it needs to be done.
 Search a directive name: Use this option to search for specific directives by typing part of
a directive’s name and clicking SEARCH. After performing a search, a CLEAR button will
appear to the right of the SEARCH button. Use the CLEAR option to clear the search input
field in order to display all directives again.

Figure 4. AlienVault USM Correlation Directives main page.

The central part of the screen displays the USM built-in directives. Directives are grouped into
several categories that are explained in the following table:

DC-00163 Edition 01 Copyright© 2015 AlienVault. All rights reserved. Page 6 of 18

 Table 1. USM Correlation Directives categories.

Category Explanation Example

Name

User This category is a placeholder for user created

Contributed and/or modified directives. By default, this
category is empty.

AlienVault This category includes directives that are used AV Attacks, Successful OpenSSL
Attacks to detect various attacks against vulnerable HeartBeat attack
services and applications.

AlienVault This category includes directives that are used AV Bruteforce attack, SSH
BruteForce to detect brute force attacks on services that authentication attack against
require authentication. DST_IP (destination IP)

AlienVault This category includes directives that detect AV Service attack, successful
DoS Denial of Service (DoS) attacks on different denial of service against IIS web
applications and services. server on DST_IP (MS07-041)

AlienVault This category includes directives that are used AV Malware, botnet Koobface
Malware to detect malware. activity detected on SRC_IP
(source IP)

AlienVault This category includes miscellaneous AV Misc, suspicious executable

Misc directives that are used to detect activities that download from a dynamic domain
do not fall into any other category. on SRC_IP

AlienVault This category includes directives that are used AV Network attack, too many
Network to detect network related anomalies and dropped inbound packets from
attacks. DST_IP

AlienVault This category includes directives that are used AV Policy violation, vulnerable
Policy to detect policy violations. Java version detected on SRC_IP

AlienVault This category includes directives that are used AV SCADA attack, Modbus
Scada to detect attacks on industrial supervisory scanning or fingerprinting against
control and data acquisition (SCADA) systems. DST_IP

AlienVault This category includes directives that are used AV Network scan, Nmap scan
Scan to detect scanning activities. against DST_IP

DC-00163 Edition 01 Copyright© 2015 AlienVault. All rights reserved. Page 7 of 18

 How They Are Structured
You can expand each category by clicking the black arrow to the left of the category name to
display the directives within the category. Each directive will have some global properties, one or
more rule(s), the directive info, and (in some cases) a Knowledge Base article assigned with it.

Global Properties
Each correlation directive has the following global properties:
 ID: a unique identifier for the directive. It becomes the Event Type ID when a directive event
is created. The ID of a directive is not displayed in the web interface.
 Name: a meaningful name for the directive. It becomes the name of the directive event or
the alarm.
 Intent, Strategy, and Method: these properties identify what the correlation directive is
trying to detect. They help categorize directive events according to AlienVault USM
Taxonomy.
 Priority: defines the impact of the detected attack and is used in risk calculation of a
directive event. All events generated by the directive will have their priority set to the priority
value of the directive.

Note: Prior to USM version 5.0, the Priority value of built-in directives can only be viewed or
modified after you have cloned the directive. This is changed in USM version 5.0 and above, where
you can see the Priority value below its name.

In the following example, the name of the directive is AV Bruteforce Attack, SSH service
authentication attack against DST_IP. The intent of the directive is Delivery & Attack, the
strategy is Bruteforce Authentication, the method is SSH, and the Priority value is 4.

Expand a Clone a Edit a

directive directive directive Name

Disable a Delete a Intent Strategy Method Priority value

directive directive
Figure 5. Global properties and management options for a correlation directive.

DC-00163 Edition 01 Copyright© 2015 AlienVault. All rights reserved. Page 8 of 18

 More functions are made available through the icons to the left of a directive name. The following
options are available:
 Expand: Click this option to expand a directive in order to observe the rules, directive info,
and the knowledge DB, if any.
 Enable/Disable: Click this option to enable or disable a directive. When the directive is
enabled, a green check mark appears. Click the check mark to disable the directive. When
the directive is disabled, a red cross mark appears. Click the cross mark to disable the
directive. Restart Server is needed when a directive is enabled or disabled.
 Clone: Click this option to clone a directive. A cloned directive is placed into the User
Contributed category where it can be edited.
 Delete: Click this option to delete a directive. This option is only available for User
Contributed directives.
 Edit: Click this option to edit a directive. This option is only available for User Contributed
directives.

Correlation Rules
You can expand a directive to see its rule(s). A rule defines a condition to match incoming events.
Refer to How Does Correlation Work for details.
Each rule is defined by multiple rule attributes. The main attributes are:
 Name: name of the rule. Each rule has its own name within the directive, and they can be
the same.
 Reliability: the reliability value of an event generated based on this rule. It can be an
absolute value from 0 to 10, or a relative value (incremental to the reliability value in the
previous rule). Reliability is used for risk calculation during risk assessment.
 Timeout: the waiting time (in seconds) before the rule expires and the correlation process
using that rule stops. Note that the timeout value for the first rule is always None, indicating
the value cannot be set.
 Occurrence: number of time(s) an event has to occur in order for the rule to match
 From: source IP and port(s) of the events that the rule is trying to match.
 To: destination IP and port(s) of the events that the rule is trying to match.
 Data Source: data source name and ID of the events that the rule is trying to match.
 Event Type: event type ID (SID) of the events that the rule is trying to match. When there
are multiple SIDs specified, the rule will try to match any of them.

The figure below shows one of the built-in directives, AV Network attack, too many dropped
inbound packets from DST_IP, which detects network attacks by observing dropped packets from
any source IP address to a specific destination IP address on the Cisco PIX firewall. There are
three correlation levels (denoted by the black triangles) and four rules (all named Firewall dropped
packets) for this directive. The relationship of the rules is shown via the indentation. Indented rules
have AND relationship while parallel rules have OR relationship. The first rule of the directive is
matched when a single ‘Deny inbound (No xlate) string’ event (SID 106011) is identified by the
cisco-pix data source plugin. And, if three more such events occurred within 10 seconds toward the
same destination, the reliability of the directive event will increase to 4. And, if 5 more such events
occurred within 20 seconds toward the same destination, the reliability of the directive event will

DC-00163 Edition 01 Copyright© 2015 AlienVault. All rights reserved. Page 9 of 18

 increase to 6; or, if 10 more such events occurred within 30 seconds toward the same destination,
the reliability of the directive event will increase to 8. See
To examine which event the SID represents, you cannot directly click the event type ID. Instead,
click the data source name, and then search for the SID in the resulting page, as shown in the
following figure:

Figure 6. Viewing the event type information in a correlation rule.

There are some additional attributes you can use in a correlation rule. If set, together with From,
To, Data Source and Event Type, they serve as filters to narrow down the events that the rule is
trying to match. You can examine these additional attributes by clicking the More button. For the
majority of the built-in directives, additional attributes are not set.

Figure 7. Viewing more attributes used by a correlation rule.

DC-00163 Edition 01 Copyright© 2015 AlienVault. All rights reserved. Page 10 of 18

 The additional attributes are:
 Sensor: the USM Sensor that the events are coming from.
 Protocol: the protocol specified in the event. Accepted values are ANY, TCP, UDP, and
ICMP.
 Sticky different: Attributes in directive rules are sticky by default, which means that when a
new event arrives at the correlation engine, it will be correlated with the previous event if the
event attributes (such as IP address or port number) are the same. However, attributes in a
directive can also be sticky different. When set, an arriving event needs to have a different
value than the previous one in order to be correlated. For example, in port scanning attacks,
if you set the destination port as sticky different, only events with different destination ports
will be correlated for the directive. Accepted values for this attribute are NONE,
PLUGIN_SID, SRC_IP, DST_IP, SRC_PORT, DST_PORT, PROTOCOL, and SENSOR.
 Username: the username specified in the event.
 Pass: the password specified in the event.
 Userdata1 - Userdata8: the user data fields specified in the event.

You can also customize the display of the attributes that are shown in the rules section of a
directive. Click the […] next to the Event Type column. A window will open where you can select
which attributes are displayed in a rule. Add an attribute by clicking the + sign, or remove an
attribute by clicking the – sign. Click SAVE when done or CANCEL to discard changes.

Figure 8. Customizing the display of attributes.

DC-00163 Edition 01 Copyright© 2015 AlienVault. All rights reserved. Page 11 of 18

 Directive Info
The DIRECTIVE INFO section displays information used by AlienVault for compliance mapping
and/or reports. It also lists the alarms this directive has triggered, if any.
The first column on the left lists some addition information (called properties) about the directive,
such as what kind of an attack the directive is supposed to detect. In the figure below, the directive
is supposed to detect when too many packets are dropped, which is classified as a network
anomaly. Therefore, the Net Anomaly property is set to Yes. To clarify, IMP is short for IMPact;
QOS means Quality Of Service; and Infleak is short for Information leak. These properties, when
set, are used in the B & C – Trends section of the Business and Compliance report, one of the built-
in reports in AlienVault USM.

Figure 9. Viewing Directive Info – properties.

You can change the default values of these properties by clicking the EDIT button, choose Yes or
No for each property, then click SAVE. You can also clear all properties by clicking the REMOVE
button.
The next three columns, ISO 27001, PCI DSS 2.0, and PCI DSS 3.0, display compliance
information about the directive, if mapped. This information is then used in the USM reports.
Compliance information of a built-in directive cannot be changed. The following figure displays an
example of a directive that has PCI DSS compliance information.

DC-00163 Edition 01 Copyright© 2015 AlienVault. All rights reserved. Page 12 of 18

 Figure 10. Viewing Directive Info – compliance information.
The last column displays alarms that this directive has triggered. When such alarms exist, the
ALARMS column displays their name, risk, and status. The directive in the example below
triggered an alarm with a risk of 3. The status of the alarm is open, as indicated by the open lock
icon.

Figure 11. Viewing Directive Info - alarm information.

DC-00163 Edition 01 Copyright© 2015 AlienVault. All rights reserved. Page 13 of 18

 Knowledge DB
Some built-in correlation directives also include a link that points to a document in the AlienVault
Knowledge Base (Configuration > Threat Intelligence > Knowledge Base). The Knowledge Base
contains vendor provided information on a vulnerability or knowledge from the information security
community. It provides suggestions to security analysts and incident response teams on where to
look for information about an activity or an attack. To read the document linked to the directive,
expand the KNOWLEDGE DB option, and click the title of the document.
The following directive, which detects an exploit in Internet Explorer, includes a Knowledge Base
document that describes the exploit and where to find more information about the exploit.

Figure 12. Viewing Knowledge DB.

How to Customize Them

There may be situations where you want to create your own directives, or modify the built-in
correlation directives. Refer to Customizing Correlation Directives or Cross Correlation Rules for
details.

DC-00163 Edition 01 Copyright© 2015 AlienVault. All rights reserved. Page 14 of 18

 About Cross Correlation Rules
The correlation engine uses Cross Correlation rules to connect IDS events and vulnerabilities.

Where to Find Them

AlienVault USM also has a web interface for you to examine, modify, and create new Cross
Correlation rules. From within the web interface, navigate to Configuration > Threat Intelligence >
Cross Correlation.
At the upper part of the screen you will notice some management options that allow you to work
with Cross Correlation rules. The options include:
 NEW: Click this option to create a new Cross Correlation rule.
 MODIFY: Click this option to modify an existing Cross Correlation rule. You have to select
the rule by highlighting it first.
 DELETE SELECTED: Click this option to delete an existing Cross Correlation rule. You
have to select the rule by highlighting it first.

Figure 13. AlienVault USM Cross Correlation main page.

The rest of the page displays the built-in Cross Correlation rules in AlienVault USM, with each line
representing one rule. The four columns: Data Source Name, Event Type, REF Name and REF

DC-00163 Edition 01 Copyright© 2015 AlienVault. All rights reserved. Page 15 of 18

 SID Name, display the events and vulnerabilities that the rule correlates. The first two columns
represent IDS events while the other two columns represent vulnerabilities.
At the bottom of the page, you can navigate to the next pages to see more rules. You can also use
the search icon to display the search box. You will be able to search by Data Source Name, Event
Type, Ref Name, and Ref SID Name.

Figure 14. Searching for a Cross Correlation rule.

How They Are Structured

To see how Cross Correlation rules are structured, it is easiest to use an example. Unlike
correlation rules, Cross Correlation rules do not have names. To view a correlation rule, double
click the corresponding line or highlight the line and click MODIFY.
The following Cross Correlation rule is matched when IDS detects a failed login event for the ‘sa’
account on the Microsoft SQL server (as indicated in the EVENT TYPE field), where the account
has a blank password (as indicated in the REFERENCE SID NAME field). Events triggered in this
case would indicate that someone tried to login to the system using a password, while the system
itself was configured with a blank password.

Figure 15. Viewing a Cross Correlation rule.

How to Customize Them

There may be situations where you want to create your own Cross Correlation rules, or modify the
built-in rules. Refer to Customizing Correlation Directives or Cross Correlation Rules for details.

DC-00163 Edition 01 Copyright© 2015 AlienVault. All rights reserved. Page 16 of 18

 Even though the web interface gives an impression that you can cross-correlate events from any
data source with those from any other data source, in practice you can only correlate IDS events
with vulnerabilities that are detected by AlienVault Vulnerability Scanner.

Creating a Cross Correlation Rule

To create a new Cross Correlation rule,
1. Click NEW.
2. Select the Data Source Name, such as snort as shown in the example below.
3. Select the Reference Data Source Name, such as nessus-detector in the example.
4. Select the Event Type of the data source entered in step #2. For example, snort: “MySQL
root login attempt”.
5. Select the Reference SID Name of the reference data source entered in step #3. For
example, nessus: MySQL weak password.
6. Click CREATE RULE. Or, click BACK if you want to discard the changes.
This custom rule would be matched if AlienVault IDS Engine detected MySQL root login attempt to
a host that has MySQL weak password vulnerability.

Figure 16. Creating a Cross Correlation rule.

Modifying a Cross Correlation Rule

To edit an existing Cross Correlation rule,
1. Locate the desired Cross Correlation rule and click on it. The entire row will change to light
blue.
2. Click MODIFY.
3. Change any of the four fields as needed.
4. Click SAVE RULE to save the changes. Or, click BACK if you want to discard the changes.

Deleting a Cross Correlation Rule

To delete a Cross Correlation rule,
1. Locate the desired Cross Correlation rule and click on it. The entire row will change to light
blue.
2. Click DELETE SELECTED.

DC-00163 Edition 01 Copyright© 2015 AlienVault. All rights reserved. Page 17 of 18

 Important: Use this button with caution because the web interface will not ask you to
confirm the deletion.

DC-00163 Edition 01 Copyright© 2015 AlienVault. All rights reserved. Page 18 of 18