# Data-Driven Network Anomaly Detection with Cyber Attack and Defense Visualization
## 4 Methodology and Implementation
### Malicious Connection Defense  
A simple mitigation approach for dealing with malicious connections would include the termination of malicious connections, but this can be insolent, particularly for false positives. Additionally, the termination only gives an attacker feedback to try other options. One of the best alternatives we found and adopted to achieve high resilience to compromised hosts without relying on static or localized network information is [56], which proposes a polynomial-based compromise-resilient en-route filtering scheme against false data. Therefore, to achieve MO-4, i.e., mitigation of attacks in the _resolve-module_, we place a compromised hosts report \(R_{FR_{C_{i}}}\) from Equation (14) on the main network controller verifiable by intermediate hosts through: _Condition 1_: Message authentication polynomial (MAP) on the compromised host \(FR_{C_{i}}\), _Condition 2_: Timestamp \(T\) on network controller. \(R_{FR_{C_{i}}}\) is obtained by:  
\[R_{FR_{C_{i}}}=auth_{C_{i}}|T \tag{18}\]  
where \(auth_{C_{i}}\) is the MAP stored in host \(i\). Using the proposed approach of handling malicious connections in [57] that takes over malicious connections as a transparent proxy by migrating TCP states to a user-level TCP stack, we design our malicious connection resolve module to attract packets from compromised hosts by fallaciously claiming fresh shortest packet routes but not forwarding them onward. This is achieved through a neighboring host having an EC to the compromised host, as described in Section 4.7,always responding to a malicious host \(FR_{C_{i}}\) route request (RREQ), with the best alternative route reply (RREP). Despite the process just described, to stop routing packets through a compromised connection, any RREP of a fresh route from any malicious host is dropped. We assume that this process continues until the security analyst takes the compromised host off the network for subsequent malware check. To prevent resource lock-up in case of a delayed malware check response from a security analyst, we purge malicious connections through timeout guidelines proposed in [58]. We use a timeout configuration that accommodates RFC 2988 [59] dynamics as \(1.0\leq\tau\leq 11.0\), where \(\tau\) is the timeout value in seconds. The value for \(\tau\) is adaptively set based on different settings checked at time \(t\), with the total number of entries \(E_{t}\) given by:  
\[E_{t}=N_{t}+\lambda\tau \tag{19}\]  
where \(N_{t}\) denotes the benign connection and \(\lambda\) denotes the malicious connection rate. Effectively, \(FR_{C_{i}}\) cannot process the threats described in Section 3.3 as the packets are absorbed and dropped without forwarding. As the attack is mitigated, Algorithm 2 explains this module together with our stated parameters to show how available resources are visually recognized at given time intervals. We propose this defense strategy to handle all malicious connections and then, in our display system, transform the connection color from red to blue, and size from double to single, once malicious connection activities are nulled with dropped packets.