Had two nearly identical searches (one for domains, and one for IPs) running to create sighting alerts in MISP, however the IP search was failing to actually create sightings.
The only difference in the results sent to the alert action was that the source for the IP events includes sub-second _time, i.e. 1570039912.009997 vs 1570039912.
"_time" was being used as the "Unique ID" field in the alert action configuration. When troublehsooting, this error was apparent in /opt/splunk/var/log/splunk/misp_alert_sighting_modalert.log:
ERROR pid=20306 tid=MainThread file=cim_actions.py:message:359 | sendmodaction - worker="<mysearchead>" signature="Unexpected error: invalid literal for int() with base 10: '1570039912.009997'.
It would appear something in cim_actions.py is expecting an int, so it is unhappy with this unique ID field including a decimal point. I realize this may not be your issue since cim_actions comes from Splunk_SA_CIM, but I figured I would post the issue here so people are aware.
As a followup: a simple | eval _time=round(_time,0) in the search is a workaround.
Had two nearly identical searches (one for domains, and one for IPs) running to create sighting alerts in MISP, however the IP search was failing to actually create sightings.
The only difference in the results sent to the alert action was that the source for the IP events includes sub-second _time, i.e.
1570039912.009997
vs1570039912
."_time" was being used as the "Unique ID" field in the alert action configuration. When troublehsooting, this error was apparent in /opt/splunk/var/log/splunk/misp_alert_sighting_modalert.log:
ERROR pid=20306 tid=MainThread file=cim_actions.py:message:359 | sendmodaction - worker="<mysearchead>" signature="Unexpected error: invalid literal for int() with base 10: '1570039912.009997'.
It would appear something in cim_actions.py is expecting an int, so it is unhappy with this unique ID field including a decimal point. I realize this may not be your issue since cim_actions comes from Splunk_SA_CIM, but I figured I would post the issue here so people are aware.
As a followup: a simple
| eval _time=round(_time,0)
in the search is a workaround.