OSSIM Policy Configuration

Good to differentiate what is DS and Taxonomy. It is source of event vs type of event.

If you go for DS, you are saying you want to monitor specific source like specific plugins/application/system on certain rue and event .

If you go for Taxonomy, you want to monitor based on classification for DS events. The classification is further organized as main categories (~20) and subcategories (~240).

For example, assume you have many different alarms created under the " Incidents > Alarms " and you like to get an email every time one alarm is created regardless of the source, reason, or whatever.
 
First you need to Create the email action. Go to Policy & Actions -> Action Tab
Second you need to create a new Policy, and it resides under "Policies for events generated in server".
Third, you need to decide either DS or Taxonomy. In this case DS is preferred because the source is specific to OSSIM alarms. taxonomy may not cover all alarms.
e.g. For DS, you create a new DS Group and using Directive_alert (ID: 1505) which refers to "OSSIM Directives alarms" - do "add all" of the alarm listed under directive.
e.g. For Taxonomy,  the Product Type of "Alarm" can be selected.

See - https://www.alienvault.com/forums/discussion/1249/i-would-like-any-alarm-to-send-me-an-email

In fact, it is probably a coverage decision to make sure the use case can be covered. I see it as if you want to monitor specific source (like web server or plugin) go for DS and if you want to monitor specific event classification (like web attack or scan, DoS), go for Taxonomy

See Event type - https://www.alienvault.com/documentation/usm-v5/policy-management/about-policy-conditions.htm
See Create Condition - https://www.alienvault.com/documentation/usm-v5/policy-management/creating-pol-conditions.htm


For the password piece, I think that rule match has taxonomy attached to it of Authentication Failed, so you could simply create a more general correlation rule based on taxonomy that would cover brute force attempts from all other resources. May have to explore the rules in specific for the count of failure..May need to explore more..

Thanks btan for the great overview of Taxonomy vs DS groups.  We will take a close look at the articles you provided.  Sounds like Taxonomy is more what we are after since we have a ton of servers we want to monitor and i would conside each server a source if im using DS groups correct?

In the meantime has anyone else implemented a password failed attempt rule to alert on the 3rd time?  we cant figure out the count of failure piece.

Also, could someone provide how to add an alert to monitor Java on any host....if say the OSSIM detects an attacker trying to exploit an outdated version of Java on any given host that OSSIM is monitoring.

I think seeing some examples rules will really help us in better understanding.

i would conside each server a source if im using DS groups correct?

Yes please

In the meantime has anyone else implemented a password failed attempt rule to alert on the 3rd time?  we cant figure out the count of failure piece.

Not for me at the moment but likely it is a Correlation Rule that you need to configure such that you can increase or decrease the "occurrence" count of the said interested event. Check the user guide - ref pg 171

Correlation rule attributes
Occurrence - Number of times an event has to occur in order for the rule to match

https://www.alienvault.com/doc-repo/usm/v5/USM-v5-User-Guide.pdf
... and see the example in Pg 181 on "Process: Creating a Directive from Scratch"
Hopefully this help you to kickstart to explore on the other use case mentioned

I have tried to set up a directive to alert us if there are 5 failed logon attempts within 60 seconds however it does not alert us. Below are screenshots, please tell me where I may have made the mistake. Also I want the directive to set off an alarm. I tested by utilizing an employees account who is on vacation. No emails were sent to us. How would I go about correcting that? If you need more informatioin/screenshots please let me know.