• Support
  • Forums
  • Blogs
A New Community Experience is Coming! For more information, please see our announcement.

User contributed directives can't be updated


New Life Form

We have quite a few built-in directives (they come out-of-the-box with the AlienVault installation) which we cloned and modified according to our need. Common reason for doing this is that the directives generate false positives, or that we need to exclude certain usernames or IPs from generating alerts, etc. I'm sure we're not the only users of AlienVault who clone existing directives.
When we're cloning a directive the original built-in directive gets disabled, which is expected, and the cloned directive moves to User Contributed directive section. The problem with this is that the User Contributed directives don't benefit from the regular AlienVault updates.

For example, let's say I cloned the AV Malware, Phishing activity directive and modified it under the User Contributed directive. When the original built-in AV Malware, Phishing activity directive (which is disabled) gets updated, the User Contributed one doesn't.
AlienVault confirmed this behavior (I logged a case with TAC earlier) and made me realize that we might be stuck with out-of-date User Contributed directives, which isn't good. We depend a lot on the User Contributed directives for bringing the noise down in the SOC and for having better quality alarms for our environment. Out-of-the-box directives can't fit all environments, it's crazy to think that.
So the options now are to either stop cloning directives and use the built-in ones, or continue using custom (User Contributed) directives and face the fact that they might be very out of date (meaning not having the latest SIDs, etc).

Have any of you found a solution to this dilemma?


Share post:


  • In an attempt to answer (part of) my question, there may be a way to achieve one functionality I am looking for - suppressing alarms generated by the correlation directives.
    And that is by identifying the SID (or SIDs) within the correlation directive which triggers the alarm, and creating a suppression policy (or discard policy as mentioned here - https://www.alienvault.com/documentation/usm-appliance/policy-management/proc-cfg-policy-discard.htm) where you set Logical Correlation to No. This theoretically means that the SID shouldn't be used in any correlation directive. The discard policy will need to be as specific as possible - including Src/Dst IP and Src/Dst ports if possible.

    However, this raises the question - what if the SID (or SIDs) which I am discarding are used in other correlation directives which I still want to use? I don't want to modify those too with the discard policy I just created.

    The other functionalities which I am looking to achieve are still unsolved without loosing the capability to have up-to-date directives:
    - Tweaking the correlation directive rules or USERDATA/USERNAME fields by cloning existing directives to USER CONTRIBUTED directives
    - Lowering the risk of existing correlation directives by cloning them to USER CONTRIBUTED
Sign In or Register to comment.