| Solution |
When a rule has been created or modified, it is good practice to optimize and test it before activating it, as well as to check for errors by following the next steps:
- Optimize the rule.
- Go to Resources -> Rules, select the involved rule, and select 'Edit'.
- In 'Step 2: Define Condition', narrow down the most the time window as per requirements
- In filters:
- Avoid the usage of REGEX operators as much as possible as they require heavy computing resources. Use the CONTAIN operator instead.
- Set the filter with at least an 'Event Type' attribute and set other attributes to have accurate incidents and less memory used where possible
- Define a category and choose one of the four (Availability, Performance, Change, Security ) to make sure the incident will be displayed in Explorer View.
- Test the rule.
- Go to Resources -> Rules, Select the involved rule, and deactivate it.
- Then select the More -> Test button.
- Paste the raw event log that should trigger the rule and select 'Test Rule'.
- Wait a moment and check for the test result in the tab.
- If the rule cannot be parsed, review its definition.
- If the rule is not triggered, review the filter of the definition or the raw event log of the test.
When the test result is as expected, activate it.
- Check rule activation.
- Go to the FortiSIEM login portal and log in as a full admin user.
- After, on the browser address field, enter the following (replace super_ip with the IP of the super): https://super_ip/phoenix/rest/dataRequest/rule.
- If any exception is defined, check https://super_ip/phoenix/rest/dataRequest/ruleException.
- Wait for the XML file to be loaded and displayed, then search (Ctrl + F) for the rule name that should be activated.
- If there, check for its filter definition and make sure it's the expected definition.
- If it is not present, go to step 4 and check for errors in the logs.
- Check for errors in the logs.
- Access the FortiSIEM SSH console on super.
- Run the command:
tail -1000f /opt/phoenix/log/phoenix.log | grep PHL_ERROR | grep phRule
- From the GUI at Resources -> Rules, select the involved rule and deactivate/activate it.
- Check for errors in the console.
If errors are displayed like PH_RULEMOD_SINGLE_EVENT_CONSTRAINT_INVALID, check the details of the error and review the rule definition of the filter involved. If difficulties are encountered in identifying the rule from the filter in the log, follow section 5.
- Identify rules involved by CONSTRAINT_INVALID errors.
The logs may contain several errors with details of the filter but not the name of the rule. The steps here describe how to identify the rule:
- List all the constraints in errors from the SSH console with the following command
grep PH_RULEMOD_SINGLE_EVENT_CONSTRAINT_INVALID /opt/phoenix/log/phoenix.log | sed s'#.*\[task\]=##'g | sort -u
- From this list, identify keywords to search in the rule definition.
- Run the next command from super CLI as root to list rule names ( replace KEYWORD with the keyword identified previously in the filter from the error log).
psql -U phoenix phoenixdb -c "select ph_drq_rule.id,ph_drq_rule.name,ph_drq_rule.owner_id,ph_drq_rule.active from ph_drq_rule join ph_drq_rule2event_filter on ph_drq_rule.id=ph_drq_rule2event_filter.rule_id join ph_drq_filter on ph_drq_rule2event_filter.event_filter_id=ph_drq_filter.id where (ph_drq_filter.single_constr ilike '%KEYWORD%' or ph_drq_filter.group_constr ilike '%KEYWORD%') and ph_drq_rule.active='t' and creation_type=1;"
- Go into the GUI at Resources -> Rules, search for the rule names listed before, review the definitions and renew steps from section 1.
|
