I would suggest removing the ANY and ALL_DMZ variables all together,

In the example above, the simplest fix would be to get rid of the ANY event variable. Since the 10.10.1.0-10.10.1.255 DMZ does not exist yet, the only variable you would be interested in is the GREEN_DMZ. When the other comes on line, name it RED_DMZ with the outlined parameters.

I see a problem if you'd like to have specific filters or signatures for one and not the other, and some for both. If you want the Attacker Loc: to specifically say RED or GREEN_DMZ, you would have to create 2 filters, one for each event variable. Otherwise you could create 1 filter with the IP address range, but, because that range will either fall into your $IN or $OUT event variable by default (depending on where your IPS is inline), that will be in the Attacker Loc field.

I would like to see event variables with in an event variable. You could have two DMZ event variables, and place those variables into the ALL_DMZ "super" event variable. That would allow you to create one filter/signature for both groups, and then you could split them out if you wanted a signature or filter for one of the sub event variables too. I would hope that the Event Details would specify the "sub" variable in the Attacker/Victim Loc: field though.

That would make managing and monitoring a little easier I think.

>>I would suggest removing the ANY and ALL_DMZ variables all together

I don't believe there is an IN or OUT variable by default in version 5.x. If you're seeing them, it's because they were carried over during an upgrade. The ANY variable is simply a replacement for the old OUT variable in our environment.

I know this much, even with an ANY variable of 0.0.0.0-255.255.255.255, some addresses are mapped into other event variables. So clearly this solution has some intelligence to properly map ip addresses into event variables. Maybe it's as simple as the ordering of variables, or something more complex. I'm just looking for an explaination of how its supposed to work. Then, maybe, I will understand why it doesn't seem to be working correctly in our environment.

I see what you mean. We were seeing the same thing and it was affecting how our filters filtered. I believe when our sensors were first deployed they had local event variables that overlapped global event variables. We wound removing many of the local event variables that were covered by global ones.

I wouldn't be surprised if the order in which the variables are in determine how the sensor maps the alerts. It seems the order matters in many other things with these sensors. However, I don't think there is a way to change the order, short of removing everything and then putting them back in, in the order you want. It would be an interesting to test.

After some testing, I can see with 5.x, defining addresses in variable $IN, does not map an Attacker/Victim Loc to IN. Defining any other event variable address name, works. Works however with $IN being all lowewr case $in. Ah well, I can live with that.