What is an Edge Security Probe

The practical meaning of “probe = evidence box” is a closed loop: capture what happened, prove the records are authentic and untampered, and keep them intact through power loss and device faults. If any one of these steps is missing, the output becomes an opinionated log rather than verifiable evidence.

Typical inputs include mirrored packets or flow/metadata, ingress counters (to expose loss), and device measurements used as integrity context (firmware/config digests for attestation). Typical outputs are sealed log segments (hash-chained entries, periodic roots, signatures/MACs), plus a compact audit summary that lets a third party verify ordering, integrity, and completeness without trusting the probe’s runtime state.

Where it sits in the network

Out-of-path (TAP/SPAN) is preferred when uptime is paramount and the probe must never become a point of failure. The main technical risk is that mirrored evidence can be incomplete without obvious symptoms. A probe designed for evidence quality therefore treats loss visibility as a first-class output: ingress statistics, gap detection, and configuration context become part of the audit trail.

Inline (bump-in-the-wire) is chosen when evidence needs to reflect the actual forwarding path and mirrored links cannot be trusted. The main risk is fault domain: power loss, software hangs, or link negotiation issues can disrupt traffic unless a well-defined bypass strategy exists. Inline deployment also requires that any bypass transition is itself recorded, otherwise the chain of custody breaks exactly when it matters most.

Traffic acquisition: TAP/SPAN, link modes, and loss detection

Mirroring is not a binary “works / does not work” feature. It is a data path with its own contention, buffering, and configuration surfaces. The practical difference between TAP and SPAN is therefore not marketing— it is how often and how invisibly evidence can become incomplete under burst, oversubscription, or filtering.

Loss visibility is strongest when it is built from independent layers of evidence, rather than a single “RX dropped” number. A probe-grade capture path typically maintains a closed accounting loop: source-side counters + probe ingress counters + content-level gap signals. If the loop cannot be closed, the uncertainty must be disclosed in the signed audit summary.

Capture granularity is a second, separate decision. Metadata-first capture maximizes throughput and retention while reducing privacy exposure; full packet capture increases forensic detail but amplifies storage pressure, power-loss risk, and long-term retention cost. A robust evidence design often defaults to metadata and upgrades to fuller capture only for constrained windows or high-value triggers, keeping the evidence chain durable and verifiable.

Hardware timestamping: what “good time” means for evidence

Evidence time has four engineering properties: ordering (events sort correctly), consistency (jitter and drift are bounded and stable), traceability (time-source state is recorded), and explainability (a reviewer can understand the error budget). Without those properties, timestamps become decorations rather than admissible evidence.

Power-loss and restart behavior must be part of the time story. Holdover (RTC + energy reserve such as a supercap) is used to preserve time continuity long enough to seal the final log segment and to label the probe’s time state after reboot. If time is uncertain (drift beyond bounds, step events, or a reset), the audit trail must mark that interval explicitly so event ordering remains defensible.

Identity & attestation: proving “who generated this log”

A practical identity stack has three layers. A device identifier makes the source addressable, a certificate chain makes it verifiable, and a protected signing key (anchored in TPM/HSM/SE hardware) makes it hard to impersonate the device. The goal is not naming— it is producing a signature that reviewers can validate without trusting the runtime environment.

Attestation evidence should be described as fields rather than narratives. The verifier needs a compact package that reports firmware and configuration state as measurements (digests), and binds those measurements to a fresh challenge so that old claims cannot be replayed. This page focuses on the evidence fields and verification logic only.

The minimum verifiable statement is intentionally small: a signed measurement plus a nonce and a time window. The nonce makes the claim fresh, the time window bounds its validity, and the signature binds the claim to the device identity. Without this minimum set, the log source and state become disputable.

Log integrity: hash chains, signatures, and tamper evidence

An append-only log links each record to the previous record via a hash reference. This structure makes insertion and deletion detectable. For high-rate capture, sealing records in segments improves throughput and verification efficiency. Segment sealing computes a compact root over a chunk of entries and signs that root, producing a verifiable checkpoint.

Tamper evidence must explicitly cover common failure and attack patterns: counter rollback (log truncation), time rollback (step events), and storage replacement (cloning or swapping media). The audit trail should record monotonic counters and sealed-root indices, and it must log time-state transitions so that timeline uncertainty is visible rather than hidden.

Durable storage & power-loss protection (PLP)

Storage choices should be evaluated through an evidence lens: can partial writes be detected, can sequential append be sustained for long retention, can endurance be predicted under high-rate logging, and can crash recovery rebuild a trustworthy index without hidden corruption. The media name matters less than the ability to implement detectable and recoverable persistence.

PLP should protect two actions: flush (drain capture buffers to a durable write path) and commit (finalize a segment with a verifiable marker and checksum/root). A well-designed log accepts that an in-flight segment may be incomplete during sudden power loss, but it ensures that incomplete data is detectable and that the last completed commit remains provable.

A recoverable data structure is built around sequential append and segment envelopes. Each segment carries a compact header (version, segment index, counter/time window) and a tail commit marker. On restart, the device performs a linear scan to locate the last valid segment commit, then rebuilds indexes from segment headers. The recovery outcome becomes an evidence event: last valid commit, detected gaps, and time-state at restart.

Privacy & data minimization: capture what you need (and no more)

A privacy-resilient capture design starts with a metadata-first baseline that still supports loss visibility, ordering, and verification. The baseline should preserve flow identity, direction, size, counters, and compact digests — enough to explain “what happened” without persistently storing sensitive payloads. Capture policy itself should be recorded in the audit trail so reviewers know exactly what was collected.

When payload visibility is required, redaction should be explicit and bounded. Redaction methods trade interpretability for privacy. The safest approach is to choose the minimum method that still preserves verifiability, then disclose that method in the signed audit summary.

Access control is part of evidence quality. Logs that are widely readable tend to leak. A probe should enforce least-privilege read access and produce a read-audit trail: who accessed what, when, and under which authorization context. Read audits should be tamper-evident, so “who saw the evidence” is itself provable.

Performance engineering: burst, buffering, and backpressure

A probe’s data path can be treated as three linked stages: ingress capture (port → DMA → ring), record packaging (timestamp + labeling + segment builder), and persistence (flush → segment commit → storage). Bursts stress each stage differently; bottlenecks are identified by where counters move and where latency expands.

Backpressure is a safety mechanism: if persistence slows, the system must avoid silent loss. Instead, it should apply bounded reduction (rate-limited intake, sampling, or metadata-only mode) and record a backpressure event containing cause, time window, and impact. This keeps missing coverage explainable and auditable.

“Logging is slower than expected” is typically explained by write amplification: a record is not just data, but evidence structure. Segment headers/footers, commit markers, checks/digests, and recovery-friendly boundaries add work. The correct engineering approach is to measure amplification via flush latency and segment commit time, then tune the segment sealing cadence to keep the uncommitted window bounded.

Validation & test setup: how to prove evidence quality

A minimal validation setup is built around three instruments. First, a traffic generator provides deterministic sequences and controlled bursts so measured drops and gap detection can be compared against known truth. Second, a time reference provides an external baseline to interpret timestamp consistency and load-dependent jitter. Third, power-fail injection forces failures at different points of flush/commit so the last valid commit, detectable incomplete segments, and recovery disclosure can be verified.

Validation should produce explicit proofs, not screenshots. Each proof item should have an input condition, a measured outcome, and a machine-checkable artifact. The goal is to show that missing coverage cannot be hidden, time uncertainty is disclosed, tamper attempts are detected, and crash recovery rebuilds a verifiable state.

Record format consistency is a test target by itself. Logs should be versioned and parseable so verifiers can recompute integrity checks. A minimal contract includes schema version, stable field types for counters and timestamps, segment boundaries that survive partial writes, and unambiguous rules for recomputing digests/roots. Policy and state events (backpressure mode, redaction method, recovery disclosure) should be represented as structured records, not free-form text.