Slips: Behavioral Evidence Aggregation for Network Security

Slips is a network intrusion detection system that builds host-centered behavioral profiles and organizes activity into time windows. It uses a modular architecture in which independent modules report evidence rather than generating final alerts directly. Slips then accumulates this evidence into host-level decisions. The paper evaluates Slips against Suricata on an expert-labeled PCAP dataset. At the profile-time-window level, Slips achieved 83% higher recall and a 70% higher F1 score than Suricata, while neither system produced false positives. These results indicate that time-window-based evidence accumulation can produce context-aware decisions that better align with expert judgment.

The core Slips architecture consists of four major parts that are continually running in parallel: (1) input processing and profiling, (2) detection modules, (3) evidence ensembling and alerting, and (4) active response and exporting. In the input processing and profiling part, network traffic enters through the input process in various formats, such as PCAP and Zeek logs. The profiler converts the input traffic into a common internal flow format, creates the host profiles and time windows, stores the resulting records in the database, and dispatches the flows to the modules using a pub/sub architecture. The profiler code creates a behavioral profile structure for each observed source IP address and partitions its activity into time windows (by default, 1 hour). This means that each profile-time-window groups all the activity of that source IP. This lets Slips analyze behavior as a continuous process rather than just treating a host as infected or not. New flows are assigned to the profile by timestamp, including late or out-of-order arrivals. A profile, therefore, represents host behavior over time rather than a single connection.

Slips currently has 24 independent modules, including behavioral and ML-based detectors. Each module runs as a separate process and has access to both Redis and SQLite through a shared database interface. Each detection module focuses on a specific behavioral family and emits evidence when it finds suspicious activity. Evidence is a detection that may include one or more flows and is sent to the evidence handler rather than triggering a response. Most modules use heuristic behavioral and adaptive rules rather than stateless ones. They maintain a state for each profile and time window, and update their detections as new events arrive. As a result, their decisions depend on the number and timing of related events, rather than on a fixed property of a single packet or flow. Each evidence generated by a module must have a threat level (Info, Low, Medium, High, and Critical) and confidence (from 0 to 1). The Info threat level indicates they are worth reporting, but do not pose a direct threat so they don't count towards the alert score. Critical evidence contributes significantly to the score required to generate an alert.

Slips combines evidence from different detection methods. It does not average model probabilities or require its detectors to share features. Instead, every rule, ML model, behavioral detector, and threat-intelligence module converts its result into an evidence object and sends it to the evidence handler process for processing. Each evidence item includes the detection type, attacker, and optional victim, profile, time window, threat level, confidence, timestamp, detection method (e.g., AI or behavioral), relevant protocol and ports, and identifiers of the supporting flows. The evidence handler validates each new evidence item before it is accumulated. It applies the configured whitelist and ignores informational evidence when computing the score. For decision-making, Slips maps low, medium, high, and critical threat to 0.2, 0.5, 0.8, and 1.0, respectively. Evidence i contributes si = ti ci, where ti is this threat value and ci ∈ [0, 1] is detector confidence. The ensemble score for profile p and time window w is Sp,w = Σi si over eligible evidence assigned to that profile and window. When Sp,w reaches the configured alert threshold, the handler creates an alert containing the profile, time window boundaries, accumulated score, and identifiers of all contributing evidence. Thus, a high-confidence GRU detection can contribute strongly, a low-confidence or flow-level ML result contributes less, and several independent ML and non-ML findings can jointly cross the threshold. No individual model is allowed to make the final alerting decision on its own.

The evaluation contains two sets of packet captures with different purposes. The first set contains three controlled vertical port-scan captures and evaluates whether the architecture represents the behavior distributed across flows as accountable evidence. The second set contains malware and benign captures and compares the detection decisions of Slips and Suricata. For Portscans-1, Slips generated two scan evidence items and raised no alerts because the accumulated evidence did not reach the configured alert threshold. For Portscans-2, Slips generated one scan evidence item and also raised no alerts. Finally, for Portscans-3, Slips generated five evidence items, but raised no alerts. For Slips, this is the expected behavior when dealing with port-scans: Slips recognizes the port-scan behavior and stores evidence items, but it does not treat one isolated scan as sufficient for a host-level alert. In contrast, Suricata raised zero alerts across Portscans-1–Portscans-3.

At the flow level, Slips produced 3,610 true positives and 37,834 false negatives, resulting in a recall of 8.71e-2. It also produced 2 false positives and 78,740 true negatives, yielding a precision of 9.994e-1, an FPR of 2.5e-5, and an F1 score of 1.603e-1. Suricata produced 68 true positives and 41,376 false negatives, resulting in a substantially lower recall of 1.6e-3 and an F1 score of 3.3e-3. It produced the same 2 false positives and 78,740 true negatives, with a precision of 9.714e-1 and an FPR of 2.5e-5. Thus, Slips achieved substantially higher malicious-flow coverage without increasing the number of false positives. At the profile-time-window level, Slips produced 33 true positives and 136 false negatives, achieving a recall of 1.953e-1 and an F1 score of 3.268e-1. Suricata produced 18 true positives and 151 false negatives, yielding a recall of 1.065e-1 and an F1 score of 1.925e-1. Both systems produced 0 false positives and 1,495 true negatives, resulting in a precision of 1 and an FPR of 0. Overall, Slips performed better than Suricata at both evaluation levels because it achieved higher recall and F1 scores while maintaining the same negligible or zero false-positive rate.

The paper makes seven contributions: (1) Modular architecture for network security analysis in which detectors, ML models, exports, and responses are connected through shared behavioral states. (2) A description of host profiles based on time windows as the main analysis entity. (3) An adaptive evidence ensemble method in which diverse modules, including an online ML flow classifier and a multi-flow ML recurrent model, produce accountable evidence as behavior evolves, and of how Slips accumulates that evidence into host-level alerts. (4) A mechanism that allows end users to adapt and extend the training of ML models using their own traffic. (5) Organization-level whitelisting that allows users to exclude alerts and block requests to or from domains, IPs, and certificates across multiple protocols. (6) Comparison between Slips and Suricata using PCAP files from the IDSEVAL dataset. (7) New dataset to evaluate IDS systems, including a new labeling framework and a new performance comparison tool.

Improvements to AI Systems:

1. Time-Windowed Behavioral Profiling: Replace single-connection or single-packet analysis with continuous, time-windowed host profiles. The AI system groups all activity of a source IP into windows (e.g., 1 hour), enabling it to detect slow, distributed, or multi-stage attacks that appear benign at the flow level but are suspicious over time.

2. Modular Evidence Accumulation with Weighted Confidence: Implement an ensemble where independent detectors (heuristic, ML, threat-intel) emit evidence objects with threat level and confidence, rather than making final decisions. The system accumulates evidence using a score S = sum (threat value times confidence) per profile-window, and only triggers an alert when a configurable threshold is crossed. This prevents any single model from causing false alerts and allows weak signals from multiple detectors to jointly reach a decision.

3. Context-Aware Alerting with Zero False-Positive Bias: Design the system to prioritize recall at the profile-time-window level (achieving 83% higher recall than Suricata) while maintaining zero false positives. The improved AI system can flag hosts as suspicious based on accumulated behavioral evidence, not just individual flows, aligning decisions with expert judgment.

4. Adaptive and Extensible ML Training: Allow end users to retrain or fine-tune the ML detectors (e.g., the online flow classifier and multi-flow recurrent model) on their own traffic. This makes the AI system domain-adaptive, improving detection for specific network environments without requiring full system redesign.

5. Organization-Level Whitelisting Across Protocols: Integrate a whitelist mechanism that excludes alerts and blocks requests based on domains, IPs, and certificates across multiple protocols (DNS, TLS, HTTP). This reduces noise and prevents the system from wasting resources on known-benign entities, improving precision.

6. Accountable Evidence Tracking: Each alert includes identifiers of all contributing evidence, detection methods, and supporting flows. The improved AI system can provide full traceability for every decision, enabling security analysts to audit, validate, and refine the system’s reasoning.

7. Parallel Modular Architecture for Scalability: Run detectors, evidence handler, and response modules as independent parallel processes with shared state (Redis/SQLite). This allows the AI system to scale horizontally, process high-throughput traffic, and add new detectors without downtime.

What the Improved AI System Can Do:

• Detect slow and distributed attacks (e.g., port scans, C2 beaconing) that evade flow-level IDS, by analyzing host behavior over time windows.

• Generate host-level alerts only when multiple independent signals (behavioral, ML, threat-intel) agree with sufficient confidence, drastically reducing false positives.

• Adapt to new network environments via user-driven ML retraining and whitelisting, improving accuracy without manual rule tuning.

• Provide explainable, evidence-backed alerts with full audit trails, enabling security teams to trust and act on detections.

• Operate in real-time on high-volume traffic using parallel processing, while maintaining a near-zero false-positive rate and higher recall than traditional signature-based systems.

Network intrusion detection systems often analyze individual packets or flows, although malicious behavior may develop across many connections and over time. This may limit their ability to combine isolated detections into a coherent assessment of host behavior. Packet-level features may also be too low-level for complex AI-based detection, requiring additional processing to improve accuracy while maintaining a low false-positive rate. We present Slips, a network intrusion detection system that builds host-centered behavioral profiles and organizes activity into time windows. It uses a modular architecture in which independent modules report evidence rather than generating final alerts directly. Slips then accumulates this evidence into host-level decisions. We evaluate Slips against Suricata on an expert-labeled PCAP dataset. At the profile-time-window level, Slips achieved 83% higher recall and a 70% higher F1 score than Suricata, while neither system produced false positives. These results indicate that time-window-based evidence accumulation can produce context-aware decisions that better align with expert judgment.