Exercise 1: Configure AlienVault USM to Receive Logs

using Syslog Protocol

In this exercise you will configure AlienVault USM to receive logs from a firewall by
enabling the appropriate data source plugin. You will test if firewall logs are indeed
processed by the server and logger components by injecting some traffic into
AlienVault USM.
Lab Exercise Procedure
Complete these steps:
Step 1 Log into USM using HTTP. Log in using admin as a username and
password as a password
Step 2 In USM, navigate to CONFIGURATION > DEPLOYMENT >
ALIENVAULT CENTER > SYSTEM DETAILS.
Step 3 Click SENSOR CONFIGURATION and navigate to COLLECTION.
Enable the sophos-utm data source plugin. Click APPLY
CHANGES to update Sensor configuration.

Step 4 Click ALIENVAULT CENTER. Open system details for the

AlienVault appliance.
Step 5 Log into the SSH session to AlienVault USM using password as a
password. In the menu select Jailbreak System. This will start the
USM command prompt shell. Choose YES when asked whether you
want to take that action. In the command prompt shell, look for the
location of the logs in the sophos-utm data source plugin:

VirtualUSMAllInOne:~# grep location

/etc/ossim/agent/plugins/sophos-utm.cfg

location=/var/log/sophos-utm.log

Step 6 Examine the content of the /var/log/sophos-utm.log file.

VirtualUSMAllInOne:~# more /var/log/sophos-

utm.log

Step 7 -- Testing Authentication Failed --

Step 8 Return to the USM web UI. Navigate to ANALYSIS > SECURITY
EVENTS (SIEM) > REAL-TIME. You will see incoming normalized
Sophos UTM events.
List three types of Sophos UTM events that were detected by AlienVault USM:
Go to ANALYSIS > SECURITY EVENTS (SIEM) and search for sophos-
utm data source. Are any lab devices involved in the Sophos UTM events?
If yes, which ones?

Step 9 Navigate to ANALYSIS > RAW LOGS. Filter the raw logs to see
only events from sophos-utm QUERY data source. Click the RAW
to display logs.

Observe the auto-complete function of the SEARCH input field.

Type only sophos-utm into the field and several options,
including a datasource=sophos-utm option, will be displayed.

You will see the Sophos UTM logs in their raw format.
Exercise 2: Create a Policy for Events Involving Important
Assets
In this exercise you will create a policy to notify an administrator about a high- priority
event involving the Server 2012 asset using email. These high-priority events will be
fully processed by the USM Server and USM Logger components. Before configuring
the policy, you will examine where in the USM web UI to set up an email relay server
and configure an action to send an email. You will not be able to test the policy
because the email system is not enabled in the lab environment.
Lab Exercise Procedure
Complete these steps:
Step 1 Return to the USM web UI. Log in using admin as a username and
password as a password.
Step 2 Navigate to CONFIGURATION > DEPLOYMENT >
COMPONENTS > ALIENVAULT CENTER. Open the system
details for the AlienVault appliance.
 Click General Configuration. Expand the options in the MAIL SERVER
RELAY setting and select YES. You will see the mail server options you
can configure. Do not save the settings since there is no mail server in the
lab environment.

Step 3 Navigate to CONFIGURATION > THREAT INTELLIGENCE >

ACTIONS. Create a new action using the details as listed in
the table. SAVE the action when completed.

Name SEND_EMAIL
CONTEXT My Company
DESCRIPTION Action to send email
TYPE Send an email message
FROM [email protected]
TO [email protected]
SUBJECT USM AlienVault – High asset event
MESSAGE: A high priority event to an important asset was
detected:
Date: DATE
Data source plugin ID and event type ID: PLUGIN_ID
PLUGIN_SID
Source IP address: SRC_IP
Destination IP address: DST_IP
Event priority: PRIORITY
Event risk: RISK
 You can click the keywords from an event data instead of
typing them.

Step 4 Navigate to CONFIGURATION > THREAT INTELLIGENCE >

POLICY. Create a new policy in the Default Policy Group as
described in the table.
Select the EVENT PRIORITY condition from the ADD MORE
CONDITIONS menu.
Rule Name High Priority Events
CONDITIONS
SOURCE ANY
DEST Server 2012 (Look for <server Win IP> in Assets)
SRC PORT ANY
DEST PORT ANY
EVENT TYPES (revisar DATASOURCE y EVENT TYPE a evaluar)
EVENT PRIORITY Priority: 1
Reliability: 1

CONSEQUENCES
ACTION SEND_EMAIL
SIEM Yes, leave the others as the default
 Rule Name High Priority Events
LOGGER Yes, leave the others as the default
FORWARDING No

Step 5 Update the policy by clicking UPDATE POLICY.

Step 6 Click Reload Policies highlighted in red.

Exercise 3: Create a Policy for Firewall Events

In this exercise you will create a policy for firewall events. These events will neither be
cross-correlated nor stored in the SIEM database, while all other SIEM and logger
functionalities will be enabled. You will test the policy by again injecting Sophos UTM
log messages into the system.
Lab Exercise Procedure
Complete these steps:
Step 1 Return to the USM web UI Log in using admin as a username and
password as a password.
 Step 2 Navigate to CONFIGURATION > THREAT INTELLIGENCE >
POLICY. Create a new policy in the Default Policy Group, as
described in the table:

Name Firewall Events

CONDITIONS
SOURCE ANY
DEST ANY
SRC PORT ANY
DEST PORT ANY
EVENT TYPES Create a new DS group named Firewalls which
contains the sophos-utm data source plugin (evaluar
que tipo de evento se va filtrar)
CONSEQUENCES
ACTION No Actions
SIEM No
LOGGER Yes, Block signing
FORWARDING No

Step 3 Update the policy by clicking UPDATE POLICY.

Step 4 Click Reload Policies highlighted in red.

The resulting policies should be as shown in the figure:

 Step 5 Return to USM web UI. Navigate to ANALYSIS > SECURITY
EVENTS (SIEM) > REAL-TIME.

Can you see any new incoming Sophos UTM event? Why or why not?

Step 7 Navigate to ANALYSIS > RAW LOGS. Filter raw logs to see
only the events coming from the sophos-utm data source. You
will see recent events.

You will see Sophos UTM logs in their raw format. The effect of the policy is
that events are still stored by the logger component but are not stored by
the server into the SIEM database.

In this lab, you learned how to create policies based on different criteria to
trigger certain actions or to modify AlienVault USM behavior.
Exercise 4: Change Alarms, Events, and Logs Retention
Configuration
In this exercise, you will change alarms and log retention configuration, and examine
events retention configuration. You will also examine the location of logger files in the
file system of AlienVault USM.
Lab Exercise Procedure
Complete these steps:
Step 1 Access the USM using HTTP. Log in using admin as a username
and password as a password.
Step 2 Navigate to ANALYSIS > ALARMS and examine if there are any
alarms older than 1 day. Even if the bubbles do not show up on the
graph, there may be alarms listed below.

Step 3 Navigate to ANALYSIS > RAW LOGS and verify if there are any
logs. Set the time frame selection to show all logs.
 What is the number of raw logs?
___________________________________________________
Step 4 Navigate to CONFIGURATION > ADMINISTRATION > MAIN.
Expand the BACKUP option.

Is backup of the SIEM database enabled?

___________________________________________________
How long are events kept in the SIEM database?
___________________________________________________
Are alarms set to expire?
___________________________________________________
Are logs set to expire?
___________________________________________________
Step 5 Enable alarm expiration and set lifetime to 2 days. Enable log
expiration and set lifetime of logs to 10 days. Click UPDATE
CONFIGURATION to save your changes.
 You can check if the alarms older than 2 days were indeed
deleted from the system. However, alarms are deleted using
a scheduled clean job every hour. Therefore, you may have
to wait for an hour to actually see effect of the configuration.
The same applies to log files.

Make sure the lifetime of alarms and logs conforms to your

security or regulatory policies.

Step 6 Log in to USM using SSH. Log in using root as username and
password as a password.
Step 7 Select Jailbreak System from the displayed menu. Raw logs are
stored in the
/var/ossim/logs/<year>/<month>/<day>/hour/<ip_add
r ess>/ directories. Examine the contents of the
/var/ossim/logs directory. You will see a directory with a year
as a name.
VirtualUSMAllInOne:~# cd /var/ossim/logs
VirtualUSMAllInOne:/var/ossim/logs# ls
2015 2016 last latest_update locate.index searches
Examine the content of 2016 directory:
# cd 2016
# ls -l
total 16
drwxrwxr-x 3 avserver alienvault 4096 Jun 22 15:01 01

drwxrwxr-x 3 avserver alienvault 4096 Jun 22 15:01 04

drwxrwxr-x 3 avserver alienvault 4096 Jun 22 15:01 05

drwxrwxr-x 3 avserver alienvault 4096 Jun 22 15:01 06

 Use the cd command to get to the level of the most recent log file directory.
Sort the output by file size:
VirtualUSMAllInOne:/var/ossim/logs/2015/04/16/06/192.168.250.
1 1# # pwd
/var/ossim/logs/2016/06/22/18/192.168.250.11
# ls -lSh
total 548K
-rw-r--r-- 1 root root 332K Jun 22 15:01

index.inx
-rw-r--r-- 1 avserver alienvault 197K Jun 22 15:00 2016-
06-22T18-51-15.459963Z.log
-rw-r--r-- 1 root root 995 Jun 22 15:01
data.stats
-rw-r--r-- 1 avserver alienvault 684 Jun 22 15:00 2016-06-
22T18-51-15.459963Z.log.sig
-rw-r--r-- 1 avserver alienvault 4 Jun 22 15:00 2016-06-
22T18-51-15.459963Z.log.count
-rw-r--r-- 1 avserver alienvault 4 Jun 22 15:00
count.total
Step 8 The directory will contain a .log or log.gz file that includes raw logs.
The log.gz file is a compressed file that must be decompressed
before viewing. Decompress the file using the gzip -d
[filename.gz] command, if necessary.
Step 9 Examine the log file content to view the raw logs.
VirtualUSMAllInOne:/var/ossim/logs/2015/04/16/06/192.168.250.
1 1# more 2016-06-22T18-51-15.459963Z.log
<?xml version='1.0' encoding='ISO-8859-1'
?><log> <sign type='signature' digest='sha1' />
<entry id='2' v='2' fdate='2016-06-22 18:51:07'
date='1466621487' plugin_id='7009' sensor='192.16
8.250.11' src_ip='192.168.250.11' dst_ip='192.168.250.11'
src_port='0' dst_port='0' tzone='-4.00'
datalen='347' data='AV - Alert - "1466621467" --> RID:
"5501"; RL: "3"; RG: "pam,syslog,authenti
cation_success,"; RC: "Login session opened."; USER: "None";
SRCIP: "None"; HOSTNAME: "VirtualUSM
AllInOne"; LOCATION: "/var/log/auth.log"; EVENT: "[INIT]Jun 22
14:51:06 VirtualUSMAllInOne su[501
2]: pam_unix(su:session): session opened for user rabbitmq
by (uid=0)[END]"; ' plugin_sid='5501'
proto='6' ctx='d3644c58-e34a-11e4-9251-000c2910cb08'
src_host='d4ca67f0-e34a-11e4-9251-000c2910c
b08' dst_host='d4ca67f0-e34a-11e4-9251-000c2910cb08'
src_net='c1a37006-7aa5-d3f8-f434-c8f1cec4929
9' dst_net='c1a37006-7aa5-d3f8-f434-c8f1cec49299'
username='rabbitmq' userdata1='/var/log/auth.lo
g' userdata2='Login session opened.'
userdata3='pam,syslog,authentication_success,' userdata4='no
ne' idm_host_src='VirtualUSMAllInOne'
idm_host_dst='VirtualUSMAllInOne' device='192.168.250.11'/>
 <entry id='3' v='2' fdate='2016-06-22 18:51:09'
date='1466621487' plugin_id='7001' sensor='192.16
8.250.11' src_ip='192.168.250.11' dst_ip='192.168.250.11'
src_port='0' dst_port='0' tzone='-4.00'
datalen='313' data='AV - Alert - "1466621469" --> RID:
"5502"; RL: "3"; RG: "pam,syslog,"; RC: "
Login session closed."; USER: "None"; SRCIP: "None"; HOSTNAME:
"VirtualUSMAllInOne"; LOCATION: "/
var/log/auth.log"; EVENT: "[INIT]Jun 22 14:51:07
VirtualUSMAllInOne su[5012]: pam_unix(su:session
): session closed for user rabbitmq[END]"; '
plugin_sid='5502' proto='6' ctx='d3644c58-e34a-11e4
-9251-000c2910cb08' src_host='d4ca67f0-e34a-11e4-
9251-000c2910cb08' dst_host='d4ca67f0-e34a-11e4-
9251-000c2910cb08' src_net='c1a37006-7aa5-d3f8-
f434-c8f1cec49299' dst_net='c1a37006-7aa5-d3f8-f43
4-c8f1cec49299' username='rabbitmq'
userdata1='/var/log/auth.log' userdata2='Login session closed
.' userdata3='pam,syslog,' userdata4='none'
idm_host_src='VirtualUSMAllInOne' idm_host_dst='Virtu
alUSMAllInOne' device='192.168.250.11'/>
<…output omitted…>
Exit the SSH session.

Exercise : Explore Events Backup and Restore

In this exercise, you will examine the automatic backup functionality of events. You
will delete the events from the SIEM database and restore them using a backup file.
Lab Exercise Procedure
Complete these steps:
Step 1 Navigate to ANALYSIS > SECURITY EVENTS (SIEM) and verify if
there are any events.

How many events?

 ___________________________________________________________
Step 2 Navigate to CONFIGURATION > ADMINISTRATION > BACKUPS
> EVENTS. You should see some backup files that can be used
to restore the events.

Step 3 Delete all events from the SIEM database by clicking CLEAR SIEM
DATABASE.
Step 4 Navigate back to ANALYSIS > SECURITY EVENTS (SIEM) and
verify if there are any events.

You will see no events because you cleared the SIEM database.
Step 5 Navigate back to CONFIGURATION > ADMINISTRATION >
BACKUPS > EVENTS. Restore the events from the latest backup
by selecting the latest file and clicking RESTORE.
When the restore finishes inserting the events you will see a notification
at the right side of the screen.

Step 6 Navigate back to ANALYSIS > SECURITY EVENTS (SIEM) and

verify if there are any events. You may have to wait for few
minutes for the events to show up.

How many events?

 _____________________________________________________________
What is the reason for different number of events before deletion and
after restore?
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________

Exercise : Explore Configuration Backup and Restore

In this exercise, you will examine the configuration backup and restore functionality.
You will first create a backup of running configuration. Then you will change the
configuration of AlienVault USM. Finally, you will restore the system from the saved
backup configuration.
Lab Exercise Procedure
Complete these steps:
Step 1 Navigate to CONFIGURATION > ADMINISTRATION > BACKUPS
> CONFIGURATION. You should see automatically saved
configuration backup files, one per day. Observe that you can
download a configuration file to store it in a save location.

Step 2 Manually back up the configuration by clicking RUN BACKUP

NOW. Wait a few minutes for the manually created backup file to
appear.
Step 3 Delete the Linux system (Host-10-47-30- 101) from the asset
database. This will make a configuration change that can be
restored from the backup you just made.

Step 4 Log out of the USM web UI.

Step 5 Log back in to the USM web UI. Log in using admin as username
and password as a password.
Step 6 Navigate to ENVIRONMENT > ASSETS & GROUPS > ASSETS.
You will see that the Linux system (Host-10-47-30-101) is no
longer there.
Step 7 Log out of the web UI.
Step 8 Log in to AlienVault USM using SSH. Log in using root as
username and password as a password.
Step 9 In the AlienVault Setup menu, navigate to Maintenance &
Troubleshooting > Backups > Restore configuration backup.
Step 10 Select the configuration file by pressing SPACE and select OK from
the menu. If there are multiple configuration files available, select
the top one.

Note that the filenames have the Epoch time concatenated to

the end of the filename. The largest number is the current date.
An Epoch time converter is available at
http://www.epochconverter.com/.
 Step 11 Confirm the restore and observe the restore process.

Step 12 Wait for few minutes for the restore process to finish. After the
restore process is finished, the appliance will reboot.

The restore process may take up to 10 minutes.

Step 13 During the restore process you will lose HTTPS and SSH connectivity
to USM. When it is complete, return to the USM web UI session. You
will see that the previously deleted asset re -appeared in the asset
database as a consequence of configuration restore.

In this lab, we have examined how to enable or change the configuration of an event,
alarm, and log retention. We have also examined the events and configuration backup,
and restore functionality.
Exercise 5: Create a Custom Correlation Directive
In this exercise, you will create a custom correlation directive that will detect multiple
failed login attempts from a suspicious attacker in a short amount of time. Every time
a correlation rule is matched, the reliability of the failed login event will increase.
Eventually the event will trigger an alarm.
Lab Exercise Procedure
Complete these steps:
Step 1 Access USM using HTTP. Log in using admin as a username and
password as a password.
Step 2 Navigate to CONFIGURATION > THREAT INTELLIGENCE >
DIRECTIVES.
Step 3 Create a new correlation directive.

Step 4 Use the following parameters:

Name: SSH Authentication Failed
Intent: Delivery & Attack
Strategy: Bruteforce Authentication
Method: SSH Failed
Priority: 4
Click NEXT
 Step 5 In the next step, create a directive rule with the following
parameters:
 Rule Name: SSH Authentication Failed, click NEXT

 Leave as default of Event type

 Select the plugin: Alienvault HIDS-Authentication_Failed(7010) -
Detector 

 Add the sub-type: 5716 – Alienvault HIDS: SSHD authentication failed.
Click NEXT.

 Source: Any

 Destination: <IP Server Linux>

 Leave Source Ports and Destination Ports empty. Click NEXT

 Set the Reliability to =4

 Set the Ocurrence to =3


Click FINISH after adjusting reliability.

There is no selection for Any. In this screen, an empty selection

means ANY asset.

Step 6 Create an additional rule inside the SSH Authentication Failed

correlation directive. Click the + under ACTION to create the new
rule.
 Rule name: Sub-Rule 1, and click
NEXT. Leave as default of Event type.
Plugin: Alienvault HIDS-Authentication_Failed(7010)
Add the sub-type: 5716 – Alienvault HIDS:
SSHD authentication failed
Click SELECTED FROM LIST.
Source: select Source IP from Level 1 from a parent rule drop-
down menu. Do not manually set the IP address.
Destination: select Destination IP from Level 1 from the parent
rule drop-down menu. Do not manually set the IP address.

Leave Source Ports and Destination Ports empty. Click NEXT.

Set the Reliability to +2. Be sure that this says +2, not =2.
Click FINISH.
Step 8 Edit the OCURRENCE field Sub-Rule 1 and change the value to 3
Ensure you click OK to save the value.
Step 14 Restart the server by clicking Restart Server to apply changes.

Restart Server restarts only the USM server process and not the
USM Server appliance. The following is displayed when
restarting the server and is not cause for alarm. It simply means
that any running correlation processes will be stopped.
Step 15 Open Putty Session and test generated SSH sessions failed to
Linux Server.

Step 16 From the web UI, navigate to ANALYSIS > SECURITY EVENTS
(SIEM) > SIEM. Filter the output for SSH involving the IP
You will see a number of SSH events, as in the previous exercise.
Step 17 Filter the output to display only directive alerts:

You will see the events, generated by the custom correlation directive. At
least one event should have a risk of one, thus generating an alarm.
Step 18 Navigate to ANALYSIS > ALARMS . Examine the alarms. You
should see at least one SSH alarm. Examine details about the
alarm.
 Which events were correlated to create a directive event, which triggered the
alarm?
_____________________________________________________________
_____________________________________________________________
Which event is directive event?
_____________________________________________________________
What is the final correlation level of the directive event?
_____________________________________________________________
What is the risk of an individual event, and what is the risk of the
directive event?
_____________________________________________________________
Step 19 Click on one of the events. Scroll down, and open the details about
the directive event at the highest correlation level.