Introducing the
Simvay Collector
A pre-configured virtual appliance for the log sources that have no API. One import, one browser form, and they are forwarding into your own SentinelOne Data Lake.
The sources nobody onboards
Most of what a modern security stack ingests arrives over an API. Endpoint agents report themselves. Identity providers, cloud platforms and SaaS applications all have a documented integration, and turning one on is an afternoon of work.
Then there is everything else. Firewalls, hypervisors, backup servers, switches, wireless controllers, storage arrays, physical access systems. A lot of the equipment that actually runs a site speaks syslog and nothing else. There is no API to point at the Data Lake, so somebody has to stand up a collector for it.
So they get skipped. Not because anyone decided they did not matter, but because onboarding each one was a small project, and there was always something more urgent that week.
What a missing source costs
A source that is not forwarding is not a gap you notice on a normal day. You notice it during an investigation.
You are trying to reconstruct what happened. The firewall that saw the traffic kept its logs locally and has already rolled them over. The hypervisor recorded the logins, but nobody was collecting them. The backup server knows exactly when the job started failing and no one thought to ask it. None of that is a detection problem. It is a retention problem, and by the time it matters it is too late to fix.
The quieter cost is consistency. When every site is built by hand, every site ends up a little different, and a query that works at one of them returns nothing at the next without ever telling you why.
Onboarding a log source should not need a security engineer.
The appliance is imported onto an ESXi host and powered on. Its console prints the address of its own setup page. A browser opens that page, seven self-test checks turn to PASS one at a time, and the verdict banner turns green.
The manual build, and what replaced it
It is SentinelOne's collector underneath, so events land in your own tenant with your own write key. What we added is the packaging, the guardrails and the proof that it is working.
The appliance's setup pages are filled in from a browser: the factory passphrase is changed, then hostname and network, then the Data Lake region and write key, then three log sources are added. Apply runs the self-test and the verdict turns green.
How it works
- 01
We hand you a built appliance.
One import onto a host you already run, with no operating system to install and nothing to compile. It powers on and prints the address of its own setup page on the VM console.
- 02
It is configured in a browser.
Address, Data Lake region, write key, and which device maps to which parser. Adding a source later is a form, not a config file, so your team can do it without us. A bad network setting rolls itself back after three minutes, so a typo cannot strand it.
- 03
It proves itself, then keeps checking.
Seven checks, including a real event round trip, end in a plain verdict on a read-only status page. Your on-site IT can read it without credentials to anything, and a watchdog pages us if it stops forwarding.
Raw syslog from a firewall, a hypervisor and a backup server arrives at the Collector in three different dialects. One line is taken apart into named fields, and the parsed events land in the Data Lake as queryable rows.
Coverage today, and what is coming
The appliance ships for VMware, and Hyper-V is in development. Parser support is rolling out for Meraki, vCenter and Veeam, and we build custom parsers where the published SentinelOne inventory stops short.
If there is a source you care about, tell us and we will confirm where it stands.