Every detection platform asks for your trust twice: once when it raises an alert, and once when you tell it to stay quiet. Logster v1.3.0 is built around both halves of that bargain. It rebuilds whitelisting so that approvals stay visible, measurable and impossible to hide behind, and it connects every explanation Logster gives you to the evidence that produced it.
Alongside that, this release adds storage that looks after itself and a delivery model for air-gapped clusters. Here is what changed.
Whitelisting you can trust
A whitelist is a statement of trust, and, as we have written before, whitelisting a graph is harder than whitelisting a filename. Logster v1.3.0 makes that statement easier to write precisely, easier to check, and much harder to abuse.
- Attackers can’t hide under an approved parent. This is the most important change in the release. An approved process that starts something unapproved is no longer removed. The whole branch is kept and scored, so running malware from inside a trusted backup job doesn’t make it disappear.
- Approve by description, not only by example. New attribute rules let you approve “this exact backup command” or “anything writing to this log path” by typing it, with no source graph needed. Rules can apply to every endpoint or just one.
- Watch before you enforce. New rules start in observe-only mode. They report what they would have excluded (“would have excluded 214 nodes in 7 days”) without changing any verdicts. Switch a rule to enforcing once the numbers match what you intended.
- A breadth check that says no. Before a rule is saved, Logster tests it against recent activity. A rule that would silence a large share of everything is refused unless someone deliberately overrides it.
- Nothing disappears silently. Whitelisted activity is excluded from scoring but still kept and visibly marked on the graph, and fully approved windows are still recorded. Every entry shows what it covers and how much it has excluded over the last seven days, so entries nobody needs any more are easy to find.
- Backup and restore. Whitelist entries are the only thing in Logster your analysts create by hand. They can now be exported to a file and restored from the console or from a script.
- Unknown parents handled safely. When a process’s parent started before Logster began observing, the parent appears as an unknown placeholder. Placeholders can now be included in approvals, but Logster refuses any approval where an unknown parent is the only actor, because “unknown” would otherwise match any long-running program, malware included.
Why this matters beyond convenience: every suppression that nobody can explain later is tuning debt, a permanent blind spot. Approvals should stay visible, measurable and reversible, and Logster v1.3.0 is built that way.
Evidence you can click
When Logster flags an attack, it explains its reasoning. In Logster v1.3.0 that explanation is connected to the evidence.
Open an investigation and the events behind the verdict move to the top of the list. The graph highlights the handful of nodes that form the attack chain, out of what can be dozens of routine ones. Click a step in the explanation, for example “PowerShell wrote to the startup folder”, and the graph spotlights exactly the nodes that step refers to.
This runs only when an analyst opens an investigation, so it never slows detection. It also annotates the original verdict rather than re-deciding it, so what you click through is the reasoning that produced the alert. Linux events now carry the same traceability back to their source, so this works across Windows and Linux.
It answers the question we think every buyer should ask a detection vendor: show me a finding exactly as an analyst receives it. (More on that in our guide to evaluating threat detection platforms.)
Storage that looks after itself
Security data grows quietly until the disk fills up, usually at the worst possible moment. Logster v1.3.0 adds storage-aware retention.
- Sensible defaults out of the box: events for 30 days, detections for 90 days, activity graphs for 14 days.
- If disk usage crosses its target anyway, the oldest data is removed first, before storage becomes an outage.
- The System Health dashboard now shows storage use per data type with a forecast against the target, plus message-queue lag, so you can see a problem coming.
Built for air-gapped environments
For organisations that can’t send security data anywhere, the Logster AI model can now be delivered separately from its runtime image and loaded from local storage inside an air-gapped OpenShift cluster. The runtime image is much smaller, the two downloads can be verified independently, and the model runs fully offline with no internet access at runtime.
Under the bonnet
A few smaller things that shipped with Logster v1.3.0:
- The Splunk receiver has been rebuilt in Rust, and correctly handles large, multi-line PowerShell events.
- Shipped container images passed our release security scan with zero known fixable CVEs, including a move to a hardened, rebuilt monitoring image.
- Linux events collected through eBPF and auditd now keep a link back to the original event, so every node in a Linux graph can be traced to its source.
- Many stability improvements across ingestion, inference and the dashboard.
Upgrading to Logster v1.3.0
Logster v1.3.0 is available now. Upgrade instructions from v1.2.1, including the new retention settings, are in the Logster documentation.
If you’d like to see Logster v1.3.0 on your own data, get in touch.