Connect the auditor to the network you already operate

Start with one useful question

Choose an investigation that currently costs the team time: explain a denied transfer, identify the owner of an unexpected egress flow, or trace a failed private application session. Define the expected answer and the data needed to prove it. This keeps the first integration focused on a measurable outcome rather than a broad promise to ingest everything.

Begin in observation-only mode. Existing firewall, VPN, web and identity policies remain authoritative while the auditor learns the evidence landscape. Set a collection boundary, retention window, data owner and operator role before attaching production sources. Where a source contains sensitive payloads, map which fields can reach the investigation tool and which require an additional authorization.

Map the evidence sources

Source	Required mapping	Integration owner
VPN and ZTNA	Session, subject, device, resource, policy revision	Network access team
RBI and SWG	Navigation, transfer decision, destination, browser session	Web security team
Identity provider	Stable subject, authentication time, assurance, group context	Identity team
Device management	Device identifier, compliance state and freshness	Endpoint team
SIEM / network sensor	Source event ID, timestamps, flow identity and loss indicators	SOC / detection team

Normalize timestamps and define the maximum acceptable clock skew. Preserve original identifiers when exporting to a SIEM so that a finding can be opened in the originating tool. Decide how duplicate events, retries, late arrival and retention expiry are represented. These details determine whether an evidence graph is trustworthy under operational pressure.

Inspect selected fields in a local Zeek JSON log

jq -c '{time:.ts, flow_id:.uid, source:.["id.orig_h"], destination:.["id.resp_h"], protocol:.proto, missed_bytes:.missed_bytes}' conn.log

Use this read-only command with a JSON-format conn.log you are authorized to examine. It illustrates the source-to-evidence mapping and makes missing-byte information visible; it does not install an agent or connect to Antara.

Fit the SOC workflow

Send investigation results to the tools operators already use. A useful export contains a concise finding, affected entities, time range, source references, evidence quality and a proposed next action. Keep the source records in the authorized system of record rather than embedding an entire packet capture in a ticket.

Reference investigation policy

yaml

scope:
  tenant: tenant-example
  maximum_window_hours: 24
  allowed_sources: [vpn, rbi, identity, network-flows]
tools:
  evidence_read: allow
  cross_tenant_search: deny
  policy_write: require-approval
report:
  include_event_references: true
  distinguish_inference: true
  redact_secrets: true

Map this intent to your deployment’s supported interfaces. Preserve role checks on the receiving ticket or SIEM view: an exported summary must not become a way to bypass the permissions on the underlying evidence.

Exit criteria for the pilot

Reconstruct a known allowed session and a known denied session from source records.
Explain an encrypted flow without fabricating content.
Demonstrate that one tenant’s analyst cannot retrieve another tenant’s evidence.
Recover from collector interruption and mark the resulting visibility gap.
Send a reviewed finding into the SOC workflow with working evidence references.
Measure analyst review effort against the previous manual investigation.

Only expand sources when they improve an agreed investigation. High-volume telemetry with weak identity correlation can increase cost without improving the answer. Review collection and retention after the pilot rather than treating the first integration as permanent.

CONTINUE EXPLORINGAgentic packet auditing with accountable decisions Run an accountable agentic audit service Standards and industry briefings