Skip to content
ZEROWARN
When one server becomes many

A platform, not a lone agent

On a single server SHIELD is already complete: detection and containment do not depend on there being more machines alongside. What changes as you grow is the operation —calibrating, updating, correlating, auditing— and it ships with everything that takes.

It calibrates itself

It adapts on its own to every interpreter version and build, even to binaries with no symbols. You install a new version and it just appears, ready, with nothing to restart. Zero manual maintenance.

How does it do it?

It reads the binary's internal information to find where the data it cares about lives. If that is missing, it runs the binary for a few moments in an isolated environment and watches it from inside the system until it works it out. From that it produces a signed map of that specific binary and applies it live, with no restart. A watcher spots new binaries by their fingerprint and launches the whole process by itself, with room for up to 16 different versions or builds living side by side on the same machine, each with its own calibration. The same goes for libraries that appear later —a database driver, a crypto library—: it hooks them in seconds.

It learns from your fleet

Every server contributes signals to the whole, and a statistical gate decides which improvement is worth shipping — and only if it does not raise the current false-positive rate. It tunes itself, with no dependency on anyone else's cloud.

How does it do it?

Agents report observations, never labels: compromising an agent cannot move the model. The central merges them, removing duplicates and with caps that stop any single one from skewing it, and a statistical test decides whether an improvement is solid: it only ships if it does not raise the current false-positive rate. Heavy retraining happens outside your production servers.

Shared intelligence

What one server learns protects the rest: models and reputation lists travel signed between your machines and are verified before they are applied. An attack on one immunises the others.

How does it do it?

Models and reputation lists are packaged cryptographically signed, travel encrypted between your machines, and each agent verifies signature and content before installing them, in an instant switch with no downtime. The reputation one server learns goes into the same place where everyone else's lives.

Panel, triage and your SIEM

Cases, timeline, indicators and an audit trail by plane and by rule, in a panel for your team. And all of it exports natively to your SIEM. Triage is annotated and closed on evidence nobody can alter.

How does it do it?

The panel reads a sealed feed produced by the agent itself. The analyst's work —flag, annotate, close— lives in a separate layer that never touches the original evidence, which is immutable and chained, and has its own audit trail. Output goes straight out in your SIEM's format: ECS for Elastic and CEF for ArcSight or Splunk, with no adapter to write. And for day-to-day work there is an admin command line, health checks and standard metrics your monitoring already knows how to read.

It protects itself

It obeys only signed orders, proves its own integrity and, if it loses contact with control, returns to a safe state on its own. An attacker cannot switch it off quietly.

How does it do it?

It only accepts signed orders with an increasing sequence number, so nobody can replay an old one; and if it stops hearing from control, it returns to its safe configuration by itself. On machines with a security chip (TPM) it also measures its own components at startup and leaves a fingerprint that cannot be faked, which the central verifies remotely: the agent's integrity is not taken on trust, it is checked.

It updates without drama

Every update is signed, with a backup taken first, a health check and automatic rollback if anything goes wrong. It never stops halfway or leaves you with a hung server.

How does it do it?

It verifies the signature and rejects the update if it is not valid. It backs everything up —binary, configuration and models—, swaps the binary in one go, migrates your configuration while respecting your settings, and restarts. And it does not call the update good until it has confirmed the new agent started and is really watching: if any step fails, it undoes everything automatically and leaves the server as it was.

It fits in as-is

It fits your infrastructure exactly as it is

No migrations, no maintenance windows and not one line of your configuration to change. This is what your systems team wants to hear before approving a pilot.

Your servers, as they are

Any current server Linux, on Intel, AMD or ARM: Debian, Ubuntu, RHEL, AlmaLinux, Rocky, Alpine… your distribution already works. Containers too, with one agent per node.

Zero changes in production

No proxy in front, no interpreter modules, no vhost to edit. Your site and your PHP carry on exactly the same: nothing to restart.

All your PHP versions

From the oldest to the newest, side by side on the same machine and with nothing installed inside the interpreter. You roll out a new version and it recognises it on its own.

Featherweight

≈50 MB of RAM and under 1% of one core, hour after hour. A few megabytes on disk: your accounts-per-server density does not move.

Your databases

MySQL and MariaDB, PostgreSQL, SQL Server, MongoDB and Redis — and it keeps seeing them even when the connection is encrypted.

One single piece

One service and that is it. No dependencies, no repositories to add and nothing to compile on each machine.

Your SIEM and your monitoring

Events arrive in the format your SIEM already understands and metrics in the standard your monitoring already collects. Nothing to write.

Containers too

One agent per node for fleets running on Kubernetes, with the same configuration and the same file.

Your data stays home

The panel is private by default and not one byte leaves your servers unless you connect it to your own central, over a channel encrypted and authenticated at both ends.

See it on your own data

Deploy the agent on three servers and leave it in observation mode. Within days you will have the figures for your own traffic: what it would have detected, what it would have contained and with how much noise. Turning on blocking is a later configuration change, and it is your call.