When selecting the Policy option I was expecting the drop-down onthe Rules tab to contain the Categories - but it only contains the item IPS Policy - Security. This was a bit confusing and actually one of my questions. The question was really badly written, sorry for that. The page - with 17000+ rules - takes ages to load, but I guess that is not something easily fixable.
When you choose to use an IPS Policy, the GUI code on the CATEGORIES tab blocks further choice of other Snort rules as it is presumed you are giving that responsibility over to the policy. Thus the RULES tab sees only the collection of rules encompassed by the selected policy. Yes, through a fluke in the GUI code, you can still use SID MGMT to "force" additional Snort rules into the final product that are not part of the chosen Snort IPS Policy. If you want to see the actual rules in use on the interface after all the processing logic is done, in the Category drop-down is an entry called "Active Rules" - if I remember the name correctly. That choice loads all of the enabled rules that will be used on the interface. But it will be even larger as the Snort built-in rules will also be included in the list, so it will take several seconds or even minutes to fully load and render the page.
The other question was simply this (and I present it as a statement now, not a question). Let's assume a category in Emerging. In legacy mode I only need a category to alert, and that will essentially block. When turning on inline mode, the rules in the category will be alert only so for me to get the same functionality as in legacy mode of having an Emerging category blocking, I need to add a file in drop SID list containing "emerging_". Then my chosen Emerging categories will block also in inline mode.
True, but literally what you are doing is changing the action for the rules matching the criteria in your SID MGMT file from ALERT to DROP. I prefer to always use the term "drop" when speaking of Inline IPS Mode to clearly distinguish it from Legacy Mode. That's exactly the same thing the GUI code does for the rules that match the chosen IPS Policy. It simply searches through all of the snort rules files and finds every GID:SID that has a matching IPS Policy tag (i.e., a tag matching the chosen policy). It then changes the action of matching rules to the value prescribed in the IPS Policy metadata tag for each rule, and then adds the rule to its list of "enabled" rules to be loaded by Snort.
Please explain to me why I would use the modifysid to enable ALL wordpress rules, would that not be the job of enablesid with a (for me yet unknown) regular expression? I am not trying to modify the rule, just enabling it based on free text in the description (if I understood this correctly).
Perhaps I misunderstood your question. I thought you wanted to find rules that had a particular keyword in their signature and change their action, because I don't recall any rules category file called "wordpress". So for example, if I want to find all rules whose signature MSG field contained something about "wordpress", then only the modifysid logic can do that. It is the only SID MGMT "function" that looks at the full text of each rule's signature. The other SID MGMT "functions" only look for one of two things: (1) the category file name, such as emerging-scan; or (2) the GID:SID. That's it. The enablesid, disablesid, dropsid and rejectsid logic only looks for those two fields. It is not looking at the MSG field in a rule. Only modifysid looks into the MSG field of a rule to search for matches.
I appreciate your patience. I try to write my questions and thoughts in a way that will server future readers.
Some of your questions lead me to think perhaps you have not actually studied the raw text of the IPS Policy rules. If you have not actually seen the metadata tags I've been discussing, then go to the RULES tab and select your IPS Policy in the Category drop-down. After the rules finish loading on the page, click on the GID:SID value for a rule, or double-click the row, to open the raw text in a pop-up modal dialog. Read the entire text of the rule signature. Look for the IPS Policy metadata tags. You will see them listed. And for many of the rules, you will see multiple tags associating the rule to more than one policy. And depending on the particular rule you choose to view, you may also see different rule actions for the different policy matches. So when you "select" an IPS Policy, all that really does is tell the GUI code to load every single Snort rule into a gigantic list in memory and then search for those policy metadata tags. It selects rules from the list that have an IPS Policy metadata tag matching the policy you specified. Then also, as it copies that rule over to the "enabled list" in memory, it changes the rule's action keyword to match what is suggested by the IPS Policy metadata tag. And not every single Snort rule has an IPS Policy metadata tag in it. Most do, but some do not. So those rules would never get selected as part of a policy.