Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
adem_netsys
Contributor

FortiSIEM: Rule sync error

Hello,

 

I cloned the existing "Windows Security Log Cleared" rule in the rules and created it in a new name, only I made the within value 120, not 600, and made the rule in the default disable. However, this time, when the rule was triggered, it created an incident with the name in the default and gave a sync error error in the rule. What could be the reason?

1 Solution
Richie_C

yes indeed. As per the documentation:

 

https://help.fortinet.com/fsiem/7-1-1/Online-Help/HTML5_Help/Notification_Settings.htm

 

"Notifications will be sent only if an incident occurs during the time range you set here."

Take a backup before making any changes

View solution in original post

26 REPLIES 26
Richie_C

It will trigger once in 24 hours if the incident is the same. For example, the source IP is the same. It will simply update the count. you can change this timer to send another notification more or less often.

 

If it is a different source, this should create a new incident and the notification should be sent for the new incident. If this is not happening it is probably either a config issue, issue sending emails, or a bug. 

Take a backup before making any changes
adem_netsys

As I think I understand, the fact that the time range remains as "any" confirms that we expect it to send mail in every different trigger, right?

Richie_C

yes indeed. As per the documentation:

 

https://help.fortinet.com/fsiem/7-1-1/Online-Help/HTML5_Help/Notification_Settings.htm

 

"Notifications will be sent only if an incident occurs during the time range you set here."

Take a backup before making any changes
adem_netsys

Hi @Richie_C 

What is the logic of the "If this Pattern occurs within 600" part in Rule 2.define, is it related to the notification time?

Richie_C

Hi @adem_netsys - This is a sliding window of time that FortiSIEM will evaluate the specific rule over.

 

Its difficult to explain concisely here, but it is well explained in the advanced analytics course on the NSE institute.

 

One thing that is important with this setting is not to be too aggressive as it can consume a lot of memory.

Take a backup before making any changes
adem_netsys

Setting the time period here has nothing to do with the notification period, do I understand correctly?

Richie_C

No it doesn't relate to the notification period.

Take a backup before making any changes
dmontgomery
New Contributor III

I am not sure what the link has to do with the issue described. I am seeing the same behaviour.

We cloned one of the system rules that was triggery a High severity alert incident. We changed the severity to low and deactivated the system rule. The System rule continues to triger high severity alerts and on the rule tab we see sync errors - timed out. See screenshot. We are not using notifications for this incident.

What is it trying to sync with and why is it behaving this way? sync errors.png

Richie_C

Hi @dmontgomery 

This conversation moved away from the initial question. In the past, some of the reasons i have seen for the issue described is as follows:

 

  • Bad rule logic (unlikely as you are only cloning an existing rule)
  • Performance related (CPU, memory, swap memory)
  • Related to workers (if you have any. Information is shared between workers and super)

I did a quick test in my lab (7.1.1) and i was able to successfully clone a rule. I did the following:

 

  • Cloned the rule
  • Changed the name
  • Changed the severity
  • Changed the incident title
  • Cleared the existing incidents

After this, I could see the events with new title and severity.

 

Regards

Take a backup before making any changes
dmontgomery
New Contributor III

It was probably performance related. I had unrelated (I thought) issue and I rebooted the super. It resolved this and the other issue I had.

Labels
Top Kudoed Authors