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. It is the value of the action column selected in the alarm rule (Source.IP by default).
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 incident related to the alarm.
When we examine the findings in the incident:
- 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,
- The alarm was last triggered on 2023-04-26 14:39:40.
Note: The Activities panel only shows the tabs (Events, Network, Process, File, DNS, Identity) that contain data for the incident. A missing tab means that no activity of that type was found. If there is no activity at all, the Activities panel is not displayed.
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 identity (user) activity in the Identity tab of 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 incident can be closed.