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. 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 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 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 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 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 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 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 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 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 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 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 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 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

Software

Transcript of Alien vault _policymanagement