Three tools, three blind spots
what we learn by crossing them

Three sources, three blind spots

A fleet is rarely monitored with a single tool. With us, three systems watch different things and each is blind to what the others see:

Tool	What it sees	What it does not see
SIEM (Wazuh)	System logs, file integrity, accounts, machine vulnerabilities	What happens on the network between machines
Network monitoring (Observium)	SNMP availability, interfaces, errors, throughput	What happens inside machines
Firewall logs	Every authorized or denied connection, with source, destination and rule	A compromised process calling out in HTTPS

None of the three suffices alone. But together, they answer the question that matters: did something abnormal happen today?

What firewall logs really say

Over twenty-four hours, two Stormshield appliances produced a little over 7.9 million authorized events and 5,436 denials. The one-to-fifteen-hundred ratio is the normal order of magnitude for an enterprise network: the vast majority of traffic is legitimate, and the background noise of scans is absorbed by rules.

What makes these logs exploitable is not their volume but their structure: each line carries the appliance identifier, the rule that decided, the inbound and outbound interface, the source, the destination, the port and the action. Without these fields, you have a text file; with them, you can answer in one query "who is trying to get in, and on what".

A detail noted in passing: the most frequent alerts are not attacks but IP address spoofing attempts a host pretending to be a gateway. It is often a sign of network misconfiguration (two DHCPs, a poorly isolated bridge) as much as malice. A security log that is not read by alert type lets this kind of signal through.

Fixing a mute agent: the textbook case

A Wazuh agent can be active and deliver nothing. Ours pointed to a manager address that no longer existed, the old one, changed during a migration. The service ran, reconnected every two minutes, and failed silently. Four hundred eighty-six days without a single event.

The fix is one line in ossec.conf and a restart. The lesson is elsewhere: nobody was watching this silence. An offline agent produces no alert, it produces absence, and absence looks like "nothing to report".

When the indexer saturates, the SIEM goes deaf

A more subtle failure still: the manager was generating its alerts, but the indexer refused to store them.

validation_exception: this action would add [1] total shards,
but this cluster currently has [1000]/[1000] maximum shards open

The dashboard kept displaying curves, those from the past. The present was no longer recorded. It is the trap of aging systems: they do not crash, they freeze.

The rule we apply now

Three checks, independent of the tools, and sent outside the monitored platform:

• Dated silence. Any agent without contact for more than 24 hours becomes a named incident, not a gray line.
• End-to-end. "The service is running" means nothing. We verify that the data arrives at the consumer: host presence in the indexes, today's line in the log, counter not frozen.
• Off-platform report. A daily message on a phone, produced by a system that is not the one it monitors. If the SIEM dies, the report keeps saying it is dead.

What cannot be automated

None of these checks replaces a decision. A CIS score at 23% does not say whether to patch tonight; a spoofing alert does not say whether it is a duplicate DHCP or an intrusion. Automation serves to ask the question in the right place, not to answer it.

And the most useful question remains the simplest: how long since my most critical machine last spoke?

Sources

• Wazuh, manager settings and OpenSearch, cluster settings: shard limit and consequences on indexing.
• VictoriaLogs, LogsQL language: field extraction and aggregation on large volumes.
• Stormshield, documentation: connection and alert log format.
• Observium: SNMP monitoring, alerts and network inventory.

Findings from October 31, 2026 on our infrastructure: two Stormshield appliances, 7.9M authorized events and 5,436 denials over 24h. No address, no machine and no internal identifier cited.