Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE

Selecting Active Lists As Variables

Selecting Active Lists As Variables

Today Adding or removing from active lists automatically is done via action rules

The issue is that you can only select the Active list manually from the Console

It would be great if a variable existed that allowed to add to different active lists according to conditions in the same rule, for examle something like a conditional variable

if condition A is met add to list A if condition B is met add to list B

Best regards

David

Tags (3)
8 Comments
Frequent Contributor.. jcamba Frequent Contributor..
Frequent Contributor..

David,

I agree, this should definitely be an option.

If you are comfortable using many local variables in your rules, I have a workaround for the situation you outlined. This requires Condition A and B to be mutually exclusive.

If condition A is met add to list A

If condition B is met add to list B

 

The solution requires 2 Active List Addition Actions and 2 Custom Conditional Local Variables for each field/value you would like to add to either list.

Configure both Custom Conditional Local Variables to return the intended field/value if true and a static string i.e. "PLACEHOLDER" if false.

Example

variableOneA = (If condition A) $realValue | else "PLACEHOLDER"

variableOneB = (if condition A) "PLACEHOLDER" | else $realValue

Your rule actions would be as follows.

Add to Active List A:

$variableOneA

Add to Active List B:

$variableOneB

Configured Properly, this will result in either List A or List B receiving the real field/value data and the other list to only receive the string "PLACEHOLDER".
When the Active List is keyed properly, this will cause new entries to be generated for new fields/values in one list while the "count" of the "PLACEHOLDER" entry simply goes up.

You can choose to later remove any "PLACEHOLDER" entries via additional rule actions, or simply filter out any "PLACEHOLDER" entries with any subsequent rules/queries/trends.

 

David Bau Outstanding Contributor.
Outstanding Contributor.

This is actually a great workaround but still its something very basic that needs to be provided by HP a builtin option in the console

Much appreciated

Best regards

David

 

martynbhp Respected Contributor.
Respected Contributor.

I disagree. This will become very complicated when aggregations have to be included in the rule. So if you needed to have something added to AL#1 if condition A happened 5 times in 10 minutes; and/or something added to AL#2 if condition B happened 3 times in 2 minutes; you will finish up with an unmangeable rule.

It is far better to put as many of your conditions as possible into a filter; the each rule will have contions like "Matches Filter_X && <condition_A>", "Matches Filter_X && <condition_B>".

Using this method you can have virtually unlimited combinations of <condition_?> with differing aggregation levels for each condition.

Remember that a filter is evaluated ONCE only per event, so every subsequent "Matches Filter_X" statement evaluates to an "IF .true." statement; ArcSight doesn't re-evaluate the filter for each rule that uses it. (For this reason I often use nested filters - it is faster in processing).

Martyn

Frequent Contributor.. jcamba Frequent Contributor..
Frequent Contributor..

@martynbhp

Remember that a filter is evaluated ONCE only per event, so every subsequent "Matches Filter_X" statement evaluates to an "IF .true." statement; ArcSight doesn't re-evaluate the filter for each rule that uses it. (For this reason I often use nested filters - it is faster in processing).

Martyn,

Do you have any documentation supporting this statement? I have a hard time believing that this is true. Primarily because everything I've read thus far would sugggest that Filters, esepcially when nested, have high performance costs.


So if you needed to have something added to AL#1 if condition A happened 5 times in 10 minutes; and/or something added to AL#2 if condition B happened 3 times in 2 minutes; you will finish up with an unmangeable rule.

In this case, you'd just create 2 separate rules with 2 unique actions. /shrug

martynbhp Respected Contributor.
Respected Contributor.

@jcamba

Agreed; filters do have an overhead so use with care and sensibly. SIngle condition filters in rules  are never a good idea (OK you might need them elsewhere such as an active channel) but don't use it in a rule just put in the condition; single-use rules are equally bad as you have all the overhead of going to a filter added on to a set of conditions. My only evidence is from my "Rules Status" dashboard having had this situation where we had a complex set of conditions followed by simple condition/action pair. Originally we had three rules each with a full set of conditions but differing only in the final condition/action.

I took the bulk of the conditions, a quite complex set with nested "&" and "OR" and made a filter of them, then re-wrote the three rules as "Matches filter & condition -> do action"

Monitoring this on the Rules Status dashboard showed that my re-written rules as a group took significantly less time than the original three full-blown rules. Draw your own conclusion.

An alternative, which I admit I have not tried, may be to write a lightweight rule with the bulk of the conditions in it and use the lightweight rule as a Generator for the standard rule which will do the final condition/action pair. You would then have "n+1" rules for "n" actions.

 

Martyn

Frequent Contributor.. jcamba Frequent Contributor..
Frequent Contributor..

@martynbhp,

Interesting; some members of my Work Group had theorized that an efficient Correlation Engine would behave in a similar manner that you just described. 

I.E. 
If a Condition X is being Tested in Correlation Rule A, B, and C; it would not make sense to evaluate Conidition X 3 times. An efficient SIEM would evaluate Condition X 1 time, "cache" the result, and then provide that result quickly if Condition X is reference again. 

We didn't guess that this behavior would be predicated on those Conditions being in a Filter; however, this would make a little sense. |


An alternative, which I admit I have not tried, may be to write a lightweight rule with the bulk of the conditions in it and use the lightweight rule as a Generator for the standard rule which will do the final condition/action pair. You would then have "n+1" rules for "n" actions.

 

We use a similar methodology in our SIEM(s). I call these kinds of Rules "Lower-Level" Generators. We use them "call out" Events of Interest and help Normalize data across Log Sources. It's very effective. 


Thanks for the feedback! I'll be testing your Filter theory asap.

Bax Regular Contributor.
Regular Contributor.

@jcamba

Hi,

regarding Your idea about conditional lis population, is there any value that You can pass to AL instad of "PLACEHOLDER" , that would be refused from Active list?

Something that should be like undefined value, rejected by active list.

I am refering to idea to avoid list populating with dummy value "PLACEHOLDER" , by using some BUG in system....

 

Frequent Contributor.. jcamba Frequent Contributor..
Frequent Contributor..

@Bax,

We haven't identified any bug that would do this. 

Additionally, I would not recommend using a "bug" as a "feature". ArcSight is already buggy and unstable.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.