CSSF — Ivanti EPMM: RCE exploitée, notification DORA obligatoire
Le 10 février 2026, la CSSF alerte sur deux RCE Ivanti EPMM (CVE‑2026‑1281/1340) activement exploitées et rappelle l’obligation de notifier un incident majeur TIC (Circulaires 25/893 et 24/847).
Excerpt — Le 10 février 2026, la CSSF alerte sur deux failles Ivanti EPMM exploitées (CVE‑2026‑1281/1340) et rappelle qu’un tel accès non autorisé est un « incident majeur TIC » à notifier (Circulaires CSSF 25/893 et 24/847). Voici la MDM concrète qui évite l’escalade — et prouve la conformité.
Les faits
Le 10 février 2026, la CSSF publie un communiqué sur l’exploitation active de deux vulnérabilités critiques dans Ivanti Endpoint Manager Mobile (EPMM) — CVE‑2026‑1281 et CVE‑2026‑1340. Ces failles permettent une exécution de code à distance non authentifiée sur le serveur EPMM, pouvant conduire à la prise de contrôle des terminaux gérés, des mouvements latéraux et l’accès à des données sensibles. La CSSF précise que ce type d’« accès non autorisé malveillant » constitue un incident majeur lié aux TIC devant être notifié selon les Circulaires CSSF 25/893 (DORA) ou CSSF 24/847, selon l’entité concernée (CSSF).
La communauté sécurité a documenté des compromissions et une exploitation industrielle de ces zéros‑days; un acteur unique serait responsable d’une large part des attaques récentes, tandis qu'Ivanti a diffusé des correctifs temporaires puis des mises à jour durcies (BleepingComputer). Le CIRCL Luxembourg a publié un rapport pratique (indiqué par la CSSF) listant les actions immédiates de réduction de risque et d’incident response (CSSF → lien vers TR‑98 du CIRCL).
Le cadre légal qui s’applique
- DORA — Reporting des incidents majeurs TIC: la Circulaire CSSF 25/893 met en œuvre les obligations de notification des incidents majeurs et menaces cyber significatives pour les entités DORA; corrélativement, la Circulaire CSSF 24/847 encadre la major ICT-related incident notification pour d’autres entités surveillées. La CSSF rappelle expressément que l’exploitation RCE non authentifiée sur EPMM « constitutes a major ICT-related incident that needs to be notified » (CSSF — 24/847; communiqué CSSF 10/02/2026).
- NIS 2 (art. 21) — Mesures de gestion des risques cyber: inventaire et sécurisation des actifs, contrôle des accès, politiques de correctifs et surveillance des événements. Les endpoints mobiles gérés (BYOD/COPE) sont explicitement dans le périmètre des mesures techniques et organisationnelles.
- RGPD (art. 32) — Sécurité du traitement: chiffrement, confidentialité, intégrité, résilience et capacité à restaurer la disponibilité des données. Un MDM correctement configuré (chiffrement, effacement à distance, cloisonnement) est une mesure « appropriée » pour les données personnelles présentes sur les terminaux. Voir aussi notre éclairage sur la résilience opérationnelle et les obligations de notification.
La solution technique à déployer
Objectif: rendre un serveur MDM/EMM non exploitable comme point d’entrée, empêcher l’escalade en cas de compromission et constituer la preuve de conformité (DORA/NIS 2/RGPD) sans discours théorique.
- MDM/EMM durci et segmenté
- Isolation réseau du serveur EPMM (DMZ dédiée, reverse proxy, règle « deny by default », flux sortants restreints), journaux horodatés et envoyés en temps réel au SIEM.
- MFA résistante au phishing pour tous les accès d’administration (FIDO2/WebAuthn) et comptes de service sous least privilege.
- Gestion de configuration déclarative (IaC/Ansible) + périmètre minimal des modules/plug‑ins; mises à jour de sécurité hors bande et patch management sous SLA.
- Politiques MDM sur terminaux
- Chiffrement forcé disque et clés protégées (TPM/SE), verrouillage fort, containers professionnels (work profile) séparant données perso/pro.
- Compliance policies + conditional access: accès aux apps et données seulement si OS à jour, appareil non compromis, AV/EDR actif.
- Catalogue applicatif approuvé (allow‑listing), interdiction du sideloading, effacement sélectif à la sortie.
- Détection et réponse
- Intégration des logs EPMM (auth, politique, API, erreurs) et des télémétries mobiles au SIEM; règles de corrélation spécifiques RCE EPMM et IOCs CIRCL.
- Playbooks SOAR: isolement du serveur, blocage d’IP, révocation de tokens, réinitialisation des attestations d’appareils, remote wipe si conteneur compromis.
Référentiels: ISO/IEC 27001:2022 — A.5.9 Inventory of information and other assets, A.8.1 User endpoint devices, A.8.16 Monitoring activities; NIST CSF 2.0 — PR.AA (Gestion des identités/accès), PR.PS (Sécurité de plateforme), DE.CM (Surveillance continue); CIS Controls v8 — C1 (Inventaire des actifs), C4 (Configuration sécurisée), C6 (Gestion des accès), C15 (Fournisseurs).
Comment Luxgap déploie cela
- Notre SOC managé 24/7 raccorde EPMM et les télémétries mobiles au SIEM, implémente les use cases RCE EPMM (TTP, IOCs CIRCL) et orchestre les réponses (isolation, révocation, effacement sélectif) en moins de quelques minutes.
- Notre gouvernance ISO 27001 formalise la politique BYOD/COPE, le registre des actifs mobiles, les procédures de patching hors bande EMM, et les preuves auditables: journaux signés, revues de configuration, comptes à privilèges.
- Nos consultants DPO et CISO externalisés cadrent l’art. 32 RGPD (analyses de risque, politiques d’effacement, chiffrement), l’alignement NIS 2 art. 21 et le reporting DORA (classification, délais, contenu), au besoin avec table‑tops « incident EMM ».
Cas concret au Luxembourg ou en UE
Une profession financière soumise à DORA et NIS 2, utilisant EPMM on‑prem, a subi des tentatives d’exploitation en février 2026. En 6 semaines, nous avons:
- isolé EPMM derrière un proxy mutualisé, imposé MFA FIDO2 aux administrateurs et refondu les rôles (RBAC minimalistes);
- déployé des politiques MDM chiffrant 100 % des terminaux actifs, avec contrôle de conformité bloquant l’accès aux données en cas d’OS obsolète;
- branché logs EPMM et endpoints au SIEM, créé des corrélations RCE + watchlists d’IPs malveillantes;
- rédigé et testé le playbook DORA: classification « majeur », notification structurée (contexte, impact, mesures), suivi correctif. Résultat: aucune exfiltration constatée, notification CSSF en bonne et due forme dans les délais.
Premiers pas concrets
- Vérifier l’exposition d’EPMM: interdire tout accès direct Internet au serveur d’administration; imposer un proxy/IDP et MFA FIDO2.
- Appliquer les correctifs Ivanti et durcir: mettre à jour vers les versions corrigées, supprimer les modules non utilisés, cloisonner les flux, journaliser vers un SIEM.
- Activer des politiques MDM minimales: chiffrement, verrouillage fort, conteneur professionnel, effacement sélectif, interdiction du sideloading.
- Brancher les logs EPMM et mobiles au SOC/SIEM; importer les IOCs et règles d’alerte recommandées par le CIRCL.
- Préparer la notification (DORA/24‑847): gabarit de classification, points de contact, chronologie, et dry‑run de 30 minutes avec les équipes métiers/IT.
Sources officielles
- CSSF — Active exploitation of vulnerabilities on Ivanti EPMM (10/02/2026)
- CSSF — Circular CSSF 24/847: Major ICT-related incident notification
- CSSF — ICT and cyber risk (DORA entities) et rappel 25/893
- BleepingComputer — 83% des attaques Ivanti EPMM attribuées à un acteur (2026)
- CIRCL Luxembourg — Recommandations EPMM (TR‑98)
Une question sur ce sujet ?
Notre équipe répond généralement sous 24 h ouvrées. Configurez votre devis ou écrivez-nous.
Configurer mon devis →