How to use inter-system correlations, optimizing work of SIEM systems and processing billions of flows in dedicated system.
Jacek Grymuza
From the point of view of monitoring only network flows, there is a chance to detect even about 10% of techniques used by adversaries defined in the ATT&CK MITRE knowledge base. This is quite a lot, considering that there are at least40 data sources (Figure 3) used in threat detection.
Evidence tracesof hackers activities can be observed by appropriate monitoring of networkmetadata, i.e. network flows. There are many scenarios of adversaries activitiesthat defenders (Blue Teams) can detect based on this data source. You canpractically detect activities from every MITER tactic, from Reconnaissance toImpact tactic. Examples of such threat detections implemented in the Sycopesystem in the context of specific tactics are shown in Figure 4.
In order to effectively detect security threats, it is not enough to focus only on monitoring network traffic. Alerts from a single source can sometimes ambiguously inform about a detected issue. On the other hand, overly cautiously set thresholds in correlation rules may cause some incidents to be overlooked.The solution may be an implementation of more accurate inter-system correlation rules detecting anomalies coming from various data sources occurring in a specific time unit. Therefore, inter-system correlations are more effective, especially during the operational handling of incidents by SOC, where it is important to limit the number of False Positives. Cross-correlations alerts can be prioritized for handling in the SOC, because if security anomalies are detected in the context of some parameters based on different data sources, there is a risk of a real security incident. For example, a single alert regarding a brute force attack against WS-Management service should have a different handling priority than the same alert correlated additionally with anomalies detected based on Sysmon logs (Figure 5).
The next example shows how to detect a DDoS attack more precisely. Despite the fact that many attacks of this type, especially volumetric ones, can be detected on the basis of Netflow monitoring, additional monitoring of logs from web applications clearly confirms the occurrence of such an attack.
The last example shows what network artefacts detected at the level of network flows and Sysmon logs are helpful in detecting traffic tunnelling using the DNS protocol.
Based on the above examples, we can see that network flow monitoring is an extremely valuable source of data in the process of security monitoring, as it makes it possible to detect many attack techniques used by cyber-criminals. In addition, in the correlation of network anomalies based on flows with other data sources, we receive additional confirmation of the detected threat, which at the same time will reduce the number of false positives. Network flow monitoring can be performed both with the use of a dedicated Network Security Monitoring class system, such as for example Sycope, but also directly in the SIEM class system. The first option allows for sending alerts generated by the NSM system to the SIEM, and the second one to analyze Netflow traffic directly in the SIEM system. When choosing the second option, we must adjust our SIEM environment to be able to handle hundreds of millions of flows per second and often buy additional licences. Whatever path we choose, we should strive to design security rules based on as many data sources as possible, so that the number of red flags left by attackers is as great as possible and consistent with the organization’s security incident handling process. We should also remember that security is a continuous process, so there is no finite number of security scenarios that can be implemented in any monitoring system.
This is a second part of the article, to go to the first part click in here: www.sycope.com/post/netflow-as-valuable-data-source-for-secops-part-1
.jpg)
