FortiSIEM fine tuning

[labsession101]

Hi,

Any tips or documentation for fine tuning the fortiSIEM rules/incident alert?
Trying to improve or add fine tuned rules / incident alerts we are getting from the fortiSIEM.

Thank you.

[Secusaurus · Accepted solution]

Hi labsession101,

Are you using a multi tenant version or enterprise version? In a multi tenant environment you need to consider that fine-tuning could (but does not need to) be different for each tenant.

Anyways, we are using the following processes here:

• Avoid making exceptions. E.g.: If a rule should not match on a specific device, either the device is in the "wrong" CMDB group or there are more general reason for not using the rule here, instead of excluding a single device.
  In our experience, the more exceptions you create, the more difficult it is to reproduce why something happened but we did not see an Incident
• Copy a rule, disable it and refine the copy. If you need to get back to the original one, you can also get the original idea again.
• (generally for rules) Avoid inserting single values, like an exact IP address. Try to use CMDB/resource values as often as possible to be flexible for other tenants
• We do always write down changes to rules in a separate document/wiki. Ca. once a month, we review all the refined rules, if the refinement still makes sense.

Does this help? Or are you looking for specific examples of refinements here?

Best,

Christian

[Secusaurus · Accepted solution]

Hi labsession101,

Are you using a multi tenant version or enterprise version? In a multi tenant environment you need to consider that fine-tuning could (but does not need to) be different for each tenant.

Anyways, we are using the following processes here:

• Avoid making exceptions. E.g.: If a rule should not match on a specific device, either the device is in the "wrong" CMDB group or there are more general reason for not using the rule here, instead of excluding a single device.
  In our experience, the more exceptions you create, the more difficult it is to reproduce why something happened but we did not see an Incident
• Copy a rule, disable it and refine the copy. If you need to get back to the original one, you can also get the original idea again.
• (generally for rules) Avoid inserting single values, like an exact IP address. Try to use CMDB/resource values as often as possible to be flexible for other tenants
• We do always write down changes to rules in a separate document/wiki. Ca. once a month, we review all the refined rules, if the refinement still makes sense.

Does this help? Or are you looking for specific examples of refinements here?

Best,

Christian

[labsession101]

Hi Chris,

Thank for your inputs. Will take these into consideration.
This is an enterprise deployment only so no other tenants needs to be considered.

So far what we have tried is to clone the default rule and edit it per our requirement.

was looking for other way or better way making fine tuning,

[FSM_FTNT]

There are some very good tips here about cloning and modifying the rule. Tracking why you made a change to a rule in a wiki is a very good approach. I've seen users put a link into the Description or Remediation notes to the wiki on what changes were made, why they were made and specific steps that should be taken if the rule triggers.

[labsession101]

In case of setting email alert, do you set to send all email alert or you just pick the high and medium incidents? (assuming this is a freshly deployed one)

although I was thinking that sometimes low incident like credentials invalid login should be part of email alert even this one is tagged as low in fortisiem.

[Secusaurus · Accepted solution]

Hi labsession101,

No, we don't send all incidents per mail (btw: use the mail encryption feature for this), because this would be an immense load to look through. Looking at the incidents on FSM itself is way better (assuming you have analysts that look at these all the time).

Our analysts receive the HIGH prio incidents, if they want, but only the "active" states. Our supervisors receive the HIGH prio with "clear" events as well, if they want.

But most notifications from our FSM deployment are from cases, not from incidents.

Best,

Christian