IDS Rules Editor Interface

The IDS Rules Editor Interface will enable you to edit & tune individual IDS Rules, including the IDS Rule Source code, status, Categories.

To put the rule in a category that does not exist yet, click New Category next to the Category list (Create First Category when there are no categories yet). IDSTower creates the category straight away and selects it for the rule; click Save to keep it on the rule.

Moreover it lets you override some of the rule settings without the need to change the source code, We will explain various features by explaining each section in the image below

../_images/ids_rules_editor_interface.png

1. IDS Rule Alert Message.

2. IDS Rule source code.

3. The rule’s action, priority, target and threshold, which you can override without having to edit the source code.

IDSTower allows you to tune these values without updating the source code, which matters because editing the source code of a rule introduces several issues, including:

  • the process is time consuming and error prone, since you will need to verify that the Rule is syntactically correct and is accepted by the IDS.

  • you will need to merge any changes/updates when a new revisions are published.

For each of these values IDSTower keeps what the rule text says and, separately, your override of it:

  • Each control shows the value IDSTower applies: your override when you have set one, otherwise the rule text’s.

  • A value you have overridden is marked Overridden, and the line under it says what the rule text has. Its ↺ Use the rule text’s value button removes your override; when the rule text has no such value, the button reads Remove the override.

  • A value you have not overridden reads From the rule text, or Not set in the rule text when the text has none.

  • These lines describe the rule text as it was last saved: while you edit the rule source code above, they still refer to the saved text until you save the rule.

  • Choosing the rule text’s own value is the same as removing the override: IDSTower never stores an override that repeats the rule text, so the rule keeps following its text when the vendor changes it.

When the rules are sent to the IDS Hosts or exported, IDSTower writes only your overrides into them, inserting the keyword or replacing the one in the rule text; everything you have not overridden goes out as the rule text writes it. Each override is applied while its transformation option is enabled, see Rules Transformation Options.

When the vendor publishes a new revision of the rule, your overrides and the tags you added are copied to it, so you don’t have to set them again, while the values you have not overridden come from the new revision’s text. When the vendor edits the rule text without changing its revision, those values follow the edited text.

To set the priority, target or threshold of many rules at once, select them in the IDS Rules Management Interface and use Rules Actions → Change Selected Rules Priority, Change Selected Rules Target or Change Selected Rules Threshold (Change Selected Rules Action for the action). In each of them, ticking Reset To Default removes the override from every selected rule.

A threshold is checked the way Suricata loads it before it is saved: the threshold, limit and both types need Seconds, while backoff needs track by_flow, a Count of at most 65535 and a Multiplier from 2 to 65535, and takes no seconds. backoff and track by_flow need Suricata 8 or later.

Example: you can set a threshold from the interface to reduce the amount of alerts generated by a noisy rule. IDSTower inserts it into the rule sent to the IDS Hosts, or replaces the threshold the rule text has, and keeps it on every new revision of the rule.

4. The IDS Rule Tags.

IDSTower extract various tags from rules, those tags includes references, url, hashes, CVEs…etc, it allows you as well to add tags, those added tags serves several purposes.

  • they allows you to “tag” and group rules bases on any key value pairs you choose, eg: you can Add a tag named ThreatActor with Value APT29 to all rules targeting this threat actor, this helps you maintain & group you detection logic better.

  • those tags adds more context to your analyst/engineer when they are triaging alerts, it would be super useful to know the vulnerability CVE number or malware hash value when investigating an alert.

  • those tags will be as well inserted to the final rule source code sent to the IDS hosts, specifically in the rule metadata keyword, this will means the generated alert will contain those tags, which will add more context to the generated alerts as well.