Introduction
This article provides a general overview of the causes and analyses of alarm triggers.
Alarm Triggering
With the Logsign Unified SecOps Platform, your logs are collected, and when a situation matches your alarm rule, your alarms are triggered.
Alarm rules are triggered by column matching within a single log line.
You can control the correlation scenarios of a data within a log line using lists within the alarm.
Let's explain this with an example.
We examine triggered alarms using the following query:
Query: DataType:alert
Let's examine the following alarm.
When the alarm log is opened, the first columns we examine are the "action" and "alert".
The object within Action.Object is the object that triggers the alarm.
To look at the triggering reason of the alarm, we examine the Alert.Reason column.
Alert.Reason provides the columns entered in the alarm rule. The alarm was triggered as the log with the values of 20.190.160.12 IP address, EventMap.Type:Attack, and EventMap.SubType:Detect, coming from SonicWall FW, matches the alarm rule.
When we examine the Alert.Category column, it shows the category information of the triggered alarm library.
When we examine the Alert.Info column, it shows the name information of the triggered alarm.
Let's check the findings by examining the case related to the alarm.
When we examine the findings in the case;
- The alarm was triggered 13 times before,
- No action was taken after the alarm was triggered,
- The risk score is low,
- The first triggering time of the alarm was 2023-04-24 23:12:36,
- We did not observe that the alarm was triggered last on 2023-04-26 14:39:40.
We observed that the 20.190.160.12 address did not create any event activity in the Activities panel.
We observed that the 20.190.160.12 address did not create any network activity in the Activities panel.
We observed that the 20.190.160.12 address did not create any process activity in the Activities panel.
We observed that the 20.190.160.12 address did not create any file activity in the Activities panel.
We observed that the 20.190.160.12 address did not create any DNS activity in the Activities panel.
We observed that the 20.190.160.12 address did not create any user activity in the Activities panel.
We observed that there is no log record on the network and system, and finally, we can also check the IP reputation control.
Let's check the risk score with Abuseipdb and Virustotal.
We observed that the source IP address does not have any risk score.
Let's check if the target source reached by the source IP address is in a p2p connection status.
No log record was found.
In the analysis conducted, it was determined that the alarm risk situation is low, and the case can be closed.