CAVER for MSSP

Your margin stops being a function of their log volume

Per-gigabyte licensing makes your best customers your worst accounts. Flat pricing changes what you can profitably offer.

Date October 2026 Prepared by RedEye Security

Executive summary

A managed provider reselling volume-priced licensing has a structural problem: the customer who grows becomes a margin problem, and the only levers are reducing what you collect or repricing the account.

CAVER's flat per-deployment license removes that. It also makes a deployment per client affordable, which is the cleanest possible answer to the data isolation question every procurement now asks.

Contents

01 The structural problem 02 Why the price works 03 Managing many deployments centrally 04 Delivering the service 05 Workers, not another alert queue 06 Endpoint telemetry that says when it is blind 07 From exploited to contained 08 Speed and storage, measured 09 How CAVER compares 10 Evidence that holds up 11 Where it runs 12 What CAVER connects to 13 How to test our claims

The structural problem

Most of these are economic rather than technical, which is why more features have not solved them.

You are reselling someone else's volume pricing, so a customer who grows becomes a margin problem.
Onboarding is bespoke every time, and the runbook lives in an engineer's head.
Client data isolation is asked in every procurement, and shared-tenant answers are getting harder to give.
Collector configuration drifts across dozens of client sites with no version history.

Why the price works

CAVER charges a flat fee per deployment. There is no charge per gigabyte.

That is a pricing decision, but it only works because of how the system is built. On a storage lake, what a search costs depends on how many files it opens, not how many bytes you have kept. CAVER continuously merges small files into fewer, larger, sorted ones.

On a real production system running about 100GB a day, that change did two things:

Idle searches went from 1,200 milliseconds to 11 milliseconds.
Files opened per search dropped from 466 to 10.

Older data moves to a sealed tier that is simply a folder. Months outside your search window are never opened at all. There is no separate index to rebuild before a search or an alert can reach that folder: detections and dashboards query it directly, measured at 172 milliseconds for an alert and 76 milliseconds for a dashboard panel over a million events.

$0/GBNo ingest charge; flat per deployment

7 yearsAudit retention, enterprise tier

466 → 10Files opened per search, after merging

48:1Compression: raw log volume against what the lake stores

What this means for you: "how far back can I search" becomes a storage question, not a performance question. You stop choosing between logging whatever each client actually needs logged and staying inside budget.

Managing many deployments centrally

A deployment per client, operated from one place.

Collectors check in with labels, and the server resolves which configuration bundles target them.
Staged canary rollouts, so a configuration change reaches one site before it reaches forty.
Stale nodes are swept automatically, so the inventory reflects reality rather than history.
Client data stays in the client's own storage, in an open format, under their keys. You operate it; you do not hold it.
Behavior analytics are tenant-scoped, so one client's activity cannot teach or trigger under another.

New clients repeat, not restart. A client deployment is a Helm chart, Docker Compose, or an AWS or Azure Terraform stack with an offline image flow. Collectors install as services on Windows, macOS and Linux, with .deb and .rpm packages. caver-doctor checks readiness at boot and produces a support bundle when something is wrong.
Bundles resolve by attribute. A deployment server targets by label, regex, CIDR or CMDB attribute. Bundles promote through canary stages, nodes can be paused with a kill switch, and caver-fleet drives the fleet from a script. Every node reports throughput and an install fingerprint on check-in, and a whole deployment's settings live in one caver.yaml with a JSON Schema.
Query fairness across clients. Per-group search cost budgets queue heavy searches rather than refusing them, and a reserved priority lane keeps incident searches fast while a report runs.

Two isolation models

A deployment per client is the strongest isolation and what we recommend. For smaller clients, a shared deployment scopes ingest tokens, indexes, behavior models, notables and ChatOps by tenant, delivered on request, typically within 30 days of order. Multi-tenant management of endpoint fleets through the Carbide Console is available to design partners. The flat license is what makes a deployment per client affordable.

Delivering the service

What your analysts and your clients actually touch.

Winning clients from other SIEMs. caver-migrate moves a client's Splunk apps, dashboards, ITSI and UBA content, Elastic and Kibana content, Sentinel rules, workbooks and playbooks, and Defender and QRadar rules into Caver in one command, with a dry run and a report on what did not convert.
Client-facing reporting. Compliance reports are customer-branded signed PDF or CSV, generated asynchronously and emailed. They assess a client against PCI DSS 4.0, SOC 2, ISO 27001, HIPAA, NIST CSF 2.0, NIST 800-53 and 800-171, CIS Controls v8, DORA, NIS2, IEC 62443 and more, in summary or evidence-row form. A Compliance API serves posture as JSON to your GRC platform. Saved searches emailed on a cron schedule to client contacts are available on request.
The SOC workflow your analysts live in. Cases sync to Jira Cloud and ServiceNow, on-call routes to Slack, Teams and Telegram, ChatOps commands run with per-user roles, and per-severity SLA timers can trigger playbooks. SOC KPI dashboards report MTTD, MTTR and false-positive rate per pack.
AI-assisted triage with guardrails. Verdicts on notables carry disposition, confidence and rationale, are grounded on the deployment's own case history, and are human-confirmed. A per-rule noise report built from case-close reasons shows which detections to tune.
Reliability and cost, per client. Ingest returns 200 only when data is durable, a dead-letter index captures rejects with a reason, and a silent-source watchdog flags a log source that stopped. Cost Intelligence reports storage by stream and tier, so you can show each client what they keep and what it costs.
Availability from the same console. ECHO builds service trees with KPIs, SLO burn rate and episode correlation, SNMP discovery, synthetic uptime checks (ICMP, TCP, HTTP, DNS, TLS) and a Kubernetes entity pack.
Detection supply. More than 5,000 rules, including the SigmaHQ set with transpiled SPL and a weekly sync, a detection IDE with live backtest, and a change-window mode that de-weights approved client change work without blinding the rule.
Disputes. The Evidence Locker uses S3 Object Lock in WORM mode, dual-authorized legal hold and signed PDF exhibit export with an offline verification CLI.

Workers, not another alert queue

The reason teams turn detections off is not that the detections are wrong. It is that nobody is left to work the output.

Roughly a third of alerts are never investigated, an investigation takes over an hour, and an analyst closes twenty to thirty in a shift. A three-digit queue does not fit inside a staffed team by arithmetic. So CAVER ships named workers rather than more alerts: each one holds a single job, runs it on its own beat, and reports what it found.

36Named agents, none needing a model

0Of them need a language model

OffHow every one of them arrives

Silence is a result, and it is recorded

An agent that speaks only when it finds something is indistinguishable from one that is broken, and the second is far more common than anyone admits. Every run is written down whether or not it found anything, carrying what it checked and over what window. A quiet morning becomes evidence rather than an absence of evidence.

Why none of them needs a model

Twenty of the thirty-six are rules, joins and thresholds: the same data gives the same answer on any day, and it can be explained to an auditor as a query. The other sixteen are baselines, peer groups and rarity, which is still arithmetic over your own history. Five can use a language model to write their summary in prose; turn it off and you lose the wording, not the finding.

The platform roster is per tenant, and so is the on-off decision, so a customer who wants none of it and a customer who wants all of it are the same deployment.

They arrive switched off, and you switch them on

Every agent ships disabled, and you enable them one at a time from the product. That is deliberate. You decide what runs for whom, and the run history is per tenant and exportable.

What is finished and what is arriving

The workforce, the roster and the controls are shipped and in the product. The connections that feed individual agents land per data source, so an agent whose source is not connected yet says exactly that and names what it needs, rather than reporting a confident nothing. Ask us which of the thirty-six are live against your feeds before you count on any one of them.

Endpoint telemetry that says when it is blind

Most estates buy endpoint telemetry from somewhere, and CAVER reads what you already run: CrowdStrike, Defender, SentinelOne, Sysmon, syslog and the forwarders on your servers. For the hosts where the options are bad, CAVER ships its own agent, Carbide, at no extra charge.

Sysmon, read as process lineage

Sysmon process, network, file, registry, module-load, DNS and memory events all arrive as OCSF with the parent and child identifiers carried in the event, so a chain of executions joins across hosts rather than only inside one log line. A coverage screen shows which Event IDs are arriving now, which were seen in the last week and not in the last day, and which hosts are reporting. Every freshness figure is the time of the last event, never a count, because a count is satisfied by history: a source that died last week still has a large one.

Carbide, on Linux, Windows and macOS

Kernel-level capture. On Windows it reads ETW and kernel providers, and on macOS EndpointSecurity. On Linux, process execution is taken at the kernel with eBPF, as one binary that runs across kernel versions without compiling per host. Container aware, with the container identity resolved in the kernel so it survives a process that has already exited.
It says when it is blind. Every event declares its own collection source and fidelity. On a host where the kernel path cannot attach, the agent falls back to polling and marks every event as partial, so a thinner feed reads as thinner instead of as quiet.
Silence raises its own alarm. The agent heartbeats on the channel it ships telemetry on. A host that stops is reported as missing, and a host that is reporting while collecting nothing is reported as empty, which is the case a green dashboard hides.
Updates that undo themselves. Signed manifests, rollout by stage, and a version that will not come up puts the previous one back without an operator.
One rule, every source. Detection content written for process lineage fires on a Windows Sysmon host and on a Linux, Windows or macOS Carbide host alike. That is asserted by a test in our build, not repeated in a slide.

Same host, same workload	Kernel capture	Polling
300 short-lived processes in a loop	300 captured	0 captured

That row is why the agent exists. A process that starts and exits between two polls is most of what execution telemetry is for, and a poller cannot see it.

Platforms and coverage

Carbide ships for Linux, Windows and macOS, installed as a system service. AIX coverage is available to design partners. Where you already run CrowdStrike, Defender or SentinelOne, Carbide sits beside it or CAVER reads that instead. Sysmon process, network, file, registry, module-load, DNS and memory events are all normalized to OCSF and addressed by the same detection content.

From exploited to contained

A vulnerability list ranked by severity score tells you what could be exploited. Two public feeds tell you what is.

CAVER ingests CISA's Known Exploited Vulnerabilities catalog, about 1,200 CVEs with confirmed exploitation, and FIRST's EPSS scores, an exploitation probability for roughly 200,000 CVEs, every day, and joins both onto your findings by CVE. The vulnerability screen gains an exploited-in-the-wild filter and a sortable probability column.

The effect on a real board is the difference between "4,000 findings" and "these eleven are being exploited right now, start here".

Time to contain, measured

In 2026 CISA published an advisory in which two organizations faced the same red team with the same tradecraft and both fell to full domain compromise. One isolated three phished workstations in 10, 2 and 20 minutes and cut the command channel. The other actioned zero alerts. The difference was not the tooling and not the detection content; it was how fast a person acted on what the tooling already knew.

So CAVER measures that interval, per incident, from the case record:

Detection to acknowledgement, how long until a person first acted.
Acknowledgement to containment.
Detection to containment, the headline number.
Detection to close.

We publish compression and query speed as first-class numbers because they are how CAVER beats a per-gigabyte platform. Time to contain is the number that decides whether any of that mattered, and it is on the same screen.

Speed and storage, measured

Real measurements from a production system handling about 100GB per day.

Search	Time
Empty hour	6 ms
One hour of data	38 ms
24 hours of data	453 ms
48 hours across two data centers	627 ms

Performance in context

Published figures show searches under 50 ms at the 95th percentile. The counterpart matters just as much: a 120-second ceiling still applies to large summarized searches, and searches over recent data under load run around 1.1 to 1.2 seconds. We are working on that ceiling. Both numbers are published because a best case is not a guarantee.

Compression: 48 to 1, and how we measured it

The top number is raw bytes received, which is what a per-gigabyte license would charge you for.
The bottom number is the actual stored file size, taken from a storage listing.
Our own system's internal logs are excluded from both.
The ratio varies with your data mix.

"If a vendor will not show you the method, the ratio is not a number. It is a claim."RedEye Security, published material

Ask any vendor, including us, for the range across your own data types during a trial. Not just one blended figure.

How CAVER compares

Area	Typical SIEM	CAVER
Pricing	Per gigabyte; retention becomes a budget lever	Flat per deployment
Data ownership	Often vendor-hosted, proprietary format	Your storage, your keys, open format
Archived data access	A restore or rehydration job, often billed per query	Queried directly from your own bucket, no restore step
Encryption at rest	Assumed, rarely verified	Checked before start; refuses to run on storage it cannot confirm
Client isolation	Shared tenancy with logical separation	A deployment per client, centrally managed, or a shared deployment scoped by tenant
Fleet configuration	Manual, or a shared clone with no versioning	Label-selected bundles with canary rollout
Your existing detection content	A rewrite, or left behind	Sigma, Splunk, Elastic, Sentinel, QRadar and Defender rules convert in, with a report on what did not
Evidence handling	Export logs; chain of custody is manual	Cryptographic custody, verifiable offline
Compliance reporting	Usually a separate product	More than 20 frameworks built in, signed export
Where it runs	Many are cloud only	Cloud, on-premise, air-gapped, single box

Where the incumbents still win

An established SIEM has real advantages we will not pretend away:

A large consulting ecosystem.
A hiring pool that already knows its query language.
A decade of your own custom content.

Those are genuine switching costs. Our answer is the parallel-run and collector-only options above, which let you measure the difference instead of taking it on faith.

Evidence that holds up

For the moment an incident becomes a legal, regulatory or contractual matter.

At that point someone outside your security team needs to trust the record without trusting your vendor. The Evidence Locker is built for that:

Every item carries a cryptographic fingerprint and a signature covering the content, time, case and the person who filed it. A signature cannot be moved onto different content.
Custody records are append-only. They are never edited.
The ledger uses the same proven construction that underpins internet certificate transparency.
Every read and every check is logged, with who, when and why.
Verification does not need CAVER. A separate signed program checks the whole chain offline, so an opposing expert, outside counsel or an auditor can verify it without touching your systems.
Export bundles can be encrypted with AES-256 under a password you set.

What this means for you: a record you can hand a client's regulator or insurer without them having to trust you or us.

One limit worth knowing before you send a bundle

The AES-256 password protects the contents of the archive. The list of file names and their sizes is still readable without the password, which is how the ZIP format works. If a file name would itself reveal something, rename it before export.

Where it runs

One product, not a different tool for every environment.

CAVER runs on Kubernetes, a virtual machine, an isolated network, or a single box. License activation does not need an internet connection, and a lapsed license gives you a 14-day grace period rather than shutting off mid-incident.

Two postures, and you choose

Sealed. Fully self-hosted. On-site vendor access only. No remote connection out of your environment. Nothing leaves. Appropriate for a client who cannot allow remote vendor access, which is a client you can still serve. For managed clients, a template discloses exactly what operator access exists and an attribution policy records which of your analysts did what, so your client can read it before signing.
Managed. The conventional arrangement, with remote monitoring and vendor-assisted operations.

This is your risk decision. Both are real products. Neither is a discouraged version of the other.

Signing in with what you already have

SAML 2.0 and OpenID Connect are both configured in the product: paste or fetch your identity provider's SAML metadata, or point at your OIDC issuer for discovery, then map the attributes or claims to roles. Test against the live provider before you can turn it on: enable is refused without a successful test in the last 24 hours. A saved change or a disable takes effect on the next request, no restart, and local login stays reachable so an identity-provider outage cannot lock your operators out. An OIDC client secret is sealed in the product's credential vault, never stored in the clear.

Provisioning through SCIM

SCIM provisioning is configured the same way: an operator mints a bearer token for the identity provider, shown once and stored only as a hash, revoked on the very next request rather than the next restart. Group membership from SAML, OIDC, or SCIM maps to roles by the same rule.

Four ways to start

Full migration, with a practice run before cutover.
Run alongside your current SIEM while your team checks coverage. CAVER can register as a Splunk search peer, or federate with Elastic, Sentinel, Sumo Logic or Datadog, so both systems answer the same question and you compare the answers.
Collection only, sitting in front of your current tool with no disruption.
One piece at a time. Take the Evidence Locker, AI monitoring or compliance reporting without replacing anything.

What CAVER connects to

The same connectivity for every client, so onboarding is configuration rather than a project.

Category	How it reaches CAVER	Status
Network and security	Palo Alto, Fortinet, Cisco, Juniper, Check Point, Zscaler, Cloudflare	Ready-made packs
Endpoint	CrowdStrike, Defender, SentinelOne, Carbon Black, Trellix, Huntress, Sophos, Sysmon	Ready-made packs
Email	Proofpoint, Mimecast, Abnormal	Ready-made packs
Identity	Entra, Okta, JumpCloud, OneLogin, Auth0, Ping, Duo, Active Directory	Ready-made packs
Cloud	AWS, Azure, Google Cloud, Workspace, Microsoft 365	Ready-made packs
Ingest paths	Syslog, Kafka and Event Hubs, Kinesis Firehose, S3 and SQS, OTLP, Prometheus remote_write, NetFlow, sFlow, SNMP, and agentless Windows Event Forwarding over HTTPS with no collector box at small sites	Included
Carbide, our own endpoint agent	Kernel-level process telemetry on Linux, Windows and macOS, shipped to CAVER directly	Included; AIX for design partners
Industrial equipment	More than a dozen industrial protocols decoded passively from mirrored traffic	Included, no extra product
Zeek, Suricata, wireless and physical	Zeek and Suricata logs normalized to OCSF; Cisco WLC, Aruba, Mist and Ruckus ingest with rogue-AP detection; weapons-detection connectors	Delivered on request
Further adapters	SentinelOne alerts and Ranger, Carbon Black App Control, Tenable OT, Armis, Snowflake query history, Trend Cloud One, PingOne, Cognito, Identity Center and CloudWatch Logs pull, plus direct LDAP, Entra and Okta user polling	Delivered on request
AI tools	Microsoft Agent 365 event data, plus Claude, Copilot, OpenAI and others	24 packs, 200+ rules

And everything else

Anything that keeps a log. Syslog, a log file, Windows events, a cloud audit trail, a database table.
Anything with an API. If it can be polled or can push, CAVER can take it.
Anything that talks on a network you can mirror to us. Even with no log and no API.
Custom collectors are built to order. That is ordinary work here, not a special request. If you have a system that matters and nothing off the shelf reads it, say so during the trial and it gets built.

More than 400 ready-made vendor packs ship for the common systems, so the bespoke work is the exception rather than the starting point.

How to test our claims

A trial is 60 days, $25K to $75K, credited fully toward your first year if you proceed. If you are replacing Splunk, a displacement credit of 25% to 50% off year one is available separately.

Do not take this paper on faith. Test it directly:

Onboard two clients and time the second one. That difference is the number that matters to your margin.
Push a configuration change to a canary site and confirm it did not reach the rest.
Ask what CAVER shows during the learning period. It should tell you it is not ready, not show you a clean dashboard. This is the claim that is easiest to fake.
Verify an evidence export yourself. Run our offline checker against a real export without touching the CAVER console.
Ask for the compression range across your data types, and for the load ceiling next to any speed figure.
Run it alongside your current SIEM so migration risk is measured during the trial rather than assumed afterward.