SIEM is the central security system for most organisations, network flow monitoring can help to increase companies’ defensive capabilities.
A SIEM class system is the key analytical system for detecting andanalysing security threats in an organisation. The system correlates logs frommultiple data sources (such as operating systems, databases, network devices,applications or security systems) in order to detect potential threats andsecurity compromises.
The visibility of threats in the system depends not only on the quality of logs of monitored data sources, but also on the correlations implemented. A correlation is nothing else than a sequence of defined events that indicate the occurrence of a specific security irregularity. Therefore, when collecting multiple data sources in a single location, it is important not forget about designing cross-system correlations, i.e. correlations between logs that originate from different systems but have one or more common attributes, such as an IP address.
The key sources of data, not only for NOC/SOC teams,include Network Visibility class systems, such as the FlowControl system. The main advantage of this system is the improved visibility of network anomalies and security threats on the whole organisation level. This is possible because network flows from all relevant network devices in the organisation are monitored to ensure that all network communications can be viewed. By analysing the network flows defined in the MITRE ATT&CK framework alone, as described in our article: "ATT&CK MITRE as an effective method of defence against cyber threats", more than 30 techniques used by cybercriminals can be detected. On the basis of the MITRE categorisation, security threat detection mechanisms have been created in the FlowControl system that can currently detect typical threats from seven different MITRE tactics.
As Network Visibility class systems analyse traffic generated by network flows, individual alerts from these systems may not be accurate enough for the security team to handle each individual alert. In addition, as in any system designed to detect anomalies, incorrectly tuned security rules can generate too many False Positives, which in fact can lead to the SOC team ignoring alerts from these systems after some time. On the other hand, ‘untightening the screw’, where security systems detect only obvious incidents, can lead to real threats being overlooked. So, where is the golden middle?
One of the solutions for this problem could be designing cross-system correlations in SIEM that would increase the criticality of potential security incidents and therefore their priority to be addressed. Therefore, the criticality of a single alert from the Sycope system should be different from the cross-correlation of this alert with alerts generated by other systems in the context of a specific attribute. For example, a single alert named‘Brute Force Attack:WS-Management and PowerShell remoting via HTTP’ should have a different handling priority than the same alert linked additionally to a sequence of events typical for a suspicious activity detected with the Sysmon monitoring service. The occurrence of many unwanted activities over a specified period of time often signals that the attacker has nudged some ‘cones’ that we deployed in different locations of the organisation to detect unwanted activities and increase the likelihood of detecting real violations of the organisation’s security procedures. For us, these ‘cones’ are threat detection mechanisms that should be linked to security incident handling procedures.
Cross-system correlations increase the effectiveness of threat detection by generating fewer False Positives. Network Visibility class systems are sources of valuable information for security incident analysts, or Threat Hunters, as well as for SIEM systems that correlate logs from different systems. Security alerts can be easily sent from FlowControl to SIEM as all that is required is to enter the IP address and the Syslog server port in the setup wizard. Of course, there is nothing to prevent the net workflow analysis taking place directly on the SIEM analytical engine. In this case, additional aspects need to be considered, including the expansion of the SIEM architecture to analyse billions of network flows per day, the costs of additional licences and the costs of resources needed to design the logics for detecting anomalies and security threats on the basis of flow data. Whatever path we choose, we must strive to design security rules based on as many data sources as possible, so that the number of traps left for attackers is as great as possible and consistent with the organisation’s security incident handling process. We must also remember that security is a continuous process, so there is no finite number of security scenarios that can be implemented in individual security systems to correlate them with alerts from other systems in SIEM.
%20(1).jpg)
.jpg)