A self-hosted security tool is only as trustworthy as the machine underneath it, and in many teams that machine is the last thing anyone chooses. Weeks go into comparing detection rules and dashboards, then the whole stack lands on whatever server had room that quarter. That order looks backwards.
Running your own log platform or intrusion sensor makes you responsible for everything a vendor used to handle out of sight, and the requirements that decide whether it works mostly sit below the software. Nine of them follow, ranked by the damage their absence tends to cause.
Keep the Watcher Off the Open Internet
The first, and in most setups the most important, is keeping the security server walled off from the open internet and from most of the network it watches. Wazuh, a popular open-source platform for collecting logs and raising alerts, fixed a flaw rated 9.9 out of 10 for severity in version 4.9.1. The flaw let anyone with access to the server’s management interface run their own code on the machine. Botnets were trying a published exploit within weeks of the February 2025 disclosure, and that June an internet-wide scan counted more than 17,000 Wazuh servers answering on the open internet, plenty of them giving no clue which version they ran.
Wazuh’s own response to the reports stressed that exploitation needs valid administrator credentials and a server interface reachable by the attacker, usually over the internet, which the company says it strongly discourages. That’s fair. It’s also most of the case for isolation. A security server usually holds agent keys, alert rules and a searchable record of everything that happened on the network, which arguably makes it the most useful single machine an intruder can reach.
Isolation in practice is dull work. The server lives on a network of its own, and only its agents and a short list of administrators can talk to it. Its management screens shouldn’t answer on any public address, password or no password. Default credentials get changed on installation day rather than later. It’s also worth asking someone outside the office to try reaching the management port from a home connection once a quarter, because firewall rules tend to drift once the original installer has moved on.
Hardware With No Neighbors
The second requirement is hardware the tool doesn’t share. On a crowded virtual host, a log platform competes with other tenants for processor time and disk access, and the competition tends to be fiercest during an incident, when event volume spikes. Sharing also means trusting the software layer that keeps tenants apart, and that layer has its own bad days. In March 2025, Broadcom disclosed already-exploited flaws in VMware’s ESXi virtualization software that let someone with administrator rights inside one virtual machine run code in a process on the host beneath it.
If you go shopping for dedicated hosting with this job in mind, Atlantic.Net is a fair benchmark for what the category ought to include. Its servers are private physical machines that share no resources with other customers. Incoming bandwidth isn’t metered either, which matters more than it sounds for a log platform, since that kind of machine spends nearly its whole life receiving data from everything else. Full root access completes the picture, because almost everything argued here assumes the operator, not the landlord, decides what runs on the box.
The questions worth asking any provider are mundane. How incoming traffic gets billed matters most, since an incident can multiply log volume for days at a time. It also helps to know whether a second, smaller machine can be added later for testing updates, and whether disks can be chosen by type rather than taken as the plan comes. Vague answers often suggest a plan built for web hosting, which is a different workload with different peaks.
Memory and Processors for the Worst Day
Third, size memory and processors for the worst day instead of the average one. One widely used open-source monitoring suite treats 24GB of memory as the bare floor for a single-box install and suggests 32GB for anyone watching even a modest amount of live traffic. For its sensors it recommends dedicated physical hardware, so they aren’t fighting other workloads for the same processors. It labels those figures the absolute minimum, and the label looks honest. Memory should be generous enough that the machine never borrows disk space to stand in for it, since disk is far slower than memory and the slowdown arrives under peak load.
An undersized box rarely crashes when it falls behind. More often it drops traffic it was meant to inspect and delays alerts, and it tends to do so in the busiest hour of the worst week, which is the hour everyone will ask about later. Suricata, the detection engine inside several of these suites, keeps a running count of packets discarded before inspection, refreshed every eight seconds by default, and its documentation warns that the network card may be dropping more on top of that. A weekly look at those counters, together with a replay of a busy day’s recorded traffic before go-live, will usually expose an undersized machine long before an incident does.
Retention Math Before Installation Day
Storage is the fourth requirement, and it’s probably the one most often settled by guesswork. Recording full traffic on a link that averages 50 megabits a second fills roughly 540GB of disk a day, and the searchable logs come on top of that. Somebody has to decide how many days of history an investigation will really need, multiply the daily figure by that number, then leave headroom for the week when everything goes wrong at once. Those disks should also be local. The same suite supports only local storage, on the reasonable grounds that network storage adds failure points to the one system that has to keep writing while everything around it is on fire.
A full disk also fails in an unhelpful way. OpenSearch, the search engine underneath several of these platforms, can mark its indexes read-only once a node passes 95 percent disk use, which protects the data already stored and stops new events from landing. A warning at 75 or 80 percent, backed by a retention policy that deletes or archives old indexes automatically, turns that cliff into a scheduled chore. Teams that skip this step often discover the problem as a gap in the timeline.
Two Network Paths
Fifth, the network has to give the tool two things most office networks don’t offer by default. One is a faithful copy of the traffic, delivered to a network connection that carries nothing else. The other is a separate route for managing the tool, so administrators never log in across the same wires the tool is watching. Neither idea is exotic, and a basic security checklist for enterprise networks already puts intrusion detection beside firewall rules and access reviews.
Few teams budget the switch ports and cabling before installation day, which is often when someone learns the office switch can’t copy traffic at all. Checking the switch model’s mirroring support takes minutes. Confirming that the copy carries traffic in both directions matters just as much, because a sensor that sees only half of each conversation tends to produce alerts nobody can interpret.
Updates on Your Own Schedule
An update path you control comes sixth, and this year has already shown what the alternative looks like. In March, an attacker holding publishing credentials that should have been revoked after an earlier incident pushed a poisoned release of Trivy, a widely used open-source vulnerability scanner, and repointed 76 of the 77 version labels on its automation add-on to credential-stealing code. That code ran before the real scan, so affected jobs appeared to finish normally. Trivy’s maker, Aqua Security, sells a commercial edition that never received the bad release, because it deliberately trails the open-source version and sends each change through a gated review. A delay most teams would call a weakness did the protecting.
Self-hosting offers the same protection, but only if the infrastructure exists to use it. In practice that means a second, smaller machine where new versions of the software and its detection rules run for a few days before production sees them, plus an internal copy of every package fixed to an exact build. Guidance on stopping supply chain attacks before they reach production makes the same case for pinning each input to something that can’t silently change. Version labels, as the Trivy case showed, can move whenever someone with the right credentials decides they should.
For a small team, a workable rhythm is a week on the test machine for routine releases, with a faster lane reserved for fixes to flaws already being exploited. Subscribing to each project’s security advisories is what makes that exception possible, since nobody can fast-track a patch they haven’t heard about.
Clocks That Agree
Seventh, and cheapest, every machine feeding the platform needs to agree on the time. An investigation is mostly an argument about order, about which login came before which file appeared. When a few servers drift by several minutes, that order gets muddy, and an attacker’s actions can seem to happen before the thing that caused them. Anyone who has tried to line up a firewall logging in local time against a server logging in universal time knows the particular misery of an investigation that spends its first afternoon on arithmetic.
Pointing everything at one internal time source costs almost nothing, although a single source is itself a single point of failure. The IETF’s best-practice guidance for network time recommends at least four independent sources for operators who care about accuracy, and it advises monitoring those sources for disagreement. Running two or three small internal time servers that each draw on four or more upstream sources, with an alert when any log source drifts by more than a second or two, is a modest job. It still gets skipped, often because nobody notices the drift until the week it matters.
Copies the Intruder Can’t Reach
Eighth is a way back that doesn’t depend on the security server surviving. An intruder who reaches that server can edit or delete the record of how they got in, so copies of the logs belong somewhere that server can’t write to or erase. The configuration deserves the same care, since detection rules tuned over two years are often worth more than the hardware they run on and tend to exist in exactly one place.
Recovery is also where organizations tend to overestimate themselves. In Veeam’s 2025 ransomware survey of 1,300 organizations, only 10 percent of those attacked recovered more than 90 percent of their data, and while nearly every respondent had a ransomware playbook, fewer than half of those playbooks covered backup verification. A quarterly drill that rebuilds the security server on spare hardware and restores the rules plus a week of logs tends to surface the missing piece while it’s still cheap to fix. Timing that drill matters too, because the result is the honest answer to how long the organization would be blind.
Power is the stranger risk. The search databases underneath most of these platforms handle sudden shutdowns badly, and the monitoring suite mentioned earlier suggests putting a battery backup in front of production hardware. A thunderstorm can leave months of evidence needing repair before anyone can search it.
Who Reads the Alerts?
Ninth comes the requirement no purchase order covers, which is a named person with protected hours to read what the machine says. Self-hosted platforms tend to be noisy out of the box, and the noise is an industry-wide complaint. In a SANS survey published in late 2025, false positives topped the list of detection problems, cited by 73 percent of respondents against 64 percent a year earlier, with a shortage of skilled staff not far behind.
Most of the work of tuning a platform is deciding which findings can safely wait and writing down why, so the next person doesn’t reopen every decision. An hour a week is a reasonable starting budget for a small deployment. The noisiest rules deserve that hour first. Each suppression should carry a reason and a review date, and the last few minutes belong to confirming that every expected source is still sending. Without that owner, the other eight requirements tend to erode, and updates usually go first because they never feel urgent on any given Tuesday.
Where Self-Hosting Loses the Argument
Here the argument has to turn on itself a little. For a company that can’t name that person, a managed service run by people who do nothing else may be safer than a self-hosted stack sitting on excellent hardware and nobody’s attention. Self-hosting still earns its place where the data can’t leave infrastructure the organization controls or where volumes make per-gigabyte pricing absurd. It just punishes neglect faster, since no vendor’s staff is there to absorb it. The awkward part is that the teams most drawn to self-hosting, small ones with tight budgets and firm opinions, are often the least able to give anyone those protected hours.
Run the Silence Test
Anyone already running one of these platforms can try an uncomfortable test this week. Pick one server that feeds the platform and stop its log forwarding on purpose. The number that matters is how long it takes for anyone to notice. After that, walk through the nine requirements against the current setup and mark each one as met, partly met or missing, starting with whether the management screens answer from the open internet. The result is a short, honest document to put in front of whoever signs off on the budget.
Somewhere on your network sits a machine that records everything and answers to almost no one. If it stopped collecting at midnight, the dashboards wouldn’t necessarily look wrong at nine the next morning, any more than those poisoned scanner jobs did. So who would notice first, and how many days would pass before they did?
