Get the latest security news in your inbox.

Topic #1: Customizing SIEM View and Custom Report Modules

One of THE most powerful features of the AlienVault USM SIEM view is the ability to create custom views and save those as re-usable views and as report modules.

HOW TO

First, you need to navigate to the SIEM view, “Analysis-->SIEM”, and select your search criteria, be it a data source, asset or asset group, date range, etc. and get it looking the way you want it.

Then, click the “Change View” button, and select “Edit Current View” (or “Create New View” if you want to start from scratch). Set the “View Name: field to a meaningful name, like “Cisco VPN Logins.” (Do this first to avoid accidentally overwriting current view). Make sure the “Include custom search criteria…” checkbox is ticked. That will ensure your selected search terms are preserved. After that, select which fields you wish to be displayed, and remove those that aren’t that useful.

Verify you have set a unique view name and hit the “Save As” button. When you change your view to the new one, it will be in the list, but at the bottom. Verify everything looks the way you like it. Notice the search criteria is preserved.

One last step, let’s create a report module from this view. Click the “Change View” button and select “Edit Current View” again. Remember seeing the “Save as report module” button? Click that, and it will save a report module under “Reports”-->”All Reports”-->”Report Modules”-->”Custom Security Events”. You can now use this report module as is or incorporate it into a custom report by combining with other modules. Just hit the little blue button next to the module to create a custom report from the module. Please note this functionality is not available in OSSIM.

Topic #2: Email Alert Configuration and Notification

Say for instance you see an event in the SIEM view where a configuration change has been made to your firewall. You would like to be notified from now on whenever this event occurs.

HOW TO

Determine Event Type

First we need to open an event and look at the event details. In this scenario, we will use the “ASA: A user made a configuration change” event which is Data Source ID 1636, and Event Type ID 111010. Make a note of these two numbers. (Data Source ID 1636 is the general cisco-asa data source that holds all the Cisco related event types.)

Create Data Source Group

The process takes a little bit of planning.

First, you need to create a data source group into which you can insert the event.

The next thing we need to make this work is to assign the DS Group we just created.

Click into the “Event Types” field, and note the change in the window below.

Deselect the “Any” selection, and select the DS group we created before “Device Config Changes”

Now for Action!

Click on “Action” and “Insert New Action”

Populate the fields with a Name, Context, Description.

Set “Type” to email.

Fill out, From, To, and Subject.

For the Subject it’s helpful to put the SRC_IP or SRCIP_HOSTNAME keyword Like so:

“Config Change on SRCIP_HOSTNAME”

In the “Message” field, you can add freeform text that will be in the body of the email.

You can add keywords (listed at the top of the window) that correspond to event items, or you can check the box to “Append Email with all event fields”

Click Save and go back to the Policy and the action field.

You should now be able to move the new action from the “Available Actions” column to the “Active Actions”

Click the “Update Policy” button, and notice “Reload Policies” is now highlighted in red.

Click “Reload Policies” and that’s it!

Now, say for instance later on you want to get notification of config change events from another device, all you have to do is select the event in the SIEM view, select the “Actions” drop-down, and “Insert Into DS Group” and select the “Device Config Changes” group.

Topic #3: AlienVault USM Event Suppression and Action Scripts

This tip looks at false positive event suppression, and actions that will run an external program.

HOW TO

Part I: False positive event suppression

For our first example, imagine you have an external PCI scanning vendor that has a specific IP address or range from where they run their scans. First, in the USM GUI, navigate to Configuration --> Threat Intelligence --> Policy. Click on "New" in the Default policy group. Name the policy rule something meaningful, like "PCI scan suppression". Next, click in the source column, and you'll see a section below called "Policy Conditions." There's a gray box there that says, Source*, Insert New Asset?, Insert New Net?, and Insert New Net Group.

For this tip, we'll use "Insert New Asset?" Go ahead and click on that, and fill in the name field, IP address, (multiples can be placed comma separated) location (optional) and FQDN/Alias (optional).

Important: Since this is an outside vendor, set the flag for "External Asset" to Yes and leave the rest of the fields alone, then click "Save."

Now that we're back at the policy screen, click over on the "Consequences" section, specifically in the "SIEM" column. Set SIEM to "No". This will prevent any kind of correlation, or database storage. This will also prevent the events from being populated in the SIEM view and no alarms will be generated.

In the "Logger" column, you can set this to “No” as well, but you may want to keep a record of the scans. This really depends on your security policy needs.

Part II: Action Scripts or running external programs from an action.

Using the knowledge from the last two tips, you can create a policy around a particular alarm, or event and have a script kick off to perform a particular action.

Once the policy is created, and you are creating the action for it, set the "Type" to "Execute an external program."

Now you will see a field where you can enter a command or a script. By default, the script runs as the root user, and the working directory is /root; bear that in mind when writing scripts. You will want to use absolute paths to any resources you are calling outside of the script as well. Keywords listed in the action window can be used as variables on the command line. For example, if an event occurs that meets the policy criteria, you can pass the SRC_IP to a text file like so:

/bin/echo 'SRC_IP' > /root/src.txt and then take it a step further to actually run an API call to a network device, (Cisco now provides a REST API) to block an IP, or to isolate a network device that is infected. For devices that don't support an API, you can use "Expect" to SSH into network devices and run commands.

About the Author:Scott MaceAlmost 20 years of experience with computer technology, from the heyday of BBS’s to the days of Google Fiber, Scott has been involved in manufacturing, hospitality industry, legal, and multimedia companies, managing security and infrastructure.
Read more posts from Scott Mace ›