Wire-Level Intelligence: How WireTrace Analyzes Network Traffic

1. Introduction

Network visibility has traditionally relied on two approaches: agent-based telemetry (requiring software on every endpoint) and active scanning (sending probes to discover devices and vulnerabilities). Both approaches fail in environments where agents cannot be installed (industrial controllers, medical devices, IoT) or where active probing creates operational risk (safety-critical OT networks, clinical environments).

WireTrace takes a fundamentally different approach: it builds on passive deep packet inspection at the wire level and extends it into Deep Protocol & Asset Intelligence (DPAI) - protocol semantics plus asset identity. By analyzing a copy of network traffic from a SPAN port or network TAP, WireTrace extracts device identity, protocol commands, certificates, behavioral patterns, and security findings. The sensor operates in receive-only mode on its capture interface - zero packets are transmitted onto the monitored network. Sensor-to-server communication occurs over a separate management interface, and optional SNMP enrichment and Bahith active scanning, when an operator enables them, transmit from the management interface only and are off by default.

This paper describes the technical architecture and methodology behind WireTrace's core intelligence engines: Protocol Intelligence, Asset Classification, Behavioral Baselines, Threat Detection, and Compliance Evidence Generation. It also addresses visibility boundaries, encrypted traffic handling, and deployment considerations.

2. Platform Architecture

WireTrace uses a distributed sensor-server architecture. Sensors capture and parse traffic at the network edge; a centralized server performs classification, analytics, threat detection, and compliance evidence generation.

3. Protocol Intelligence Engine

The foundation of WireTrace is its deep packet inspection engine - a high-performance native parser library that decodes network protocols at the application layer. Unlike port-based identification (which maps port numbers to assumed services) or signature matching (which looks for known byte patterns), WireTrace performs application-layer protocol dissection for supported protocols - parsing each protocol's grammar to extract structured fields from unencrypted protocol sessions.

3.1 Parsing Architecture

The DPI engine operates in a pipeline: raw packets are captured from the SPAN/TAP interface, reassembled into protocol sessions, and passed through protocol-specific parsers. Each parser understands the protocol's message structure and extracts fields relevant to asset identification, security analysis, and operational monitoring.

3.2 Protocol Depth Matrix

WireTrace supports 250+ protocols across four domains. The depth of extraction varies by protocol type and encryption state:

4. Encrypted Traffic and Visibility Boundaries

Passive deep packet inspection operates on a copy of network traffic as it appears on the wire. This means the depth of analysis depends on whether the application payload is encrypted.

5. Multi-Signal Asset Classification

Asset classification in WireTrace is performed by a weighted voting engine that combines multiple independent signals to produce a confident device identification. This approach is fundamentally different from single-signal methods (MAC OUI lookup, banner grabbing, or agent-based fingerprinting).

5.1 Classification Signals

Each observed device accumulates evidence from multiple sources:

• Protocol behavior: Which protocols the device speaks, how it speaks them, and what role it plays (client/server, master/outstation, publisher/subscriber)
• DPI-extracted identity: Vendor and model information parsed from protocol fields (S7Comm SZL data, ENIP ListIdentity, PROFINET DCP, LLDP system description)
• MAC OUI: Vendor prefix from the device's MAC address - used as supporting evidence, not as the sole classifier
• DHCP fingerprint: Hostname, vendor class, requested options from DHCP transactions
• mDNS/SSDP/NBNS: Service announcements, device descriptions, model identifiers from discovery protocols
• TLS handshake data: Certificate fields from TLS 1.2 connections; SNI, cipher suite, and JA3 fingerprint from all TLS versions
• HTTP User-Agent: Browser, OS, and application identification from HTTP headers
• Behavioral patterns: Communication timing, protocol mix, peer relationships, and data volume patterns

5.2 Weighted Voting

Each classification signal carries a priority weight (1-200) based on its reliability and specificity. DPI-extracted identity from industrial protocols (e.g., S7Comm SZL returning "Siemens S7-1200") carries a high priority (100+), while MAC OUI (which only identifies the vendor, not the model or function) carries a lower priority (50).

Multiple rules can vote on the same device. The classification engine resolves conflicts by selecting the highest-priority match, with tie-breaking based on signal specificity. This means a Philips ventilator behind a VMware virtual NIC is correctly classified as a medical device - not as a VMware server - because the proprietary Philips protocol fingerprint outweighs the MAC OUI.

5.3 Classification Rule Structure

Classification rules are defined in YAML and organized by domain (industrial, medical, enterprise, IoT). Each rule specifies match conditions (which protocols, which field values, which OUI prefixes) and outputs (device type, vendor, model, Purdue level, domain). As of version 1.3, 427 classification rules across 13 domain-specific rule files cover industrial controllers, medical devices, enterprise infrastructure, and IoT endpoints.

6. Behavioral Baseline Engine

WireTrace establishes per-device, per-protocol behavioral baselines from observed traffic. Baselines capture what is "normal" for each device - which protocols it uses, which peers it communicates with, how often, with what command patterns, and at what data volumes.

6.1 Baseline Components

6.2 Learning Period and Refinement

Initial behavioral baselines begin forming within 24-48 hours of continuous observation, which is sufficient for steady-state OT environments with consistent polling patterns. The baseline engine refines continuously as more operational history is accumulated, incorporating weekly cycles, shift patterns, and maintenance windows over the first 7-14 days. Environments with shift-based manufacturing, seasonal HVAC operations, or batch processing benefit from extended observation periods for full cycle coverage.

Deviations are reported with full protocol context - the alert shows what changed, what the baseline value was, and the specific protocol evidence. This context enables analysts to rapidly distinguish genuine anomalies from expected operational variations.

7. Security Insights Engine

The Security Insights engine continuously analyzes observed traffic for security findings across several categories:

8. Threat Detection

WireTrace's threat detection combines three approaches: indicator matching, behavioral anomaly detection, and attack surface analysis.

• IoC Matching: Observed IPs, domains, and URLs matched against threat intelligence feeds (STIX/TAXII). Infrastructure whitelist prevents false positives from known-good services (e.g., CDN providers, cloud infrastructure, OS update servers). Per-IoC exclusion allows analysts to dismiss confirmed-benign indicators.
• Behavioral Detection: Deviations from established baselines - new communication peers, unusual protocols, command pattern changes, volume anomalies - surfaced with full protocol context and baseline comparison data.
• Attack Surface Scoring: Per-asset risk score based on observed exposures, categorized by severity: cleartext credential transmission (critical), expired or self-signed TLS certificates (high), exposed management interfaces with weak authentication (high), and unprotected industrial protocol access (medium-high). Scores reflect what is actually observed on the wire. CVE correlations based on observed firmware versions are probabilistic and should be validated through targeted assessment.

9. Compliance Evidence

WireTrace generates supporting evidence for selected controls within 7 frameworks - IEC 62443, ISO 27001, HIPAA, NCA ECC, NCA OTCC, NIST CSF 2.0, and NERC CIP - plus custom frameworks. This evidence is derived from observed network behavior - asset inventories from protocol communications, segmentation validation from documented cross-zone traffic, encryption posture from TLS handshake analysis, and access control patterns from communication flow records.

Traffic-derived evidence supports audit preparation and reduces manual evidence collection. It does not constitute compliance certification and does not replace all evidence requirements for any framework. Controls that require policy documentation, physical security measures, or organizational processes are outside the scope of passive network observation.

10. Limitations and Scope

11. Deployment

All components run as containers. Typical server installation completes within 10-15 minutes using the self-extracting installer on recommended hardware. Sensors enroll via activation token and begin transmitting parsed protocol data within 60 seconds. The platform operates fully on-premises with no cloud dependency. Air-gapped deployment is supported; vulnerability feed updates can be performed via offline file transfer.