Newsletter Article
THE SNARE PERSPECTIVE
Don’t build another log pipeline. Build an evidence layer.
Snare Insider Newsletter Series Article
Make sure you Subscribe
Snare isn’t designed to replace the SIEM. It is designed to make the organisation’s security evidence independent of it. The SIEM keeps detecting, correlating and responding. Snare controls what happens underneath:
Collect → Protect → Retain → Route → Replay → Investigate
Each step answers a failure point from this month’s incidents.
1. Collect forensic-level evidence at the source
Snare Agent v5.11 captures security and audit telemetry directly from the operating system, before any downstream platform decides what matters:
- Beyond the Event Log. Event Tracing for Windows (ETW) providers, including DNS Analytic and Debug logs that Windows audit policy can’t reach.
- One policy model across platforms. Windows Server 2008 R2 to 2025, Windows 10/11, Linux (x86-64 and ARM64), macOS, Solaris, AIX and HP-UX, with file integrity monitoring (SHA-256) and registry integrity monitoring.
- Collection that survives outages. Events are written to an encrypted local disk buffer before forwarding, so they survive network outages and SIEM maintenance. Sequence-numbered streams make gaps detectable.
- A hardened agent. TLS 1.2/1.3 with certificate-based mutual TLS in transit. The agent’s management interface runs at OpenSSL security level 3, limited to AES-256-GCM with ECDHE/DHE, and rejects RSA keys of 2048 bits or smaller, SHA-1, RC4 and 3DES.
Identity, SaaS and cloud audit sources feed Snare Central directly through syslog, API and cloud audit feeds, with no agent required.
Why it matters: in South Staffordshire Water’s case, 95% of the environment wasn’t monitored. Evidence that was never collected can’t be recovered later.
2. Retain more than you send to the SIEM
Snare Central retains evidence independently of downstream analytics, with retention policies from 90 days to 7+ years on local disk, NAS, SAN or S3-compatible object storage. That means retention can be set well beyond the 247-day average breach lifecycle, so the evidence of initial access is still there when the breach is finally found.
- Tamper-evident archives. Hash verification on archive ingestion and retrieval, so historical evidence can be shown to be unaltered.
- Aggregation without losing the record. Repeated or near-identical events are merged into a single enriched record within a configurable window, with the original event detail kept in aggregation metadata.
- Lower retention cost. Snare reports up to 90% lower SIEM storage costs. Results depend on ingestion volumes, storage policies and log sources.
The architectural point isn’t the percentage. It’s that what you retain doesn’t have to equal what you pay your SIEM to analyse continuously. Coupang’s lost logs show what happens when retention is set by default rather than by investigation need.
3. Control what reaches each destination
Snare Reflector applies policy before events reach downstream analytics: routing rules on source, log type, event ID, severity, metadata, keyword or regex; de-duplication; field truncation; enrichment; and format transformation to JSON, CEF, LEEF, syslog or custom templates. Field remapping aligns data to Splunk CIM or Microsoft Sentinel ASIM schemas.
Reflector delivers to Splunk (HEC and syslog), Microsoft Sentinel, IBM QRadar, Securonix and Devo, plus any syslog destination, Kafka, Amazon S3, Azure Blob and HEC-compatible platforms.
Detection data goes to detection. Compliance evidence goes to retention. Verbose forensic data stays available without becoming continuous SIEM ingest. Filtering shapes what the SIEM sees; it never reduces the evidence Snare Central retains.
4. Keep collection independent of the SIEM
When collection is built into the SIEM, changing the SIEM means rebuilding collection. Snare keeps the layers separate:
- Reflector delivers to all configured destinations simultaneously, with independent queues, failover and load balancing, so a failure at one destination doesn’t affect the others.
- Old and new SIEMs can run in parallel during migration.
- Business units, or an MSSP’s customers, can use different analytics destinations from the same evidence layer.
- Agent collection policies don’t need rebuilding when the downstream SIEM changes.
Your security evidence should outlast your procurement cycle.
5. Replay history when the question changes
Snare Central v8.8 replays archived events into Microsoft Sentinel and Splunk, applying Reflector’s destination features, including field remapping, to the replayed data. Teams can retain a wide evidence set economically, then replay just the window a new hypothesis or indicator needs.
Green Monster is the example. The April activity wasn’t the investigation it started in October; the October event changed the question. Replay is what lets the data follow the new question without paying to keep every month in the SIEM’s hot tier.
6. Investigate retained evidence where it lives
Storage alone doesn’t shorten an investigation. AskSnare is a cybersecurity AI assistant that lets analysts ask questions of Snare’s retained evidence in natural language, correlate activity, trace timelines and investigate anomalies without first building a dashboard or writing a specialist query.
- AskSnare queries data in place; nothing is replicated or centralised, so data doesn’t cross sovereignty boundaries.
- Every insight comes with a clear rationale analysts can check against the source evidence.
- Human-in-the-loop. AskSnare recommends and explains; the analyst decides and acts.
AI investigation shouldn’t become another black box on top of the evidence. It should make the evidence easier to interrogate.
7. Deploy to fit the environment
A defence network may need complete isolation. A multinational may need protected zones kept separate. An MSSP may serve customers on several different SIEMs. Snare supports four deployment pathways, all built from the same Snare Agent, Snare Central and Snare Reflector:
| Pathway | For |
| Fully on-premises | Local collection, management and retention, with no dependency on cloud or AI |
| On-premises + AskSnare | On-premises collection and retention, plus AI-assisted investigation |
| Unified on-premises + cloud | One collection and retention layer across on-premises and cloud estates |
| Hybrid / separated | Separate Snare Central instances per zone; protected logs never leave their zone |
The architecture follows the organisation’s security, sovereignty and operational requirements, not a vendor’s preferred destination.
