Silenced sources
Autonomous, Multi-Tenant Silenced Sources Monitoring
The Silenced Sources Detection Engine is designed to operate in a fully autonomous manner, requiring no manual intervention from SOC analysts.
Once a data source is integrated into the platform, it is automatically discovered, baselined, and continuously monitored. No configuration, rule creation, or tuning is required, as the engine applies its detection logic by default to all sources reporting activity.
The engine natively supports multi-tenant environments, ensuring that monitoring and anomaly detection are applied independently and securely per tenant. Behavioral baselines, anomaly thresholds, and alerting decisions are maintained in isolation for each customer and for each source.
As new sources are added to the platform—either directly or indirectly through other integrated systems—they are automatically included in the monitoring scope. This guarantees consistent coverage across the entire platform without additional operational effort.
By fully delegating silenced source detection to the platform, SOC operations benefit from reduced overhead, uniform visibility, and faster detection of log ingestion disruptions. This approach allows analysts to focus on investigation and response activities, while the platform continuously ensures the integrity and completeness of log flows.
Mission
The Silenced Sources Detection Engine designed to identify situations where an integrated data source—either directly connected or indirectly reporting through another integrated source such as a SIEM or a firewall—stops sending logs to the platform.
A loss of log activity can indicate either:
The impact of a cyberattack (e.g. attacker disabling logging, network segmentation, system compromise), or
A customer-side infrastructure or a simple firewall missconfiguration
In both scenarios, this condition represents a critical loss of visibility and must be detected and reported with high urgency.
Behavioural Baseline and Pattern Modeling
Once sources are discovered, the engine establishes a behavioural baseline for each individual source.
This baseline includes metrics such as:
Normal log volume over time
Event frequency and distribution
Temporal patterns (hourly, daily, seasonal)
Expected variability ranges
Using this baseline, the engine continuously evaluates incoming log streams to detect anomalies.
Anomaly-Based Alerting
Alerts are generated based on behavioral deviations, including:
Complete loss of logs from a source
Significant drops or spikes in log volume compared to the established baseline
Unexpected changes in reporting patterns
Rather than relying on static thresholds, the engine uses anomaly detection techniques to adapt to the normal behavior of each source, improving detection accuracy in dynamic environments.
Endpoint Behaviour Filtering and False Positive Reduction
Because the silenced sources detection process is fully automatic, certain common operational scenarios may otherwise generate false positives.
A typical example involves user endpoints such as laptops or workstations that:
Begin sending logs when employees start their workday
Stop sending logs when systems are powered off at the end of the day
Since these endpoints are automatically detected as log sources, their expected shutdown could be misinterpreted as a silenced source.
To prevent this, the platform automatically identifies sources with a low and intermittent event profile, characteristic of end-user endpoints. Sources matching this behavior do not generate silenced source alerts when they stop reporting events, as this is considered normal behavior.
Critical Low-Volume Sources and CMDB Severity Override
In some environments, there are critical assets that generate a low volume of events, such as:
Small Windows servers
OT or industrial devices
EDR agents with low event frequency
These sources may resemble endpoint behaviour from a volume perspective but must always be monitored for availability.
To ensure that these assets are never excluded from silenced source detection, the platform relies on CMDB severity configuration.
Any source configured with Critical severity in the CMDB will:
Always generate a silenced source alert
Be monitored regardless of its event volume or behavioural profile
This mechanism allows SOC teams to combine automatic behavior-based filtering with explicit operational importance.
Configuring Critical Sources in the CMDB
To ensure that a source always triggers a silenced source alert, follow these steps:
Access the Administration section of the platform
Navigate to CMDB
Identify the sources that must always be monitored for silence
Configure them as critical severity
By combining behavioral baselining, endpoint filtering, and CMDB-driven severity overrides, the platform provides accurate silenced source detection while minimizing false positives and maintaining full coverage of critical assets.
Last updated