Alien vault _policymanagement

Copyright© 2014 AlienVault. All rights reserved.
AlienVault Unified Security Management™ Solution
Complete. Simple. Affordable
Policy Management Fundamentals

AlienVault™, AlienVault Unified Security Management™, AlienVault USM™, AlienVault Open Threat Exchange™, AlienVault OTX™,
Open Threat Exchange™, AlienVault OTX Reputation Monitor™, AlienVault OTX Reputation Monitor Alert™, AlienVault OSSIM™ and
OSSIM™ are trademarks or service marks of AlienVault.

DC-00160 Edition 00 Copyright© 2014 AlienVault. All rights reserved. Page 3 of 66
TABLE OF CONTENTS

Policy Management Fundamentals...............................................................................1

Table of Contents ...........................................................................................................3

1.
Introduction..............................................................................................................5

2.
Policies Overview ....................................................................................................5

2.1.
What is an Event?...................................................................................................... 5

2.2.
What is a Policy? ....................................................................................................... 5

2.3.
Policies Related to External Events vs. System Events ............................................ 6

2.4.
External Event Policy Interface .................................................................................. 7

2.5.
System Event Policy Interface ................................................................................... 8

3.
Creating or Modifying a Policy ...............................................................................9

3.1.
Policy Conditions for External Event Policies .......................................................... 10

3.1.1.
Source ................................................................................................................11

3.1.2.
Destination..........................................................................................................12

3.1.3.
Source Ports.......................................................................................................13

3.1.4.
Destination Ports ................................................................................................14

3.1.5.
Event Types: Data Source Groups.....................................................................15

3.1.6.
Event Types: Taxonomy.....................................................................................16

3.1.7.
Sensors...............................................................................................................17

3.1.8.
Reputation ..........................................................................................................18

3.1.9.
Event Priority ......................................................................................................20

3.1.10.
Time Range .......................................................................................................21

3.2.
Policy Conditions for System Event Policies............................................................ 22

3.2.1.
Event Types........................................................................................................23

3.2.2.
Reputation ..........................................................................................................24

3.2.3.
Event Priority ......................................................................................................26

3.2.4.
Time Range ........................................................................................................27

3.3.
Policy Consequences .............................................................................................. 28

3.3.1.
Actions................................................................................................................29

3.3.2.
SIEM...................................................................................................................30

3.3.3.
Logger.................................................................................................................31

3.3.4.
Forwarding..........................................................................................................32

4.
Managing Policies..................................................................................................33

4.1.
View Existing Policies .............................................................................................. 33

4.2.
Policy Groups........................................................................................................... 36

4.3.
Policy Order ............................................................................................................. 37

5.
Configure Actions..................................................................................................39

5.1.
Configure Action to Send Email ............................................................................... 40

5.2.
Configure Action to Execute External Program ....................................................... 41

5.3.
Configure Action to Open Ticket .............................................................................. 42

5.4.
Use Keywords in Actions ......................................................................................... 43

6.
Configure Policy to Discard Events.....................................................................46

6.1.
Create DS Group to Specify Data Source ............................................................... 46

6.2.
Discard Events......................................................................................................... 50

7.
Configure Policy to Send Emails Triggered by Events......................................52

7.1.
Create Action to Send Email.................................................................................... 52

7.2.
Create Policy Conditions for External Events .......................................................... 54

7.3.
Create Action as Policy Consequence for External Events ..................................... 56

7.4.
Create Policy Conditions for Directive Events ......................................................... 59

7.5.
Create Action as Policy Consequence for Directive Events .................................... 63

1. INTRODUCTION
Use this document to understand policies and actions in AlienVault. Policies are used to
influence event processing, filter events that don't need to be processed, and deal with
events that result in noisy or false positive alarms. Understanding policies and actions is
critical in managing AlienVault and tuning it to meet your security needs.
2. POLICIES OVERVIEW
2.1. WHAT IS AN EVENT?
An event is a single line of data collected from an external system (e.g. Windows servers,
firewalls) or produced by AlienVault components (e.g. USM Server, USM Sensor) that
describe a particular system level or user level activity that took place. For example, security
events collected from a Windows server will describe a user attempting to authenticate to a
Windows server. Events from a firewall, such as Cisco ASA or Fortinet Fortigate, describe
communication from a system within the customer network either to another system in the
network or a system external to the network. These events are used to help security
analysts understand what is happening in a network and to identify potential security threats
that can lead to a security incident.
There are two types of events to consider in AlienVault: external events and system events.
External events are collected by USM sensors from external systems and devices. They are
sent from the USM Sensor to the USM Server for correlation and the USM Logger for long-
term storage. System events are created by the USM Server using correlation rules.
2.2. WHAT IS A POLICY?
Policies are AlienVault USM configuration objects that allow you to configure how the
system processes events once they arrive at the AlienVault USM Server or Logger. The
policies include conditions and consequences. Conditions determine which events are
processed by the policy. Consequences define what will happen when events match the
specified conditions. Policies are used widely within USM to alter the default behavior of
USM when events are captured and sent to the USM Server or USM Logger. By default, all
collected events will be processed and stored by both components. Common examples of
how policies are used include:
• Perform risk assessment and correlation without storing events in the Server
database. This is typically done with firewall events, but could be done with any
type of event. It is common to process certain firewall events for use in correlation,

but you may not want to store them in the USM Server database due to the
volume. You will likely want to store the events in the USM Logger, however, for
long-term retention and compliance reasons.
• Store events in the USM Logger and not correlate the events. This is typically
done if the events in question have no directives or cross-correlation rules to
process them. If there is no reason to send them to the USM Server for correlation,
you can configure a policy to skip the USM Server and just store the data in the
USM Logger.
• Correlate events and forward them to another USM Server without storing
them. In larger, distributed deployments, the USM components can be tiered to
allow for additional scale. You may want to correlate the events on a child server
and send them to a higher-level USM server or Federation Server to further
correlate or store them. You can use policies to set up the event forwarding.
• Reduce false positive alarms. As you collect more events from different external
systems, you may run into a scenario that is causing the USM Server to generate
more alarms than you want. You can use policies to filter the events to reduce the
number of alarms that are created.
• Send an email notification. Policies can be used to trigger on alarms to send a
notification to an administrator or others to inform them of the alarm. Policies can
be configured with an email action to automate the notification.
• Temporarily hide true positive alarms. On occasion, you may want to disable the
generation of alarms based on a particular set of events to avoid alarm
regeneration or noise until analysis, corrective action, or preventative actions are
taken. Use policies to limit the creation of alarms temporarily.
• Increase the importance of a specific event. On occasion, you may wan to
closely monitor a specific IP address or a specific port. You can use policies to
generate alarms for these specific scenarios without writing a correlation rule.
These use cases represent just examples of how to use policies to manage and control
event processing within AlienVault USM. As you learn more about policies and how they are
used to interact with events, you will find them to be a valuable and powerful tool.
2.3. POLICIES RELATED TO EXTERNAL EVENTS VS. SYSTEM EVENTS
Policies can be created for both external events and system events from within the policy
management interface in the web UI. From within the web UI, navigate to Configuration >
Threat Intelligence > Policy to access the policies. From here you can create new policies,
modify existing policies, delete policies, enable/disable policies, duplicate policies, and
manage policy groups.

You will notice that the policy view is separated into two halves. The upper half of the policy
management web UI allows you to manage policies related to external events. The bottom
half of the policy management web UI allows you to manage policies related to system
events.
Figure 1: Policy list interface
No policies are created by default within AlienVault USM. You will need to create policies as
needed. When you create a new policy or modify an existing policy, policy conditions and
consequences must be defined to tell AlienVault what to evaluate and how to react.
Starting with AlienVault USM version 4.12, a third policy group, AV Default policies, has
been introduced. It contains one rule named AVAPI filter, which filters events from the
AlienVault avapi user. This policy is disabled by default.
2.4. EXTERNAL EVENT POLICY INTERFACE
You can use the policy management interface to create and manage policies related to
external events. This includes all events collected from external systems via the sensors.
Policy groups are used to organize policies into logical groups. After initial installation, a new
AlienVault system will have a default policy group called “Default Policy Group: Default
Group Policy objects.” This policy group includes no default policies, but can be used to
create policies related to external events.
The policy group includes a set of management options that allow you to manage policies
within the policy group. They include:
External events
System events

• New. Click this button to create a new policy.
• Modify. Select an existing policy in the list and click this button to modify that
policy.
• Delete Selected. Select an existing policy in the list and click this button to delete
it. You will be asked to confirm the deletion.
• Duplicate Selected. Select an existing policy in the list and click this button to
duplicate it. A duplicate of the selected policy will be created. You will need to
provide a unique name, update the policy as desired, and save the policy.
• Reload Policies. After the external policies have been modified or reordered, they
need to be reloaded so the Server and Logger are aware of the changes. Click this
button to reload the policies. This forces a restart of the service used to manage the
policies.
• Enable/Disable Policy. Select a policy in the list and click this button to enable or
disable it. You will be prompted for confirmation before the change is made.
2.5. SYSTEM EVENT POLICY INTERFACE
You can use the policy management interface to create and manage policies related to
system events. These are events that are generated by AlienVault. After initial installation, a
new AlienVault system will have a default policy group called “Policies for events generated
in server.” This policy group includes no default policies, but can be used to create policies
related to system events.
Similar to external events, this section of the user interface also includes several
management options. They include:
• New. Click this button to create a new policy.
• Modify. Select an existing policy in the list and click this button to modify that
policy.
• Delete Selected. Select an existing policy in the list and click this button to delete
it. You will be asked to confirm the deletion.
• Duplicate Selected. Select an existing policy in the list and click this button to
duplicate it. A duplicate of the selected policy will be created. You will need to
provide a unique name, update the policy as desired, and save the policy.
• Reload Policies. After the external policies have been modified or reordered, they
need to be reloaded so the Server and Logger are aware of the changes. Click this
button to reload the policies. This forces a restart of the service used to manage the
policies.

• Enable/Disable Policy. Select a policy in the list and click this button to enable or
disable it. You will be prompted for confirmation before the change is made.
3. CREATING OR MODIFYING A POLICY
The policy configuration interface can be opened by clicking the New button for either an
external policy or system policy. The web UI will open the policy configuration interface. To
see the policy configuration interface for an existing policy, click on the policy name. The
interfaces for an external policy and system policy are a bit different, but follow the same
basic design principles.
Across the top of the policy configuration interface, you can create or modify several
settings:
• Policy Rule Name. This is the name given to the policy.
• Active. This toggle allows you to determine if the policy is Active or not. By
selecting “Yes”, the policy is enabled. By selecting “No”, the policy is disabled. This
will be reflected in the Policy List view when saved.
• Policy Group. Select the policy group with which you want the policy to be
associated. To change the default selection, use the drop-down menu to select
another policy group.
Policies are composed of conditions and consequences. Conditions determine which events
are processed by the policy. Consequences define what will happen to events matching the
specified conditions.

Figure 2: Policy configuration interface
3.1. POLICY CONDITIONS FOR EXTERNAL EVENT POLICIES
Policy conditions determine which events are processed by the policy. You can configure
policy conditions for external event policies by using the Default Policy Group section of the
policy management interface.
To configure policy conditions, open the policy configuration interface. The policy
configuration interface can be opened by clicking the New button in the Default Policy
Group section. The web UI will open the policy configuration interface. To see the policy
configuration interface for an existing policy, click on the policy name.
To select a condition that you want to configure, you have two options. Each option
produces the same result.
• On the top half of the policy configuration interface, you can click in the yellow or
green area under SOURCE, DEST, SRC PORTS, DEST PORTS, or EVENT TYPES
to open the configuration area for that condition.
• On the bottom half of the policy configuration interface, you can click on any of the
vertical words SOURCE, DESTINATION, SOURCE PORTS, DEST PORTS, or
EVENT TYPES to open the configuration area for that condition.

Figure 3: Configure policy conditions
3.1.1. SOURCE
Source defines assets, asset groups, networks, or network groups as the source IP address
of the event. By choosing a source, you’re determining that only events that come from that
source will be processed by this policy.
To add a source, click on Assets, Asset Groups, Networks, or Network Groups. You can
also choose ANY as the source condition if you want the policy to apply to any source. For
example, if you wanted to create a policy that affected any events that affect a particular
destination, regardless of their source, you would choose ANY as the source policy
condition.
You can also configure objects on the fly, by clicking the INSERT NEW HOST?, INSERT
NEW NET?, or INSERT NEW NET GROUP? link. In each case, a configuration window will
open. Click Save in that window when you have finished the configuration tasks in that
window.
Here are a few ways you might make use of source as a policy condition:

• If you want to establish a policy for events from a single asset, use the source
condition to select that asset.
• If you want to use several hosts in different subnets for the source, create an asset
group containing those hosts and use this asset group object as source in the policy
condition.
• If you want to establish a policy with all of the assets in a subnet as the source, use
a network defined in the system to include an entire subnet as the source policy
condition.
• If you want to establish a policy with several networks as the source, use a network
group that contains those networks as the source policy condition.
Figure 4: Source as policy condition
3.1.2. DESTINATION
Destination defines assets, asset groups, networks, or network groups as the destination IP
address of an event. By choosing a destination, you are determining that only events that
have that specific destination will be processed by this policy.
To add a destination, click on Assets, Asset groups, Networks, or Network groups. You
can also choose ANY as a destination condition. For example, if you wanted to create a
policy that affected all events that come from a particular source, regardless of their
destination, you would choose ANY as the destination policy condition.
You can also configure objects on the fly, by clicking the INSERT NEW HOST?, INSERT
NEW NET?, or INSERT NEW NET GROUP? link. In each case, a configuration window will
open. Click Save when you have finished the configuration tasks in that window.
Here are a few ways you might make use of a destination as a policy condition:
• If you want to establish a policy for events destined for a single asset, use the
destination condition to select that asset.

• If you want to use several hosts in different subnets for the destination, create an
asset group containing those hosts and use this asset group object as a destination
in the policy condition.
• If you want to establish a policy with all of the assets in a subnet as the destination,
use a network defined in the system to include an entire subnet as the destination
policy condition.
• If you want to establish a policy with several networks as the destination, use a
network group that contains those networks as the destination policy condition.
Figure 5: Destination as policy condition
3.1.3. SOURCE PORTS
Source port defines the TCP/UDP source port of an event.
To add an object as a source port, click on the object in Port Groups. You can also choose
ANY as a source port condition to accept all ports.
You can also configure port group objects on the fly, by clicking the INSERT NEW PORT
GROUP? link. A configuration window will open. Click Save when you have finished the
configuration tasks in that window.
Here are a few ways you might make use of source ports as a policy condition:
• If you want to establish a policy for events sourced from certain TCP or UDP port,
use the source port condition to select that port.
• If you want to establish a policy for events sourced from certain ports, create port
group and add desired TCP or UDP ports to the port group. For instance, you could
create an HTTP port group for TCP ports 80 and 8080, assuming that your web
servers are sending HTTP responses sourced from these two ports.

Figure 6: Source ports as policy condition
3.1.4. DESTINATION PORTS
Destination port defines the TCP/UDP destination port of an event.
To add an object as a destination port, click on the object in Port Groups. You can also
choose ANY as a destination port condition to accept all ports.
You can also configure port group objects on the fly, by clicking the INSERT NEW PORT
GROUP? link. A configuration window will open. Click Save when you have finished the
configuration tasks in that window.
Here are a few ways you might make use of destination ports as a policy condition:
• If you want to establish a policy for events destined for certain TCP or UDP port,
use the source port condition to select that port.
• If you want to establish a policy for events destined for certain ports, create port
group and add desired TCP or UDP ports to the port group. For instance, you could
create HTTP port group for TCP ports 80 and 8080, assuming that customers are
connecting to your web servers, which are listening on ports 80 and 8080.

Figure 7: Destination ports as policy condition
3.1.5. EVENT TYPES: DATA SOURCE GROUPS
Event Types define the types of events that will be processed by this policy. This function
uses Data Source Groups to define the data sources for events, or uses Taxonomy to
define the types of events. In this section, we will review how to use of Data Source Groups.
A data source is any application or device that generates information which can be collected
and analyzed by AlienVault USM. AlienVault USM includes a number of integrated data
sources that monitor traffic and assets to detect events, while also accepting events from
external data sources, such as network devices, network firewalls, and antivirus
applications.
A data source group is a collection of different data sources. Once assembled in a data
source group, you can then easily incorporate that collection into a policy. For instance, you
could match all events from the Cisco ASA firewall and the Palo Alto firewall by adding
these two data sources to one data source group. As another example, the predefined
Document files data source group combines all file related event types belonging to snort
data source into one data source group.
To add a data source group to event type, select the desired data source groups from the
DS Groups list by checking the box to the left of the group’s name. Note that you will first
need to uncheck ANY if that box is checked. To see which data sources are included in a
data source group, or to edit the list of included data sources, click on the name of the group
to display the View DS Group window.
You can also add data source groups on the fly, by clicking the INSERT NEW DS GROUP?
link. You can then add different data sources to the data source group or even choose only
certain event types for a selected data source.
You can also choose ANY as a data source group for event type. For example, if you
wanted to create a policy that affected all events that come from a particular source,
regardless of the type of event, you would choose ANY as the event types policy condition.

This is a predefined list of DS groups:
• Document files: Microsoft Office or PDF documents detected in network transit.
• Executable files: Executable files detected in network transit.
• Get IP request: Get public IP request from external web service.
• Network anomalies: Network anomalies signatures.
• Sensitive data: Sensitive data detected in network transit.
• Snort HTTP INSPECT: Snort HTTP Inspect preprocessor signatures.
• Snort IDS sigs: Snort IDS signatures.
• Suspicious DNS: DNS queries to suspicious TLDs.
• Tor network: Access from or to Tor network exit nodes
Figure 8: Event types—data source group as policy condition
3.1.6. EVENT TYPES: TAXONOMY
Event Types define the types of events that will be processed by this policy. This function
uses Data Source Groups to define the data sources for events, or uses Taxonomy to
define the types of events. In this section, we’ll review the use of Taxonomy.
Taxonomy is a classification system for security events. AlienVault open source security
event taxonomy is a classification system based on 20 main categories and 240
subcategories.
To use Taxonomy, click the Taxonomy button. You can then use the Product Type,
Category, and Subcategory taxonomy parameters for creating a taxonomy condition. The
Category options change based on which Product Type is selected. Similarly, the
Subcategory options change based on which Category is selected.

In the example below, all system emergency events for the firewall product type will be
matched. You need to click the ADD NEW button to add selected taxonomy parameters as
taxonomy conditions.
Figure 9: Event types—taxonomy as policy condition
3.1.7. SENSORS
To see additional options under policy conditions in a policy for external events, click the
ADD MORE CONDITIONS button in the POLICY CONDITIONS section. Click on Sensors
to add it as a condition.
Figure 10: Additional policy conditions
The Sensors policy condition defines the USM Sensor that is collecting and normalizing an
event. This allows user to specify which sensor or number of sensors are the source for the
events identified for processing by the policy. For example, in distributed deployment, you
might want to create a policy for events received from only the sensors that are installed at
remote locations.
To add a sensor, click on the sensor in the Sensor list.

You can also choose ANY as a sensor condition.
Figure 11: Sensors as policy condition
You can also insert a new sensor on the fly, by clicking the INSERT NEW SENSOR? link. A
new window opens where you can add a new sensor as a policy condition.
Figure 12: Insert new server
3.1.8. REPUTATION
ADD MORE CONDITIONS button in the POLICY CONDITIONS section. Click on
Reputation to add it as a condition.

To add a reputation condition, select the desired Activity, Priority, Reliability, and
Direction in the Reputation Parameters section and then click ADD NEW. Reputation
defines the reputation of either source or destination IP address of an event. By selecting a
direction, you can specify whether the policy should match the reputation of the source or
destination IP address.
By selecting an activity, you can specify malicious activity of an IP address that the policy
should match. The following options are available:
• Advanced Persistent Threats
• Command and Control Server
• Malicious host
• Malware
• Malware distribution
• Malware domain
• Malware IP
• Scanning Host
• Spamming
Each IP address, present in the OTX database, has a priority and reliability values. The
priority value specifies the priority of malicious activity of the IP address. Priority is a number
between 1 and 10, where 1 specifies low priority and 10 specifies high priority of the
reported IP address reputation. Reliability specifies the accuracy of an IP address being
reported as malicious. Reliability is a number between 1 and 10, where 1 specifies low
reliability and 10 specifies high reliability of the reported IP address reputation.

For instance, by using reputation as a policy condition you can filter events coming from a
botnet command and control server with high priority and high accuracy of reported
reputation.
Figure 14: Reputation as policy condition
10
3.1.9. EVENT PRIORITY
ADD MORE CONDITIONS button in the POLICY CONDITIONS section. Click on Event
Priority to add it as a condition.
Each event, detected by AlienVault USM, has an assigned priority value. It specifies the
importance of the event, and defines how urgently the event should be investigated. Priority
is a numeric value between 0 and 5, where priority event 0 has no importance, and priority
event 5 is very important.

Each event also has an associated reliability. Reliability specifies the likelihood that the
event is accurate. Reliability is a numeric value between 0 and 10, where 0 means that the
event is unreliable (False Positive), and 10 means that a real attack is in progress.
Event Priority allows you to choose which events are processed by the policy based on the
priority and reliability of the event. For example, you may want to create a policy that applies
only to events with a priority of 5 and a reliability of 3.
To add an event priority condition, select the desired Priority and Reliability in the Events
Parameters section and then click ADD NEW.
Figure 16: Event priority as policy condition
3.1.10. TIME RANGE
ADD MORE CONDITIONS button in the POLICY CONDITIONS section. Click on Time
Range to add it as a condition.

Time Range allows you to set a time window for matching events. Only events that occur
during the specified time range will be processed by the policy.
You can set the time range on a daily, weekly, or monthly basis, or you can create your own
custom time range. In the example below, the time range specifies weekdays between 7
a.m. and 6 p.m. in the US Eastern time zone.
Figure 18: Time range as policy condition
3.2. POLICY CONDITIONS FOR SYSTEM EVENT POLICIES
Policy conditions determine which events are processed by the policy. You can configure
policy conditions for system event policies by using the “Policies for events generated in
server” section of the policy management interface.
To configure policy conditions, open the policy configuration interface. The policy
configuration interface can be opened by clicking the New button in the “Policies for events
generated in server” section. The web UI will open the policy configuration interface. To see
the policy configuration interface for an existing policy, click on the policy name. You can
configure policy condition in the lower part of the screen.

Figure 19: Configure policy conditions
3.2.1. EVENT TYPES
Event Types define the types of events that will be processed by this policy. For policies
affecting system events, this function uses Data Source Groups to define the data sources
for events.
A data source is any application or device that generates information which can be collected
and analyzed by AlienVault USM. AlienVault USM includes a number of integrated data
sources that monitor traffic and assets to detect events, while also accepting events from
external data sources, such as network devices, network firewalls, and antivirus
applications.
A data source group is a collection of different data sources. Once assembled in a data
source group, you can then easily incorporate that collection into a policy.
To use directive events as a data source group event type, select Directive events by
checking the box to the left of the group’s name.
You can also add data source groups on the fly, by clicking the INSERT NEW DS GROUP?
link. You can then add different data sources to the data source group or even choose only
certain event types for a selected data source.
Configure policy conditions

For policies in the “Policies for events generated in server”
policy group, you can only include data source groups that are
comprised of system events.
Figure 20: Event type as policy condition for system events
3.2.2. REPUTATION
ADD MORE CONDITIONS button in the POLICY CONDITIONS section. Click on
Reputation to add it as a condition.
To add a reputation condition, select the desired Activity, Priority, Reliability, and
Direction in the Reputation Parameters section and then click ADD NEW. Reputation
defines the reputation of either the source or destination IP address of an event. By

selecting a direction, you can specify whether the policy should match the reputation of the
source or destination IP address.
By selecting activity, you can specify the malicious activity of an IP address that the policy
should match. The following options are available:
• Advanced Persistent Threats
• Command and Control Server
• Malicious host
• Malware
• Malware distribution
• Malware domain
• Malware IP
• Scanning Host
• Spamming
Each IP address, present in the OTX database, has a priority and reliability values. The
priority value specifies the priority of a malicious activity of the IP address. Priority is a
number between 1 and 10, where 1 specifies low priority and 10 specifies high priority of the
reported IP address reputation. Reliability specifies the accuracy of an IP address being
reported as malicious. Reliability is a number between 1 and 10, where 1 specifies low
reliability and 10 specifies high reliability of the reported IP address reputation.
For instance, by using reputation as a policy condition you can filter events coming from a
botnet command and control server with high priority and high accuracy of reported
reputation.

Figure 22: Reputation as policy condition
3.2.3. EVENT PRIORITY
ADD MORE CONDITIONS button in the POLICY CONDITIONS section. Click on Event
Priority to add it as a condition.
Each event, detected by AlienVault USM, has an assigned priority value. It specifies the
importance of the event, and defines how urgently the event should be investigated. Priority
is a numeric value between 0 and 5, where priority event 0 has no importance, and priority
event 5 is very important.
Each event also has an associated reliability value. Reliability specifies the likelihood that
the event is accurate. Reliability is a numeric value between 0 and 10, where 0 means that
the event is unreliable (False Positive), and 10 means that a real attack is in progress.
Event Priority allows you to choose which events are processed by the policy based on the
priority and reliability of the event. For example, you may want to create a policy that
applies only to events with a priority of 5 and a reliability of 3.

To add an event priority condition select the desired Priority and Reliability in the Events
Parameters section and then click ADD NEW.
Figure 24: Event priority as policy condition
The Event Priority condition only works for events generated in a USM Server. In AlienVault
USM version 4.14 and alter, a warning message displays if you try to use it in the Default
policy group, AV default policies, or any policy groups created by users of your AlienVault
USM system.
3.2.4. TIME RANGE
ADD MORE CONDITIONS button in the POLICY CONDITIONS section. Click on Time
Range to add it as a condition.
Time Range allows you to set a time window for matching events. Only events that occur
during the specified time range will be processed by the policy.

You can set the time range on a daily, weekly, or monthly basis, or you can create your own
custom time range. In the example below, the time range specifies weekdays between 7
a.m. and 6 p.m. in the US Eastern time zone.
Figure 26: Time range as policy condition
3.3. POLICY CONSEQUENCES
Consequences define what will happen to events matching the specified conditions.
To configure policy consequences for external events, choose “Configuration > Threat
Intelligence > Policy” and click on New in the Default Policy Group pane.
To configure policy consequences for system events, choose “Configuration > Threat
Intelligence > Policy” and click on New in the Policies for events generated in server
pane.
To modify the policy consequences for an existing policy, click on the policy name to open
the policy configuration interface.
Consequences that can be configured are the same for both types of policies.
To select a consequence that you want to configure, you have two options. Each option
produces the same result.
• On the top half of the policy configuration interface, you can click in the yellow or
green area under ACTIONS, SIEM, LOGGER, or FORWARDING to open the
configuration area for that consequence.
• On the bottom left side of the policy configuration interface, click on POLICY
CONSEQUENCES. Next, on the bottom half of the policy configuration interface,
you can click on any of the vertical words ACTIONS, SIEM, LOGGER, or
FORWARDING to open the configuration area for that consequence.

Figure 27: Configure policy consequences
3.3.1. ACTIONS
The Actions section defines actions taken as a consequence of conditions met in the policy.
“Actions” has a specific meaning in AlienVault USM. There are three possible actions that
you can configure:
• Send an email to a preconfigured email address. Note that this capability could
allow you to use an email to send information from AlienVault USM to an external
ticketing system.
• Execute a command to invoke a script on AlienVault USM.
• Open a ticket in the internal AlienVault USM ticketing system.
Section 5 is used to explain Actions settings in detail. Actions
can be configured from the “Insert New Action” link or the
“Action” tab found by navigating to Configuration > Threat
Intelligence > Actions.

Figure 28: Actions as policy consequence
3.3.2. SIEM
The SIEM consequence defines the way events that match the policy conditions are
processed by the AlienVault USM Server.
Here are the possible SIEM settings in policy consequences:
• SIEM: Disables or enables processing of events by SIEM. The possible settings are
Yes or No. The default setting is set to Yes. In almost all cases, you want to use the
power of the SIEM within AlienVault USM to correlate events that arrive at the
server. When you select the Yes option, you can granularly set other SIEM settings
(Set event priority, Risk assessment, Logical correlation, Cross-correlation, SQL
storage). When you select the No option, you disable all other SIEM settings (Set
event priority, Risk assessment, Logical correlation, Cross-correlation, SQL storage)
with one click.
• Set event priority: Each event, detected by AlienVault USM, has an assigned
priority value, which specifies the importance of the event. The priority of an event is
defined within the event definition, but it can be changed using policies if required.
Change the priority by setting a numeric value between 0 and 5, where priority event
0 has no importance, and priority event 5 is very important. The accepted values are
Do not change, or any number from 0 to 5. The default setting is set to Do not
change, which uses the default priority of an event.
• Risk assessment: The process of determining the risk of an event based on an
asset value and type of an event is called risk assessment. This process takes into
account the asset value, event priority, and event reliability. You can enable or
disable risk assessment of events that match a policy by setting the option to Yes or
No. The default setting is set to Yes.
• Logical correlation: AlienVault USM Server performs logical correlation, which is
used to create new events from multiple events provided by detectors and monitors.
Logical correlation is configured using correlation directives, which are defined as

logical trees that combine individual events. Each new event has new priority and
reliability values, as defined by an individual directive. You can enable or disable
logical correlation of events that match a policy by setting the option to Yes or No.
The default setting is set to Yes.
• Cross-correlation: You can enable or disable cross-correlation of events that match
a policy by setting the option to Yes or No. The default setting is set to Yes.
• SQL storage: Events that are detected or generated by AlienVault USM are by
default stored in the SQL database. However, some events are not required or even
desired to be stored in the database. You can enable or disable SQL storage of
events that match a policy by setting the option to Yes or No. The default setting is
set to Yes.
Figure 29: SIEM as policy consequence
3.3.3. LOGGER
The Logger section defines whether events will be stored by the USM Logger, and how
events that are stored will be signed.
The possible Logger settings are Yes or No. The default setting is set to No.
In most cases, you will want to change the setting for Logger to
Yes. Most AlienVault users choose to log events processed by
policies in the USM Logger for analysis, compliance, or
archiving purposes.
When Logger is set to Yes, log files can be signed via either Line or Block.
• Line: Digitally sign every log that comes to USM Logger. This option ensures
immediate protection from log tampering, but is more processing intensive.

• Block: Digitally sign a block of logs every 1 hour or whenever the log file is bigger
than 100 MB. This option may leave a window of opportunity for someone to
tamper with logs before singing them, but is less processing intensive. Block
signing is the most commonly used approach, and meets all typical compliance
requirements.
Figure 30: Logger as policy consequence
3.3.4. FORWARDING
The forwarding section defines whether events will be forwarded to other USM Servers.
In a distributed deployment, a USM Server is set up at each remote location. All USM
Servers in remote locations could communicate with the USM Server at the headquarters to
send normalized events. For this to happen, you would need to set forwarding from the
server at the remote location to the headquarters server. This means that the forwarding
server is enabled generally for a server.
Forwarding that is set in policies overrides forwarding that is configured generally for a
server. The latter configuration is used to forward all events, while policies can be used to
configure forwarding for some events, and to configure exceptions to the general behavior.
For instance, assume that you have configured a remote server to forward all events. By
using policy conditions and disabling the forwarding of events in policy consequences, you
could determine which events will not be forwarded from the remote location’s server to the
headquarters server. In that example, all events will be forwarded except for those that
match the policy conditions.
Possible Forwarding settings are Yes or No. The default setting is set to No. When you
select Yes, you need to select the server to which events should be forwarded.

Figure 31: Forwarding as policy consequence
4. MANAGING POLICIES
4.1. VIEW EXISTING POLICIES
Go to “Configuration > Threat Intelligence > Policy” to view any policies that are configured
on your AlienVault USM Server.
Each policy is listed within a Policy Group.
Figure 32: Policy list
You can move the slider to the right to see additional settings of the configured policies.

Figure 33: Additional settings in policy list
There are two additional buttons at the bottom of policy view for system events: Security
Events process priority threshold and Reorder Policies.
When you drag and drop policies a few times to reorder them, you may accidently end up
with duplicated order IDs. Whenever that happens, clicking on Reorder policies fixes the
IDs.
Figure 34: Reorder Policies button
When you click the Reorder Policies button, you will have to confirm your selection.

Figure 35: Reorder Policies confirmation screen
Refer to section 4.3 to see why policy order is important.
You may influence whether USM will process the event against configured policies by
clicking the Security Events process priority threshold button. If the event's priority is
greater or equal to the configured process priority threshold, USM will process the event,
otherwise not.
Figure 36: Security Events process priority threshold button
Valid values for process priority threshold are from 0 to 5. Default value is set to 0, hence all
the events will get processed against configured policies.

Figure 37: Security Events process priority threshold button
4.2. POLICY GROUPS
Policy groups allow you to group policies for administrative purposes, or to assign policies to
a correlation context. Correlation context defines sensors and the scope of assets, upon
which correlation is performed.
Upon installation AlienVault USM has two preconfigured policy groups. You can create your
own policy groups by navigating to “Configuration > Threat Intelligence > Policy” and
clicking the EDIT POLICY GROUPS button.
Figure 38: “Edit policy groups” button
In the EDIT POLICY GROUPS window, select the NEW button to create a new policy
group.

Figure 39: “Edit policy groups” window
You can choose a name for the policy group and assign this policy group either to the entity
or context.
In the example below, a policy group named “My Policy Group” is applied to the entity
named “My Company”. You could also assign the policy group to the context named “Test
context”.
Entities and contexts can be managed under “Configuration >
Administration > Users > Structure”.
Figure 40: Create policy group
4.3. POLICY ORDER
When an event is being processed, policies are evaluated in order from top to bottom. When
an event matches a rule, the system stops processing that event. Therefore, very specific
and restrictive rules should be defined at the top of the rules list, while generic rules should
be specified at the bottom of the rules list.
The figure below shows an example where 3 policy rules are configured:
• The first rule matches Cisco ASA events with source IP address of 10.128.10.15.
• The second rule matches all Cisco ASA events.

• The third rule matches Cisco ASA events with source IP address of 10.177.16.150.
Because the second rule is very general, it will match all Cisco ASA events. Therefore, the
third rule, which is more specific, will never be evaluated. In order to correctly process
events, the INTERNAL_NMAP rule should be placed before the FIREWALL_EVENTS rule.
Policies can be reordered by dragging the policy and dropping it in the desired place. Note
that you will need to click on Reload Policies for the new policy order to take effect.
Figure 41: Policies order example
You can also reorder policy groups by clicking the arrow icons in the upper right
corner of a policy group.

Figure 42: Prioritize policy groups
5. CONFIGURE ACTIONS
The Actions section defines actions taken as a consequence of conditions met in the policy.
This section describes each of the three possible action options and shows how to use
them.
“Actions” has a specific meaning in AlienVault USM. There are three possible actions that
you can configure:
• Send an email about an event detected by AlienVault USM to a preconfigured email
address. Note that this capability also allows you to use an email to send
information from AlienVault USM to an external ticketing system.
• Execute a command to invoke a script on AlienVault USM.
• Open a ticket in the internal AlienVault USM ticketing system.

To configure actions, navigate to “Configuration > Threat Intelligence > Actions” and click on
the NEW button.
Figure 43: Create new action
5.1. CONFIGURE ACTION TO SEND EMAIL
To configure an action to send an email, select the Send an email message option from
the Type drop-down menu.
You must fill in these fields:
• Name: Specifies the name of the action.
• Context: Specifies the context, to which the action is attached.
• From: Specifies the sender of the email.
• To: Specifies the recipient of the email.
• Subject: Specifies the subject of the email.
• Message: Specifies the content of the email. Note that you can use keywords,
discussed in a later section, to configure the message.
For email delivery to be successful, you need to configure an
email relay server in system details under “Deployment >
Components > AlienVault Center”.
After you configure an action to send email, you have to apply
the configured action as the policy consequence to one of your
policies. This is shown in section 7.

Figure 44: Configure action to send email message
5.2. CONFIGURE ACTION TO EXECUTE EXTERNAL PROGRAM
To configure an action to execute an external program, select Execute an external
program from the TYPE drop-down menu.
You must also define the name of the action and fill in the COMMAND field, which defines
the file path to the script that gets executed when policy conditions are met. A script or a
program resides locally on AlienVault USM. The script is launched from the USM, which has
to have a way to communicate with an external device if it is trying to control it.

Figure 45: Configure action to execute external program
After you configure an action to execute an external program,
you have to apply the configured action as the policy
consequence to one of your policies.
5.3. CONFIGURE ACTION TO OPEN TICKET
AlienVault USM has an internal ticketing system, which can be used to delegate tasks to
other administrator users, and to track investigation progress on specific alarms and events.
To configure an action to open a ticket about events matched by a policy, select Open a
ticket from the TYPE drop-down menu.
You must also define the name of the action and specify the assignment of the ticket in the
IN CHARGE field. You can assign a ticket either to a user or an entity.
In the example below, the ticket is assigned to the user “admin.” If the policy conditions are
met and the action in policy consequences for this policy is set to open the ticket, the user
will find the opened ticket under “Analysis > Tickets” screen.

You can also integrate the AlienVault USM system with an
external ticketing system, which opens a ticket upon receiving
an email from AlienVault USM.
After you configure an action to open a ticket, you have to apply
the configured action as the policy consequence to one of your
policies.
Figure 46: Configure action to open ticket
5.4. USE KEYWORDS IN ACTIONS
When configuring actions, you can use all the information from the events as keywords in
the actions. The figure below shows all possible keywords that can be used in an action.

Figure 47: Event attributes in actions
When an action is executed, the keywords are substituted with their value, which comes
from an event triggering the action.
For example, if you create an action to send an email about a detected alarm to an
administrator, you can include information from the alarm in the email message. The figure
below shows an example of an email message, where SRC_IP, DST_IP, PLUGIN_NAME,
SID_NAME, and RISK keywords from a normalized event are used as parameters in the
email message. These keywords will be replaced with actual values when the action is
triggered.

Figure 48: Use event attributes in email message
You can click an individual attribute to include it in the action,
without actually typing the attribute into the input field.
Similarly, you can include event attributes when executing an external program. In the
example below, an event invokes a script that sends a shun command to a network firewall
to prevent an attacker from making connections through the firewall at the provided IP
address.

Figure 49: Use event attributes in command
6. CONFIGURE POLICY TO DISCARD EVENTS
This section provides a specific example of how to use a Policy.
In this section, you will see how to filter and discard events by creating a policy. Google
Talk, Skype, or any other IM system would generate a lot of events based on usage. The
use may or may not be allowed by company policy. If allowed, there is no reason to process
such events unless a known vulnerability is associated with them. You will learn how to
discard any events related to the Gtalk application.
6.1. CREATE DS GROUP TO SPECIFY DATA SOURCE
Follow the instructions below to filter Gtalk events by using a policy:
1. Choose “Configuration > Threat Intelligence > Policy” and click on New:

Figure 50: Add new policy
2. Select the policy conditions: source, destination, source ports, and destination ports.
Choose ANY for all these policy conditions.
3. Click on INSERT NEW DS GROUP?, which is included in the event types tab, to match
events related to Gtalk application.

Figure 51: Link to add new DS group
4. Write the DS group name and add events to the DS group by clicking on ADD BY DATA
SOURCE policy conditions. Select snort data source from the list.

Figure 52: Add new DS group
5. Click on this icon to edit.
6. Search for the ET POLICY Gmail gtalk event and add it by clicking on the icon ( ).
Figure 53: Add DS group
7. Click on SUBMIT SELECTION and then on UPDATE.
8. The new DS group named Gtalk appears in the policy conditions. Deselect the ANY option
and select the created Gtalk DS group.

Figure 54: Choose DS group as event type policy condition
6.2. DISCARD EVENTS
Follow the instructions below to discard Gtalk related events, so that no risk assessment, no
logical correlation, no cross-correlation, and no SQL storage of events will be performed.
Note that logging will still be performed if Logger is set to Yes in the policy consequences
section.
1. Select the SIEM tab in the policy consequences and select NO for SIEM:

Figure 55: Discard SIEM events in policy consequences
2. Write a policy rule name and click on UPDATE POLICY.
3. Click on Reload Policies.

Figure 56: Reload policy
7. CONFIGURE POLICY TO SEND EMAILS TRIGGERED BY EVENTS
This section explains how to create a policy for external events to notify an administrator
using email about a high-priority event involving a mission critical asset. The section also
explains how to create a policy for directive events to notify an administrator using email
about a policy violation of Skype IM usage.
7.1. CREATE ACTION TO SEND EMAIL
Follow the instructions below to create an action to send an email:
1. Choose “Configuration > Threat Intelligence > Actions” and click on NEW:

Figure 57: Add new action
2. Give a name to the action and select Send an email message as action type. Fill in the
required fields. You may use event attributes in the MESSAGE section.
For the emails to be successfully sent, the mail relay server
needs to be set up under “Deployment > Components >
AlienVault Center” in General Configuration settings.

Figure 58: Settings for “Send an email message” action
You can click on the keywords listed at the top of the screen to
enter them in the message instead of typing them.
3. Click SAVE.
7.2. CREATE POLICY CONDITIONS FOR EXTERNAL EVENTS
Follow the instructions below to create policy conditions for external events to match high-
priority events destined to a mission critical server:

Figure 59: Add new policy for external events
2. Choose ANY for these policy conditions: source, source ports, and destination ports. Select
your mission critical asset as destination policy condition.
3. Choose a mission critical server as the asset (Server2008 in the example) as destination
policy condition.
4. Click on “ADD MORE CONDITIONS > Event Priority” to add event priority as policy
condition. Chose 5 for Priority and 2 for Reliability.
When sending email notifications about events, it is
extremely important to configure policies correctly to avoid
overloading external systems, such as email servers or
messaging gateways.

Figure 60: Policy condition to match high priority events
5. Click ADD NEW.
7.3. CREATE ACTION AS POLICY CONSEQUENCE FOR EXTERNAL EVENTS
Follow the instructions below to create a policy action for external events, which will send an
email as a policy consequence:
1. Click the ACTIONS tab in the POLICY CONSEQUENCES part of the screen.
2. Choose the Send_email action from the list of available actions and add it by clicking the +
sign.

Figure 61: Set action to send email
3. Enter a Policy Rule Name and click UPDATE POLICY.

Figure 62: Update policy
4. Click Reload Policies.

7.4. CREATE POLICY CONDITIONS FOR DIRECTIVE EVENTS
Follow the instructions below to create policy conditions for directive events:

Figure 64: Add new policy for directive events
2. Check the Directive events checkbox and click on the Directive events link.

Figure 65: Select directive events
3. The VIEW DS GROUP window opens. Notice that the directive_alert data source is
selected. By default, all event types for this data source are selected. Change this behavior
by clicking the icon.
When sending email notifications about events, it is
extremely important to configure policies correctly to avoid
overloading external systems, such as email servers or
messaging gateways.

Figure 66: View DS group window
4. Note that all directive event types are selected, because an empty selection area on the left
means “ANY”.
Figure 67: All directive event types are selected by default
5. Select the AV Policy Violation, Skype IM usage on SRC_IP directive event from the list
and click the (+) sign. Confirm the selection by clicking the SUBMIT SELECTION button.

Figure 68: Select directive event type
6. Note that only one directive event type is selected.
Figure 69: View DS group window after selecting event type
7. Close the window.
7.5. CREATE ACTION AS POLICY CONSEQUENCE FOR DIRECTIVE EVENTS
Follow the instructions below to create a policy action for directive events, which will send
an email as a policy consequence:
1. Click the ACTIONS tab in the POLICY CONSEQUENCES part of the screen.
2. Choose Send_email action from the list of available actions and add it by clicking the +
sign.

Figure 70: Set action to send email
3. Enter a Policy Rule Name and click UPDATE POLICY.

Figure 71: Update policy
4. Click Reload Policies.

Alien vault _policymanagement

More Related Content

What's hot

Viewers also liked

Similar to Alien vault _policymanagement

Recently uploaded

Alien vault _policymanagement