7.5.4. Analysing the Sigflow alerts

7.5.4.1. Introduction

For information, see the following paragraphs:

7.5.4.1.1. Management of the Sigflow engine

To view the engine Status, see the View the status of Sigflow paragraph.
To update the engine, see the Engine update paragraph.
To configure the engine, see the Sigflow configuration paragraph.

7.5.4.1.2. Events generated by the engine

The events generated by Sigflow are:

Events of type "alert" when the engine has found a match with the signature defined in the alert rules
Events of type "fileinfo" when the Sigflow engine has reconstructed the network flow files
Events of type "metadata" when the Sigflow engine has recognized the network flow protocols

7.5.4.1.2.1. Events of type "alert"

Events of type "alert" are generated when the engine has found a match with the signature defined in the alert rules.

These are displayed:

In the main interface named WEB UI on the GCenter in the `Alerts` screen

The main interface named WEB UI is described in Overview of the WEB UI.

It is possible to view the found signature and its definition.
- To view the alerts, select the `Sigflow` filter.
  
  See the presentation of the Web UI `Alerts`.
- Click on the selected alert.
  
  The `Alert details` window is displayed.
  
  The detailed information of this alert is displayed: see compteurs_alerte_sigflow.
In the interface named Kibana UI
- In the main interface WEB UI, to view the alerts, select the `Sigflow` engine filter.
  
  The screen displays only the list of Sigflow alerts.
- After selected the alert, click on the `Open flow details` command of the `Actions` menu.
  
  See the presentation of the Web UI `Alerts`.
  
  Kibana is opened on the `Sigflow` category of the `Alerts ` section.
  
  The interface displayed is the interface named Kibana UI (described in Overview of the Kibana GUI).
- Click on the `Messages` tab.
  
  The Kibana database is filtered with the filters:
  - network.flow_id : unique ID of the flow selected
  - event.module: sigflow_alert
  This page displays all alerts detected by Sigflow in this network flow (whatever the IP adresses or the direction).
- Click on the toggle icon on the left of the alert.
  
  The `Expanded document` window is displayed.
  
  The detailed information of this alert can be viewed in table or json format.
  
  Note
  
  The Kibana UI can also be accessed without any filters via the `Hunting` icon on the left side menu bar in the WebUI.

7.5.4.1.2.2. Events of type "fileinfo"

Events of type "fileinfo" are generated when the Sigflow engine has reconstructed the network flow files.

These fileinfo events are visible in the Kibana interface.

In the main GCenter interface, in the `Alerts` screen, select the `Sigflow` engine

The screen displays only the list of Sigflow alerts.
After selected the alert, click on the `Open flow details` command of the `Actions` menu.

The Kibana interface is opened on the `Sigflow` category of the `Alerts ` section.
Click on the `Network Metadata` section then the `File Transactions` category.
Click on the `Messages` tab.

This page displays all events of fileinfo type corresponding to the reconstructed files in this network flow.
Select the arrow to the left of the event.

The detailed information of this event can be viewed in table or json format.

The Kibana UI can also be accessed without any filters via the `Hunting` icon on the left side menu bar in the WebUI.

7.5.4.1.2.3. Events of type "metadata"

Events of type "metadata" are generated when the Sigflow engine has recognized the network flow protocols.

These metadata events are visible in the Kibana interface.

In the main GCenter interface, in the `Alerts` screen, select the `Sigflow` engine

The screen displays only the list of Sigflow alerts.
After selected the alert, click on the `Open flow details` command of the `Actions` menu.

The Kibana interface is opened on the `Sigflow` category of the `Alerts ` section.
Click on the `Network Metadata` section then the protocol category (HTTP for example).
Click on the `Messages` tab.

This page displays all events of metadata type (metadata) corresponding to the detected protocol in this network flow.
Select the arrow to the left of the event.

The detailed information of this event can be viewed in table or json format.

7.5.4.1.3. Essential information to understand the context of the alert

7.5.4.1.3.1. What are the key fields of an alert and their meaning?

Before undertaking any investigation or qualification of the alert, it is essential to start by observing several elements that will provide essential information to understand the context of the alert.

These elements can be found either in the WEB UI interface or in the Kibana UI interface.

In the main interface named WEB UI of the GCenter.
- Open the `Alert details` window.
  
  The detailed procedure is given below.
- Click on the `Details` tab.
  
  The following key elements are:
  - `category` to know the alert id and severity, useful for classifying alerts
  - `sigflow` to have important information about the triggering of the alert
    
    The `metadata` section displays precisely the payload that triggers the alert.
  - `Network` for information on the protocol used to trigger the alert and also the vlan used
  - `source` and `destination` to have the elements concerning the port and ip address for the source and destination
  - For the rest of the elements, the most interesting field will be the `start` of the `flow`
    
    It allows you to select a time window to perform searches.
In the Kibana UI interface
- Open the `Alerts-Sigflow - Messages` window.
  
  The detailed procedure is given below.
  
  The following key elements are:
  - `timestamp:`
    
    This field corresponds to the time of detection.
  - `Source IP` and `Dest. IP`
    
    The IP addresses associated with the alert, source or destination, provide information about the network communication involved in the incident.
  - `Source Port` and `Dest. Port`
    
    The port associated with the alert, source or destination, provides information about the network communication involved in the incident.
  - `Sigflow affected product`
    
    Where possible, there is a product specification in relation to the alert.
    
    The accuracy of this field is very relative, it can be an apache version or elements like `Web_Browsers` or `Windows_XP_Vista_7_8_10_Server_32_64_Bit`
  - `Sigflow.signatures`
    
    This will display the alert title, the "msg" part that describes the item detected by the alert.
    
    For information, if this field contains `ET POLICY` ou `ET INFO`, consider this alert as an information alert or a low profile alert.
    
    They show that there is a configuration that does not correspond to good practices.
    
    They can be used for additional context on other alerts.

7.5.4.2. Alert handling procedure

7.5.4.2.1. How do you verify the accuracy of an alert and determine if it represents a real threat?

Sigflow uses rules to make detections.
The subject of verifying the accuracy of a Sigflow alert must be addressed and whether it represents a real threat or not involving a combination of analysis techniques.
Here are some steps to take:

Understanding the alert:
- Understand the rule that triggered the alert, source and destination IP addresses, port numbers and any additional information provided.
- All this information can be found in GCenter:
  - in the webui, in the `Alert details` window of the `Alert` screen : carefully review the details of the Sigflow alert
  - in Kibana, to better understand the alert, open the `Expanded document` window of the `Alerts ` section, `Sigflow` category, `Messages` tab
- For the record, if you have an alert containing the labels `ET POLICY` or `ET INFO`, take it as an information alert.
  
  They show the fact that there is a configuration that does not correspond to best practices.
  
  They can be used for additional context on other alerts.
Rules analysis:
- Review the rule that generated the alert.
  
  Understand the conditions that triggered the alert and the level of severity assigned to it.
  
  Some rules may be more generic and generate false positives, while others may be more specific.
- Different elements concerning false positives:
- True false positive is a rule that has been triggered and indicates a threat when there is none.
- Noisy signature is an alert triggered by normal activity that is identified but the rule has not been deleted.
  
  This can happen when, for example, a script performs automatic actions that can be associated with malicious activity if it is not performed by the monitoring machine.
Historical analysis and reference comparison:
- Examine historical data and trends.
  
  Analyze if similar alerts have been issued in the past and if there is a trend of recurring threats.
  
  Historical analysis can help identify persistent or evolving threats.
- Aggregate all alerts by machine or check the regularity of the event over time.
- By aggregating the view of alerts, look for the appearance of alerts to see if it is the only alert of this type.
  
  In case of multiple alert on this host, record it and qualify this alert.
  
  Sometimes alerts are too important and can be triggered even if there is nothing to fear.
- If there are doubts about false positives, look at the following point in the documentation «What happens if an alert from this engine is identified as a false positive» ?
- Once the assessment is complete and after determining whether the alert is recurring or not, drill down to the payload analysis.
Payload Analysis:
- Analyze the payload associated with the alert.
  
  This information will be found in the alert details (seen in the first point).
- To analyze the payload, use the following fields `Sigflow.payload_printable`.
  
  For example, to identify a malicious domain.
- Also use the `Sigflow.payload` field when the payload is coded.
  
  For example, to reconstruct and look inside an archive sent by stealer to its C2 and encode in b64.
Correlation with other events:
- It is mandatory to cross-reference alerts with logs from other engines.
  
  A tiered approach can help confirm the validity of an alert.
- To help you in this task, reduce the scope of the analysis by exploring the IP sources/destinations, the port and a time window on which the first alert was identified
Threat intelligence integration:
- To be safe and have more information to act, obtain details on orroborate alerts with known indicators of compromise (ICOs) from threat intelligence sources.
Incident Response Procedures:
- If an alert is deemed genuine, follow your organization’s response plan to mitigate and contain the threat.
- Some ideas for a more in-depth analysis of events are given in the section «What answers are needed if the threat is confirmed?»

7.5.4.2.2. How to categorize the threat based on the information collected?

The categorization of threats based on the information produced by the Sigflow engine implies:

To analyze alerts
To classify them under different threat categories

The information will have to be cross-checked to initiate other actions.

To categorize threats:

Severity Levels:
- Start by reviewing the severity levels assigned to Sigflow alerts.
  
  Many rules have predefined severity levels (e.g., high, medium, low).
  
  Use these severity levels as an initial indicator of the potential threat.
- All this information can be found in GCenter:
  - in the webui, in the `Alert details` window of the `Alert` screen : carefully review the details of the Sigflow alert
  - in Kibana, to better understand the alert, open the `Expanded document` window of the `Alerts ` section, `Sigflow` category, `Messages` tab
Classification of rules:
- Classify rules into different categories according to their purpose and the type of threats they detect.
  
  For example, rules may focus on malware, suspicious network activity, exploit attempts, or known vulnerabilities.
- For the record, if an alert contains the `ET POLICY` or `ET INFO` labels, take it as an information alert.
  
  They show the fact that there is a configuration that does not correspond to best practices.
  
  They can be used for additional context on other alerts.
- All this information can be found in GCenter:
  - in the webui, in the `Alert details` window of the `Alert` screen : carefully review the details of the Sigflow alert
  - in Kibana, to better understand the alert, open the `Expanded document` window of the `Alerts ` section, `Sigflow` category, `Messages` tab
- For the record, if an alert contains the `ET POLICY` or `ET INFO` labels, take it as an information alert.
- For the record, if you have an alert containing the labels `ET POLICY` or `ET INFO`, take it as an information alert.
  
  They show the fact that there is a configuration that does not correspond to best practices.
  
  If necessary, report the alert to your security organization.
Payload Analysis:
- Examine the payload of network packets associated with each alert.
  
  Payload analysis can reveal the nature of the threat, such as specific malware signatures, command and control communication, or malicious payload patterns.
  
  For example, to identify a malicious domain.
- Also use the field `Sigflow.payload`, it depends on the case.
  
  For example, to reconstruct and look inside an archive sent by stealer to its C2 and encode in b64.
Compromise Indicator Analysis (IOC):
- Look for indicators of compromise in alerts, such as IP addresses, domain names, file hashes or patterns specific to known malware.
  
  Cross-reference these indicators with threat intelligence flows to determine the nature of the threat.
- All this information can be found in GCenter, in the `Alert` panel or in Kibana, in sigflow under the Messages panel.
- All this information can be found in GCenter:
  - in the webui, in the `Alert details` window of the `Alert` screen : carefully review the details of the Sigflow alert
  - in Kibana, to better understand the alert, open the `Expanded document` window of the `Alerts ` section, `Sigflow` category, `Messages` tab
Behavioural analysis:
- Analyze the network traffic behaviour that triggered Sigflow alerts.
  
  Identify patterns of suspicious or malicious behaviour, such as port analysis, brute force attacks or abnormal communication patterns.
- For this part, expand the time windows and look for other alerts to better understand the behaviour.
  
  You won’t necessarily find the beginning of the attack, but with this behavioural analysis, you can use killchain to identify the stage of the attack.
Background information:
- Consider contextual information, such as source and destination IP addresses, ports and protocols.
  
  This information can provide information about the specific type of threat and the potential impact on the network.
- Also use another detection engine to help in this task.
  
  For example, Sigflow cross-reference alerts and the Malcore engine let you know what malware you are dealing with.
Incident Response Classification:
- If an alert is confirmed as a real threat, classify it according to your organization’s response classification system.
  
  This may involve categorizing incidents as low, medium or high impact and prioritizing response actions accordingly.
Documentation and Reporting:
- Document findings and create reports that summarize threat categorization.
  
  Clear documentation helps to understand the nature of threats, improve response procedures and share information with relevant stakeholders.

7.5.4.2.3. What answers are needed if the threat is confirmed?

Note

This procedure allows to deepen the investigation and assess the extent of the incident after confirmation of a threat generated by the Sigflow engine.

Follow incident response procedures if an alert is deemed genuine:

Follow your organization’s response plan to mitigate and contain the threat.
In the absence of an incident response procedure:
- Reporting and Classification:
- Record findings
- Classify the incident as low, medium or high impact
- Prioritize intervention measures accordingly
- Isolate the system:
- Isolate contaminated system immediately
- Ensure that it cannot cause further damage
- Go after threats:
- Proactive threat hunting
- Use alerts as a starting point for investigating potential threats
- Conduct in-depth analysis to uncover hidden or advanced threats that may not be immediately apparent

Because the Sigflow engine allows us to find an item on the network, with this network survey, a compromised host survey must be initiated.

7.5.4.2.4. What if an alert from this engine is identified as a false positive?

Sometimes alerts are too important and can be triggered even if there is nothing to fear.

In this case:

Check that the traffic generating the alert:
- Is legitimate
- Aligns with the normal behaviour of the network
If it appears that some rules produce too many false positives, disable them by changing the ruleset.

Important

Disabling a rule means that the threat for which the rule was created will no longer be detected.

We advise you to closely assess the risk of this operation with all stakeholders responsible for the security of the organization.

Note

This summary table shows which counters are not protocol dependent.

Table part source of Sigflow logs of alert type
Field	Required	Description	Values or example
@timestamp	Yes	Timestamp of the processing of the alert by the GCenter (corresponds to the passage in logstash)	2023-10-09T08:51:50.124Z
@version	yes	version of document	1
app_proto	No	File source flow application protocol	http
dest_ip	Yes	Destination IP address	"X.X.X.X"
dest_mac	Yes	Destination MAC address	"7e:ef:8d:eb:1a:81"
dest_port	No	Destination port. Present only when proto is udp or tcp	48740
event_type	Yes	Type of event: alert	Default alert
flow.reason	No	Mechanism that caused the flow between (“timeout”, “forced”, “shutdown” to stop processing)
proto	Yes	Layer 4 protocol used	TCP
severity	Yes	Level of alert severity	3
src_ip	Yes	Source IP address	"X.X.X.X"
src_mac	Yes	Source MAC address	"8a:f3:99:16:a0:57"
src_port	No	Source port. Present only when proto is udp or tcp	80
stream	Yes		1
Timestamp of the processing of the alert by the GCenter (corresponds to the passage in logstash)	Yes	Date and time of alert analysis by logstash	2023-10-09T08:51:50.124Z
type	Yes	Event type: default suricata	suricata
uuid	Yes	Unique identifier of the alert	1b6e03fa-d325-4f3d...

Summary table of counters in category "Alert"
Field	Required	Description	Values or example
alert.metadata	No	Alert metadata. Field specification is free.	metadata: key value
alert.severity	Yes	Level of alert severity	3
alert.signature	Yes	Description of the alert	AND INFO Python SimpleHTTP ServerBanner

List of metadata used in source alerts (alert.metadata object in ES):

alert.metadata.affected_product
alert.metadata.attack_target
alert.metadata.created_at
alert.metadata.deployment
alert.metadata.former_category
alert.metadata.impact_flag
alert.metadata.malware_family

alert.metadata.performance_impact
alert.metadata.ruleset
alert.metadata.service
alert.metadata.signature_severity
alert.metadata.tag
alert.metadata.updated_at

Here is an example of an alert that uses metadata affected_product, attack_target, created_at, deployment, signature_severity, tag et updated_at:

alert tcp $EXTERNAL_NET any -> $SQL_SERVERS 1433 (
msg:"ET EXPLOIT MS-SQL SQL Injection closing string plus line comment";
flow: to_server,established;
content:"'|00|";
content:"-|00|-|00|";
reference:url,doc.emergingthreats.net/bin/view/Main/2000488;
classtype:attempted-user;
sid:2000488;
rev:7;
metadata:affected_product Web_Server_Applications, attack_target Web_Server, created_at 2010_07_30, deployment Datacenter, signature_severity Major, tag SQL_Injection, updated_at 2016_07_01;
)