Engineering Resilient Network Detection and Response Solutions through Wazuh and High Fidelity Eve.json Metadata

Unoptimized network detection and response solutions deployed in high-throughput environments inevitably fail when unconfigured eve.json streams flood OpenSearch with millions of redundant flow and anomaly events. In a Tier 3 SOC, visibility is not the problem—signal-to-noise ratio is. When your SIEM index consumes 7.5 million daily alerts, identifying lateral movement or exfiltration becomes a forensic impossibility.

This technical guide establishes a blueprint for scaling network detection and response solutions using the Wazuh manager, Suricata, and precision metadata filtering to reduce noise by 99.9% while maintaining total forensic integrity.

Executive Summary

Modern NDR (Network Detection and Response) requires more than simple signature matching; it demands a high-fidelity pipeline that parses nested JSON metadata at wire speed. This article breaks down the architectural shift from “collecting everything” to “indexing what matters.”

• Metadata Pruning: Implementing eve-log output types to disable non-essential DNS and flow logging at the sensor level.
• Severity Routing: Utilizing Wazuh decoders to route Suricata Severity 1 alerts to high-priority indices while archiving Severity 3 events.
• Storage Optimization: Configuring logrotate and OpenSearch ILM (Index Lifecycle Management) to handle 500MB burst rotations.
• CTI Enrichment: Integrating MISP attributes for real-time IoC pivoting within the OpenSearch dashboard.

The Technical Anatomy of Network Detection and Response Solutions

At the core of open-source network detection and response solutions is the transition from raw packet capture (PCAP) to structured telemetry. Suricata’s eve.json provides a unified output format, but its default configuration is often “promiscuous,” logging every TCP flow, DNS query, and TLS handshake.

In a distributed architecture, the Wazuh agent resides on the IDS sensor (e.g., a Debian-based Proxmox VM), reading the eve.json file in real-time. The challenge lies in the Wazuh-Analysisd daemon’s ability to process these events. If the ossec.conf file is not tuned, the manager’s CPU will bottleneck, leading to dropped events and a complete loss of visibility during a high-velocity attack.

Technical Workflow: Sensor to Dashboard

Forensic Artifact Analysis

Effective network intrusion detection relies on the specific parsing of data.alert.signature, data.src_ip, and data.app_proto. When an alert is triggered, the metadata provided in the eve.json must be mapped to OpenSearch fields that allow for rapid forensic pivoting.

Log Logic: The Wazuh Configuration

To ingest Suricata logs into Wazuh, the ossec.conf on the agent must be configured for JSON format. This ensures the manager treats the log as a structured object rather than a raw string.

XML

<localfile>
  <log_format>json</log_format>
  <location>/var/log/suricata/eve.json</location>
</localfile>

Metadata Tuning for Noise Reduction

A production-ready suricata.yaml must restrict the types of events sent to the eve.json file. By commenting out flow and setting anomaly: no, we prevent the SIEM from being overwhelmed by non-security-critical telemetry.

YAML

# suricata.yaml Production Snippet
outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: eve.json
      types:
        - alert:
            payload: yes             # Essential for forensic analysis
            packet: yes              # Required for Tier 3 review
            http-body: yes
        - http:
            extended: yes
        - dns:
            enabled: no              # Disable if using dedicated DNS logs
        - tls:
            extended: yes
        - flow:
            enabled: no              # High volume, low signal
        - stats:
            totals: yes
            threads: no

IR Workflow: Detection to Eradication

The incident response cycle in high-density network detection and response solutions begins with severity-based filtering. If every alert has the same weight, the L3 analyst cannot prioritize.

Step 1: Severity Routing in OpenSearch

Using DQL (Dashboards Query Language), we filter for data.alert.severity: 1. In the Suricata ecosystem, Severity 1 indicates a high-confidence match (e.g., an ET EXPLOIT rule). In a real-world test, this reduced a pool of 7.5M events down to approximately 371 critical alerts per 10-minute window.

Step 2: CTI Ingestion and IoC Pivoting

When a suspicious src_ip is identified, the NDR solution should automatically query a MISP (Malware Information Sharing Platform) instance.

Python

# Python Snippet: MISP IoC Pivot for Suricata Alerts
import json
import requests

def query_misp(ioc_value):
    misp_url = "https://misp.solideinfo.com/attributes/restSearch"
    headers = {
        "Authorization": "YOUR_API_KEY",
        "Accept": "application/json",
        "Content-Type": "application/json"
    }
    query = {"value": ioc_value, "type": "ip-src"}
    
    response = requests.post(misp_url, headers=headers, json=json.dumps(query))
    if response.status_code == 200:
        return response.json().get('response', [])
    return None

# Logic: If data.src_ip matches MISP attribute, escalate to P1

Step 3: Persistence with Logrotate

To prevent disk exhaustion on the sensor, a strict logrotate policy is required. High-volume eve.json files should rotate based on size rather than time.

Bash

# /etc/logrotate.d/suricata
/var/log/suricata/*.json {
    size 500M
    rotate 3
    missingok
    nocompress
    create 0640 suricata suricata
}

Scaling with AI/LLMs

Integrating LLMs into network detection and response solutions allows for automated alert summarization. Instead of an analyst reading a raw JSON blob, an LLM can parse the payload field and the rule.groups to provide a natural language summary of the threat.

Enterprise vs. Open Source Tooling Comparison

While enterprise network detection and response solutions like Darktrace or ExtraHop offer “out-of-the-box” AI, a custom Wazuh/Suricata stack provides superior forensic granularity at a fraction of the cost.

Deep-Tech FAQ

Why use data.alert.severity over rule.level?

The rule.level is a Wazuh-specific metric (0-15), whereas data.alert.severity is the native Suricata priority. For NDR operations, native severity is often more accurate for signature-based detection.

How do I handle “SURICATA IPv4 truncated packet” alerts?

These are typically caused by MTU mismatches or NIC offloading (GRO/LRO). Disable offloading on the mirror interface to eliminate these false positives:

ethtool -K ens19 gro off lro off tso off

Can I ingest MISP data directly into Wazuh?

Yes, using a custom integration script in /var/ossec/integrations/, you can cross-reference every alert against MISP attributes in real-time.

Architecting elite network detection and response solutions requires a relentless focus on data hygiene. By mastering the eve.json metadata fields and implementing strategic severity routing within Wazuh and OpenSearch, security architects can build a defense-in-depth pipeline that identifies advanced persistent threats while maintaining a high-performance, low-noise environment for Tier 3 operations.

Implementing these network detection and response solutions ensures your infrastructure remains resilient against modern adversarial techniques and provides the forensic depth necessary for rapid post-incident remediation.