Network Security Monitoring: Building Visibility Across Enterprise Infrastructure

The Case for Network Visibility

Host-based security monitoring through SIEM agents and EDR provides excellent endpoint visibility, but attackers increasingly use legitimate network protocols and cloud services to move laterally and exfiltrate data in ways that host-based tools may miss. Network security monitoring closes this visibility gap by analyzing the traffic itself — not just endpoint events.

At PostEx, we layered network monitoring (Security Onion + Suricata + Zeek) on top of our host-based Wazuh and Splunk deployments to achieve comprehensive east-west visibility across all network segments. This layered approach caught several threat behaviors that host-based monitoring missed.

NSM Architecture

Network Tap / SPAN Port
        |
        v
Security Onion Sensor
  |-- Suricata (IDS: signature-based detection)
  |-- Zeek (Protocol analysis: behavioral detection)
  |-- Strelka (File extraction and analysis)
        |
        v
Elastic Stack (Storage + Visualization)
        |
        v
SOC Analyst Investigation Workflow

SPAN Port Configuration

# Cisco switch - configure SPAN port to mirror traffic to NSM sensor
# Monitor all traffic on core switch
monitor session 1 source interface GigabitEthernet0/1 - 0/24
monitor session 1 destination interface GigabitEthernet1/1

# MikroTik SPAN equivalent
/tool sniffer
set filter-interface=all streaming-enabled=yes streaming-server=192.168.1.50
/tool sniffer start

NetFlow Analysis for Threat Detection

NetFlow provides metadata about every network connection (source/destination IP, port, protocol, bytes, packets) without capturing payload content. It is invaluable for detecting beaconing, lateral movement, and data exfiltration even in encrypted traffic.

# Enable NetFlow on MikroTik router
/ip traffic-flow
set enabled=yes interfaces=all
/ip traffic-flow target
add dst-address=192.168.1.50 port=2055 version=9

# nfdump queries for threat hunting
# Detect top talkers
nfdump -R /var/log/nfcapd/ -s ip/bytes -n 20 -o extended

# Detect beaconing (regular intervals to same dest)
nfdump -R /var/log/nfcapd/ "host suspicious.ip"   -A srcip,dstip,dstport -s flows/flows -n 50

Firewall Log Analysis

Firewall deny logs are gold for network threat hunting. Denied outbound connections often indicate malware C2 beaconing or lateral movement attempts that your perimeter is blocking.

# Splunk SPL: Top denied destinations from internal hosts
index=network_firewall action=denied direction=outbound
| stats count by src_ip, dest_ip, dest_port, protocol
| sort -count
| where count > 100
| eval hunt="Potential C2 or scanning activity"

# Kibana: Denied inbound attempts by source country
KQL: event.dataset:firewall AND network.direction:inbound AND event.outcome:failure
| Date histogram + geolocation heatmap

VLAN Segmentation and Security

Proper VLAN segmentation is the most effective network control for limiting lateral movement. Our segmentation model at PostEx:

• VLAN 10 - Corporate Endpoints - Employee workstations, filtered internet access
• VLAN 20 - Servers - Production servers, strict access control from VLAN 10
• VLAN 30 - Management - Network devices, hypervisors - jump host access only
• VLAN 40 - DMZ - Public-facing services, no direct access to internal VLANs
• VLAN 99 - Security Monitoring - NSM sensors, SIEM infrastructure, isolated

# MikroTik ACL: Block Corporate VLAN from directly accessing Server VLAN
# (must go through application layer controls)
/ip firewall filter
add chain=forward in-interface=vlan10 out-interface=vlan20   protocol=tcp dst-port=22,3389,5985 action=drop   comment="Block admin protocols from corporate to servers (use jump host)"

Monitoring Encrypted Traffic

With most traffic now encrypted via TLS, traditional payload inspection is limited. Modern NSM relies on metadata-based detection:

• JA3/JA3S fingerprinting - Fingerprint TLS client/server hellos to identify malicious clients (Cobalt Strike, malware families)
• Certificate analysis - Self-signed certs, recently issued certs, suspicious CNs indicate C2
• JARM fingerprinting - Server-side TLS fingerprinting to identify C2 infrastructure
• Traffic volume and timing - Beaconing analysis works regardless of encryption