Flowmon Incident Response

This document is aimed at operators and analysts who use Flowmon to detect and analyse security events.

The document assumes that the Flowmon system is correctly deployed and configured to eliminate so-called false positives, its operator has adequate technical training in computer networks and the family of TCP/IP protocols, and has been trained in their everyday work with the system. This document is not a replacement for the user manual.

Recommendations and procedures are based on the NIST Cybersecurity Framework, which provides a comprehensive methodology for securing the digital environment of organisations. NIST defines the individual functions necessary to ensure cybersecurity.

• Identify - analysing the cybersecurity state of the organisation, evaluating technologies and processes, identifying assets, risks, proposing draft measures
• Protect - implementing measures to ensure protection (preventive measures) against cybersecurity incidents
• Detect - detecting cybersecurity incidents that overcome preventive measures
• Respond – responding to a security incident including determining the scope and design of measures, minimising the impact of a cybersecurity incident
• Recover - recovery from a security incident, data and system production status recovery

Source: NIST, The Cybersecurity Framework Version 1.1

Flowmon covers the "Detect" and "Respond" phases, with the "Recover" phase supported by monitoring the current state of network traffic and by the built-in analytics. Flowmon ADS (Anomaly Detection System) is used to detect cybersecurity incidents, which enables you to automatically identify anomalies and present these anomalies in the form of events. Identified events can be analysed directly in the Flowmon UI (which is the subject of this document) or passed to third-party log management or SIEM systems for correlation and processing together with security events from other systems such as firewalls, antiviruses, etc.

Workflow Analysis of Security Incidents

The following example shows the detection of events that correspond to individual anomalies and are categorised according to the character of network traffic that has been evaluated as anomalous. Each event is assigned a priority, and these events are grouped by category.

Step 1: Identify the originator, context and analysis of the attack

In the analysis of events we proceed according to the severity (for the events we see C = critical, H = high, ...) and analyse the individual categories of the events, the originator of the event and identify the device responsible for the event. Here, the most serious event is an attack on the SSH service to gain unauthorised access to a device or system on the network. The attacker is trying to compromise a larger number of devices in the network, gain persistent access, higher user permissions, etc. We have identified an attacker with the IP address 192.168.1.100 and the target of the attack with the IP address 192.168.1.225.

In the event’s detail, we can get a lot of additional information (if available) such as the relevant device by IP address, device domain name, device domain name recorded at the time of detection, the physical address of the device (MAC address) and user identity. Based on the information provided, we will determine the actual relevance and severity of the incident.

The IP addresses identified as the source or target of the event will then be used in the event search filter and we will look at the overall picture of related event activities. A convenient way of sorting is on the basis of the timestamp of detecting the event. Detected events allow us to reconstruct the activity of the attacker, identify the targets of the attack, estimate its intentions, and choose a suitable defence strategy.

The example shows the IP address of an attacker or infected device that first simulated the DHCP server function and assigned a spoofed network configuration to the device 192.168.1.225. This fact is revealed in the following event where a device with an IP address of 192.168.1.225 is used by the attacker as a DNS server. The following activities of the attacker include identifying additional attack targets (ARP scan) and identifying services available on the gateway (IP 192.168.1.1) and on the victim (IP 192.168.1.225). The following activity is an attack on the SSH services to gain unauthorised access. This attack proves to be successful; the attacker presumably used information captured from the communication of the device 192.168.1.225 over the network.

Step 2: Analyse related data flows

The attacker's activities in the monitored environment may be wider than the range of events detected by the Flowmon ADS module. All the activity of an attacker, compromised stations and the general impact of security incidents can be analysed in the Flowmon Monitoring Center, which records, archives and visualises data network traffic in the form of data flows.

Using the information obtained in the previous step, we can identify all the communication on the data network of the attacker with the IP address 192.168.1.100 and present it in the form of a summary as a graph and as a detailed chart. In this way, we can identify all the communications, potentially affected systems and activity of the attacker and any other potentially compromised systems.

We recommend exporting the data obtained by this analysis for long-term archiving or handing over to authorities for investigating an attack or security incident.

Closing Comments

The Flowmon ADS module can be integrated with CMDB systems that record information about the assets of a given environment with a web link for finding information about a given device. This is the recommended procedure for quickly identifying devices and obtaining the necessary context directly when analysing security incidents.

If a security incident analysis reveals a false detection, we recommend updating the Flowmon ADS configuration by defining a new false positives rule.

Related Articles:

What is Network Detection and Response (NDR)?