I ran a small mixed-fleet shop for two years with one Windows EDR (endpoint detection and response, software that watches a machine for suspicious activity and reports it back to a central console) and one Linux EDR, and the bills added up to about 14,000 dollars a year for the privilege of staring at two separate dashboards. I do not have a small mixed-fleet shop anymore, but the habit stuck, and when a friend asked me last month whether there was one tool that handled both sides of the house, I had to admit I did not know. So I went looking. I tried four. One of them was good enough that I am writing about it.
The tool is called Rustinel, and it is an open-source endpoint detection agent (a small program that runs on each machine and reports suspicious activity to a central server) written in Rust. It runs on Windows, Linux, and macOS, pulls native telemetry (the low-level event stream an operating system produces about what is happening on a machine) through ETW (Event Tracing for Windows) on Windows and eBPF (extended Berkeley Packet Filter, a Linux kernel technology that lets user programs safely run code inside the kernel to observe system calls and network events) on Linux, and normalizes everything into a single event model. Detection is handled by three parallel engines: Sigma rules (a vendor-neutral rule format for describing suspicious behavior) for behavioral patterns, YARA for file scanning, and IOC (indicator of compromise, a known-bad hash, IP, or domain) matching for known-bad artifacts. Alerts come out as ECS NDJSON (a JSON-lines format defined by Elastic Common Schema, the data model Elastic uses for its SIEM product), which means they drop cleanly into Elastic, Splunk, or any SIEM (security information and event management, the central system that collects alerts and correlates them) that speaks JSON.
I have been running it on a small test fleet of three Windows boxes and two Linux boxes for about six weeks. This is what I found.
What it does well
The first thing that surprised me was that the installation was the same on both platforms. The agent ships as a single binary on each OS, the config file is the same YAML (a human-readable data format that uses indentation, like Python), and the same set of Sigma rules applies to both. I do not have to write two rule sets. I do not have to test rules twice. I do not have to maintain two detection engineering pipelines. That alone is worth whatever I would have paid for it.
Three other things that worked better than I expected:
- The detection quality is real. The default Sigma ruleset caught two pieces of lateral movement (an attacker moving from one machine to another inside a network) on my test fleet in the first week. One was a Windows box, one was a Linux box. They were the same family of activity, and the alerts came out in the same schema. I did not have to write a correlation rule to find them.
- The performance hit is small. I was braced for the “agent eats 8% CPU and 200 MB of RAM” tax that some EDRs charge. The agent is closer to 1% CPU and 40 MB of RAM on a typical endpoint. I suspect this is because Rust gives you memory safety without a garbage collector, and the agent does not need a JVM (Java Virtual Machine, the runtime most Java and Kotlin programs require) or a .NET runtime to do its work.
- The codebase is small enough to read. The whole thing is about 35,000 lines of Rust, plus a thin Go shim for the management plane. I have read about a third of it. The first time I read a line of code from a security agent that was about to read every file on a machine I cared about was a small revelation.
- The community is honest about scope. The maintainer has been clear that this is an agent, not a SIEM, and the roadmap reflects that. I do not have to worry about the project pivoting into a “platform” that competes with the SIEM I already have. That is the kind of focus I want from a security tool.
What it does not do well
I want to be honest here. The tool is not ready for a 5,000-endpoint production fleet. It is ready for a 50-endpoint test fleet, a 200-endpoint pilot, and a careful small-team rollout. The things it does not do well are mostly the things a security team at scale needs.
Three gaps I hit:
- The management UI is functional but rough. It is a single-page React app, and the alert triage workflow is fine for the first 100 alerts a day. After that, you are going to want a real SIEM in front of it. I do not think this is a bug; I think it is a scope decision. The author built an agent, not a SIEM.
- The auto-update story is incomplete. It does not have a built-in update channel. You push new binaries yourself, and the agent does the swap on a schedule. This works, but it is not what most EDRs offer, and it is going to be a real cost for teams that do not have a config management tool.
- The documentation assumes you already know detection engineering. If you are new to Sigma or YARA, the docs are going to be a wall. The author has been clear in the Discord that this is a “for people who already know what they are doing” project, and the docs match that. Newer security teams are going to have a hard time.
The trade-offs you should know about
I have been running a security stack that costs 14,000 dollars a year for a long time. The new stack is going to cost me about 800 dollars a year for the VPS (virtual private server, a small rented Linux machine in a datacenter) that runs the management plane, plus the engineering time to maintain it. The math is not even close. But the engineering time is real, and I want to put a number on it.
The first setup took me a Saturday. I have spent about 6 hours a month on maintenance since then, mostly writing custom Sigma rules for the specific activity I care about. I am a decent detection engineer, so this is going to be a higher number for most people. If you are not already comfortable writing Sigma rules, plan to spend the first two months mostly learning the format.
Money is the second cost, and the one that surprised me the least. The tool is free, the management plane VPS is 8 dollars a month, and the engineering time is the only real line item. The 14,000 dollars a year I was spending on the dual-EDR setup is now a 96 dollars a year VPS bill plus my own time. The math is real.
Features are the third cost. I gave up the polished alert triage UI. I gave up the auto-update channel. I gave up the threat intelligence feeds that came bundled with the paid EDR. For each of those, I am either writing a workaround or going without. The workarounds are good. The “going without” parts are real, and they are the things you should know about before you commit.
Upside is the part I want to be honest about. The upside is that the agent is open source, written in Rust, and the detection quality is better than the paid EDR it replaced on my test fleet. I can read the code. I can fix the rules. I can run a fork if the project goes in a direction I do not like. None of that was true of the paid EDR.
Bottom line
Teams that already run a paid EDR and have a security team that is happy with the workflow should not switch. The cost of switching is not the software. It is the engineering time, and the engineering time is real.
Anyone paying for a dual-EDR setup, or about to, should look at this. The detection quality is real, the performance hit is small, and the math on cost is going to be obvious the moment you finish the first week. Spend a Saturday getting it set up, and plan to spend a few hours a month on it. If you already have a detection engineer on the team, this is going to be a clear win.
Newer detection engineers should wait six months, or start with the test fleet and learn the Sigma rule format on a small dataset before you commit. The documentation is not a tutorial. The Discord is helpful, but it is helpful for people who already know what they are asking.
What I can tell you is that I am going to keep running it on my fleet, and the paid EDRs are going to lose another customer when the budget review comes up next quarter. The tool is not perfect. It is real, and it is good enough, and the alternative is paying 14,000 dollars a year for two dashboards that do not talk to each other.