Release notes
Detailed notes on the features, improvements, and fixes shipped in each IDPS-ESCAPE release. For the full list of all changes see the changelog.
v2.0.0
August 2026Manager-centric enrichment architecture
Enrichment logic has moved out of the endpoints and into the Wazuh manager. A new
manager-enrichment package (enrichment.py,
web_enrichment.py, geoip.py, state_store.py)
centralizes GeoIP and web enrichment processing, integrated directly with manager
workflows and web endpoints.
Agents now ship raw /var/log/auth.log directly instead of running a
per-endpoint enrichment helper, venv, and systemd service. This also fixes per-user
velocity/ASN state, which was previously tracked separately per endpoint instead of
centrally.
Migrating an existing deployment: set MAXMIND_LICENSE_KEY
in the manager's .env, redeploy with
sudo ./build-radar.sh suspicious_login /
geoip_detection, then re-run bootstrap-agent.sh on every
existing endpoint. Manager and agent updates must land together per endpoint.
Manager APIs, CLI, and deployment orchestration
A major API redesign supports the new manager-centric enrichment flow, with a new
wazuh_api module providing programmatic and CLI access to manager
operations. Manager-side helper scripts under radar_deploy
(apply-scenario, assign-agent-group, ensure-certs,
health, local-agent, mint-token) are now driven by
top-level radar.sh and bootstrap-agent.sh entrypoints.
Enrollment hardening & agent lifecycle management
New scripts secure and manage Wazuh agent enrollment end to end: manager-harden-enrollment.sh
enforces password-protected enrollment with purge disabled and cluster key management;
manager-enrollment-window.sh opens and closes time-limited enrollment
windows via firewall rules on port 1515. Webhook deployment now mints a short-lived
registration token when needed and persists agent state.
| Script | Purpose |
|---|---|
manager-deregister-agent.sh |
Deregister an agent from the manager. |
manager-unassign-agent-group.sh |
Unassign an agent from a scenario group. |
manager-undo-scenario.sh |
Undo a scenario deployment and remove its rules, decoders, and lists. |
RADAR GUI: manager-flow & undo actions
The Deploy, Infrastructure, and Connectors pages have been adapted to support the new manager-centric deployment flows. Every deployment action now has a corresponding undo action in the GUI: deregister agent, undo deployment, and unassign agent group.
Scanning detection scenario & DECIPHER risk scoring
Scanning-detection rules, agent configuration, and manager snippets were updated per SRS-066. DECIPHER CTI scores are now factored into RADAR's risk score computation and case creation in FlowIntel. The scanning simulation and its tests were reworked with interactive execution and verification-aware waits.
Log-volume endpoint collection via systemd
bootstrap-agent.sh --group log_volume now installs and enables a systemd
service/timer that records /var/log size every 30 seconds, with the Wazuh
agent watching the resulting file. uninstall-agent.sh removes the collector,
timer, and logrotate configuration, and can optionally purge its data.
Documentation restructuring & simulation standalone mode
Custom deployment guides moved from /deployment/ to
docs/manual/custom_deployments/; legacy Ansible playbooks and deprecated
Wazuh installation guides were removed, and RADAR operational and user documentation was
streamlined and consolidated. Radar simulation scenarios now run standalone on the
endpoint without depending on Ansible automation.
Ansible cleanup & archived scenario removal
Ansible role tasks and playbooks (health_check, wazuh_agent
playbooks, multiple wazuh_manager tasks) were removed as part of the
redesigned manager workflow. Unmaintained archived scenarios — DDoS detection, GeoIP
detection, and insider threat — were removed from radar/archives/ to
streamline the codebase.
Build & project layout cleanup
Per-component Dockerfiles and run scripts were relocated into their own subdirectories
(sonar/Dockerfile.sonar, adbox/Dockerfile.adbox,
adbox/Dockerfile.test, adbox/adbox.sh,
adbox/run_test.sh, sonar/sonar.sh), replacing the former
root-level Dockerfiles and scripts. The root-level radar.Dockerfile and the
per-component .devcontainer/adbox and .devcontainer/radar
configs were removed, consolidating on the single root
.devcontainer/devcontainer.json.
Test specifications TST-055 – TST-058
New unit and integration tests were added to match the manager-centric redesign, and new test case specifications TST-055 through TST-058 were published, alongside updated RADAR manuals and specifications.
v1.1
May 2026Web scanning detection scenario
A new production-ready RADAR scenario detects web-layer attacks via
signature-based detection on Apache/Nginx HTTP access logs, using the
built-in web-log decoder. Detections trigger an automated response with a
firewall-drop active response and email notifications for high-risk events.
The scenario ships with full documentation
(scanning_detection_explained.md — objectives, detection methodology, manual
setup, and deployment instructions), a formal system requirement specification with
acceptance criteria and test specification, and a test report execution for the
scanning_detection scenario.
RADAR default-rule support
ar.yaml and radar-default-ossec-snippet.xml were updated with
new default warning rule IDs 23503, 23504, and
23505, using the authentication_failures rule group. A new
default simulation exercises the default Wazuh ruleset end to end from the
existing simulation entrypoints; default is now an explicit scenario option
restricted to --agent remote.
config.yaml gained scenarios.default.simulate configuration
support, and simulate.yml was extended with a new default block
that downgrades to a vulnerable version and schedules an independent safety-net restore
after safety_net_minutes. Test specifications and execution reports for the
default-rule flow, active response handling, and simulation behavior were added across
TST-053 and TST-054.
Rule group support in Active Response
The RADAR Active Response script now resolves scenarios by rule group in addition to
rule ID. test_radar_ar.py was updated to cover canonical rule group naming
and accurate scenario identification behavior.
v1.0
May 2026RADAR web interface
A Flask-based control panel (app.py) introduces a four-page web interface
for managing and operating RADAR scenarios without direct server access.
Three new system requirements formalise the subsystems: SRS-063
(REST API contract), SRS-064 (frontend specification), and
SRS-065 (Ruleset-as-Code).
| Page | Purpose |
|---|---|
| Active Responses | Per-scenario configuration of risk weights, detection scoring, time windows, tier boundaries, and per-tier mitigation actions. |
| Infrastructure | Full Ansible inventory management with cards for each manager and agent showing connection type, IP, and credential status. |
| Connectors | Credential and URL management for OpenSearch, Wazuh API, OpenSearch Dashboards, SMTP, DECIPHER, and Webhook. |
| Deploy | Three-tab interface for running build-radar.sh (Build & deploy), run-radar.sh (Run scenarios), and health-radar.sh (Status). |
A new user manual radar-gui-user-manual.md covers first-time setup, and the
product presentation website has been extended with a RADAR GUI gallery section featuring
four screenshots.
Ruleset as Code (RaC)
A GitHub Actions-based CI/CD pipeline enables developing, reviewing, and deploying Wazuh
rules and decoders without direct server access. New documentation in
radar-rules.md covers the Wazuh rules repository structure and workflow.
Off-hour login detection & GeoIP frequency rule
A new system requirement SRS-062 specifies per-user behavioral baseline
detection of authentication events outside business hours (Mon–Fri, 07:00–20:00) using
OpenSearch RCF with a data.user.keyword categorical field.
A new GeoIP frequency rule provides an escalation path for coordinated geographic anomalies by detecting high-frequency authentication attempts from non-whitelisted countries.
RADAR container hardening & active response logging
Security hardenings have been applied to all RADAR container Dockerfiles.
Active response logging has been enhanced in radar_ar.py to always record
planned mitigations — including would_be_mitigations when
allow_mitigation is false — improving observability and the audit trail for
response decisions.
SpecEngine C5-DEC v1.3 upgrade
The dependency content fingerprinting feature of SpecEngine has been integrated into IDPS-ESCAPE, enabling automatic detection of stale Doorstop links when upstream requirement content changes.
Test specification TST-050 & report TRP-040
A new test case specification TST-050 covers the SONAR Linux resource monitoring scenario (v1.0). The corresponding execution report TRP-040 records the v1.0 test campaign results: 6/6 steps passed on 2026-05-04 in debug mode.
v0.9
April 2026Apache/Nginx web access log support for GeoIP detection
The GeoIP detection scenario now covers HTTP/HTTPS web server traffic in
addition to SSH authentication events. A new accesslog decoder
(0375-web-accesslog.xml) parses Apache and Nginx access logs, and a new
detection rule 100902 triggers on requests originating from non-whitelisted
countries. The accompanying SRS-055 requirement has been expanded with web
server log monitoring scope and updated acceptance criteria covering the new rule and test
cases.
Unit tests for GeoIP enrichment have been extended to cover the new log formats, and the
geoip_detection_explained.md documentation has been updated with Apache and
Nginx configuration examples for enabling source-IP GeoIP monitoring over web traffic.
Multi-node Wazuh deployment support
IDPS-ESCAPE now fully supports multi-node Wazuh manager topologies. The deployment guides and Ansible automation have been updated with multi-node configuration parameters, topology guidance, and precondition details for the Ansible executable.
Optional data ingestion flag for detector training
A new --ingest flag for run-radar.sh decouples synthetic
dataset ingestion from scenario deployment, enabling both fresh deployments that require
training data and production deployments that rely on live data. A BATS test case
validates the flag’s behaviour end-to-end.
Webhook bootstrap & reliability improvements
A dedicated bootstrap_webhook.yml Ansible task enables independent
webhook service deployment. Container initialisation has been made more reliable through
state-aware checks and retry logic, and the health check now uses explicit file lists
instead of pattern matching for higher reliability.
Anomaly detection threshold-based filtering
Anomaly detection accuracy has been improved through configurable threshold-based filtering rules, reducing false positives in noisy environments without requiring model retraining.
Test specification TST-049 & report TRP-038
A new comprehensive test case specification TST-049 for RADAR integrity testing has been added, along with the corresponding execution report TRP-038 capturing the v0.9 test campaign results.
v0.8
March 2026SATRAP-DL DECIPHER integration for real-time CTI analysis
The stub SatrapClientMock has been replaced by a fully operational
DecipherClient connecting to the DECIPHER REST API.
RADAR now performs real-time Cyber Threat Intelligence (CTI) analysis via the
analyze endpoint and creates incident cases via create_incident
as part of the tiered active response pipeline.
A new system requirement SRS-061 formalises the tiered active response
logic with DECIPHER risk-based decision making. Environment configuration has been updated
with dedicated DECIPHER_BASE_URL, DECIPHER_VERIFY_SSL, and
DECIPHER_TIMEOUT_SEC variables, replacing the earlier FlowIntel-only env vars.
| Endpoint | Purpose |
|---|---|
analyze |
Real-time CTI enrichment — scores IOCs against threat intelligence sources (MISP, SATRAP). |
create_incident |
Opens an incident case in FlowIntel when the risk tier warrants escalation. |
RADAR health check
Manager-side and agent-side health checks via health-radar.sh verify the
status of all RADAR elements using dedicated Ansible tasks. The checks cover container
liveness, Wazuh connectivity, and RADAR component availability, enabling rapid
diagnosis of deployment issues.
RADAR attack simulation
A new simulate-radar.sh orchestration script drives attack simulations
across three RADAR scenarios — GeoIP detection, log volume,
and suspicious login — using Python simulation modules. An Ansible
playbook extends simulation support to remote agents via SSH key authentication, enabling
end-to-end validation of the full detection and response pipeline without real attacker
traffic.
Tiered active response configuration
The active response configuration has been redesigned around explicit tiers.
tier1_min defines the Tier 0 boundary for low-risk events handled without
escalation. Mitigations are now split into per-tier mitigations_tier2 and
mitigations_tier3 keys, and the redundant risk_threshold and
create_case keys have been removed. IOC extraction now includes country,
ASN, and agent fields; domain extraction filters out file-extension-like TLDs.
SpecEngine C5DEC v1.2 upgrade & new tooling
All SpecEngine scripts have been consolidated under docs/specs/SpecEngine/.
New tools added in this release include c5graph.py (interactive spec graph
viewer), c5mermaid.py (Mermaid diagram rendering), c5traceability.py
(traceability matrix with coverage metrics and HTML report), c5browser.py
(Bootstrap + DataTables items browser), prune_bad_links.py (link hygiene),
and doorstop_yml_to_md.py (item migration helper). The dev container has been
extended with Node.js 20, Chromium, and the Mermaid CLI to support diagram rendering.
TRP document type & v0.8 test campaign
The separate TRA and TRB Doorstop document types have been merged into a single TRP (Test Case Execution Report) document type. v0.8 test campaign results are captured in TRP-030 through TRP-037.
RADAR helper & suspicious login improvements
The velocity cap has been removed from the RADAR helper; speed calculation now uses
the log timestamp instead of the processing time, and a dt_eps constant
prevents division-by-zero when events share the same timestamp. A new suspicious login
correlation rule has been added. Country-change and ASN novelty tracking are now
maintained independently per user. Unit tests reflect all these changes with two
additional tests.