The IDS rules management has a learning curve

[EricPerl]

I started experimenting with IDS/IPS yesterday and it didn't take long until I thought I was losing my mind.

I've now figured out why: The Admin->Rules page is what I would call a Resultant Set of "Policies" page.
I put policies in quotes because they include manual adjustments on the policy page.
And these adjustments have priority -1. IOW, once you've made an adjustment, no actual policy can affect it.
If you've made any changes directly on the rules page, an adjustment has been created for you and until you delete the adjustment from Policy->Rule-adjustments, no policy will affect that rule.

That behavior tripped me up big time because I KNEW I had never visited that adjustment page, so I didn't bother to look after my test policy behaved unexpectedly.
I would suggest a 'delete adjustment' alongside the enable/disable/alert/drop buttons...

On a side note, I've found filters on matched policy useful.
I 've had some surprises but they could be due to missing an apply...
Apparently, the filtering yields the rules that were affected by the policy (based on initial state and adjustments, not current view).
For example, with a single alert rule and a policy to swap alert to drop, the result is drop (as expected) and filtering by that policy shows the altered rule (even though the policy criteria is not a match based on what is displayed).

In any case, I'm going to keep my policies simple (not specifying old action, pri 0 for exceptions, pri 1 for large sets, no overlaps of sets)...

HTH

[EricPerl]

Thinking about this UX some more, I feel like there should be an easy way to figure out how the effective action was set:
* Default value
* Manual adjustment X
* Policy Y

[someone]

policies depending on what is done will affect all rules under that policy
Policies are for large changes in ruleset behavior