IDPS-ESCAPE v2.1.0 on GitHub - Abstractions Lab

A manager-centric, hardened RADAR, tightly integrated with SATRAP-DL

We are pleased to announce IDPS-ESCAPE v2.1.0, now available on GitHub.

1D1B2_LOG_IDPS-ESCAPE-Stable-Geometrized-400x400_v1.0

Since the v1.0 release in May, RADAR, the risk-aware detection and automated response subsystem of IDPS-ESCAPE, has gone through three releases:

v1.1 added a new web scanning detection scenario.
v2.0 redesigned how RADAR is deployed and run.
v2.1 makes it deployable on existing Wazuh installations and hardens it for production use.

Throughout, RADAR’s integration with DECIPHER, the CTI analysis and incident-handling service of SATRAP-DL, has become a core part of every response decision.

Highlights

Threat intelligence in every risk decision. RADAR asks DECIPHER to assess the indicators of an alert before scoring it. The resulting CTI score is part of RADAR’s risk score, and every alert that crosses the first risk tier gets a Flowintel case, opened automatically.
Manager-centric architecture. Enrichment, such as GeoIP lookups and login history, now runs on the Wazuh manager instead of on every endpoint. Endpoints simply forward their logs.
Simpler onboarding. Endpoints join in a single step, using short-lived enrollment tokens, and every deployment step can be undone from the web control panel.
Hardened for production. v2.1.0 secures the control panel, credentials, the anomaly-detection pipeline and the automated responses themselves (details below).
New web scanning detection scenario for Apache and Nginx access logs.
No more Ansible. RADAR no longer depends on Ansible. Deployment, onboarding, health checks and attack simulations all run with RADAR’s own tooling, so no configuration-management stack is needed on the manager or the endpoints.

RADAR and SATRAP-DL: detection meets threat intelligence

RADAR decides how to respond to a threat by combining three signals into a single risk score:

behavioral anomalies detected by OpenSearch Anomaly Detection;
known attack patterns matched by Wazuh and Suricata rules;
cyber threat intelligence from DECIPHER.

When an alert fires, RADAR sends its indicators (source IPs, usernames, the targeted host) to DECIPHER. DECIPHER assesses them against its threat intelligence sources, such as MISP, and returns a CTI score. RADAR folds that score into its risk calculation, so an attack from a known malicious source is escalated faster than one from an unknown address.

The integration continues after the decision. For every alert above the lowest risk tier, RADAR has DECIPHER open a structured case in Flowintel, with the full detection context attached. The email notification sent to analysts includes:

the risk breakdown;
the CTI score and labels;
the indicators of compromise;
a direct link to the Flowintel case.

Analysts get a prioritized, documented incident without any manual triage step.

Connecting the two systems takes a few settings in RADAR’s web control panel. If DECIPHER is unavailable, RADAR keeps detecting and responding, without the CTI enrichment and case creation, instead of failing.

A manager-centric RADAR (v2.0)

v2.0 moved RADAR’s intelligence to where it belongs, the Wazuh manager:

Login enrichment (geolocation, travel velocity, ASN novelty) and web access enrichment run on the manager. Endpoints no longer need a local enrichment service.
RADAR is deployed from the web control panel or the command line, and every step, including a scenario deployment, can be undone.
Agents enroll with short-lived tokens during time-limited enrollment windows.
A major redesign was implemented: Deploy, Infrastructure and Connectors pages were designed around the manager-centric workflow. The Infrastructure page manages the Wazuh nodes directly, and every deployment action, including a scenario deployment, can be undone.
Deployment, onboarding, health checks and attack simulations no longer depend on Ansible.

Security hardening (v2.1)

v2.1.0 strengthens every layer that an attacker could try to abuse:

The web control panel accepts only local connections by default, requires a login token and blocks cross-site requests.
Every deployment gets its own credentials, which are easy to rotate.
Anomaly alerts are accepted only from authenticated, trusted sources.
Automated responses act only on the attacker’s own address, and critical addresses and services are protected.
Configuration is treated strictly as data, and each component receives only the settings it needs.

The README’s new section, Security assumptions and recommendations, lists the firewall rules we recommend and the settings to review for your site.

Getting started and upgrading

New users can follow the getting-started guide in the repository: a single build deploys the Wazuh stack and the chosen RADAR scenarios, and the web control panel handles everything else.