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…” check box 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.
Use case:
- Custom view/report module name – “Windows FIM Report”
- Create a view: Date range – Today
- Event Name – contains “FIM”
- Data Source – AlienVault HIDS
- Columns – Event name, Date, Source, Sensor, Category, Subcategory, Username, Userdata1, Filename
- Schedule to run this module daily for daily file change reports. You can also restrict the report to specific assets when you set the schedule.
Reference: Creating Custom Reports from Security Events
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.
- Navigate to “Configuration” --> “Threat Intelligence” --> “Data Source.”
- Click on the “Data Source Groups” button, then click on “Add New Group.”
- Name it something meaningful, like “Device Config Changes” and add a description if you like
- Hint: Use something general, so you can use this same DS group for config changes from other devices, which we will discuss in a later step.
- Select “Add by Data Source” and search for the Data Source ID (1636) you noted from the previous step, using the “Search:” field on the right.
- Click on the result to add it to the Data Source Group
- Now we need to specify the exact Event Type ID
- Click on the pencil icon, and note there is nothing in the left panel, and a large list in the right.
- Type the Event Type ID in the field at the top of the right pane, to search for it.
- Click the event “+” sign to move it to the left, then click “Submit Selection”
- This will take you back to the Data Source Group edit page.
- Note the “Events type selected: 1” to the right of the page.
- Click “Update” to save group.
Create Policy / Action
Now that we have our data source group set up, let’s create a policy around it so we can do some cool stuff.
- Let’s click back into to “Configuration” --> “Threat Intelligence” --> “Policy”
- You will see three policy groups.
- Select “New” in the “Default policy group”
- Note the yellow colored fields, those require editing.
- Name the policy first. Let’s call it “Config Changes”
- Let’s set the “Source” and “Destination” fields to “Any”
- 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” dropdown, and “Insert Into DS Group” and select the “Device Config Changes” group.
References:
Configuring a Policy to Send Emails Triggered by Events
Connecting Your Corporate Mail Server to USM Appliance
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.
References:
Configuring a Policy to Discard Events
Creating an Action for an External Event
Cisco ASA REST API Quick Start Guide
Expect Script Example for SSH and running command
Conclusion
There’s a lot to learn to get the most from your AlienVault USM or OSSIM implementation. Keep up to date with the latest technical insights by subscribing to the AlienVault Forum!
Related Stories
Article Link: http://feeds.feedblitz.com/~/290815260/0/alienvault-blogs~Tips-and-Tricks-for-Using-USM-OSSIM-from-an-AlienVault-Engineer