Le piège classique
L'article 4 du RTS TLPT est un piège de gouvernance, pas de technique. La CSSF, en tant qu'autorité TIFM au sens de l'article 26 de DORA, sanctionne les entités qui lancent un test fonde sur la menacé sans avoir formalise l'équipe chargée du contrôle (control team) ni désigné nommement son chef. En pratique, ce qui tombe c'est le defaut de secret : un TIFM connu de trop de personnes n'est plus un test réaliste, et la BCL comme la CSSF, dans le cadre TIBER-LU (Implementation Document revise le 20 juin 2025), considèrent qu'une fuite du périmètre ou du nom de code invalide le test et impose de le rejouer. Le second piège classique est l'absence de procédure de containment : quand la blue team détecte le red team et déclenche une réponse a incident reelle, personne n'est habilite a bloquer la remontée.
Les mesures organisationnelles que la CSSF vous demandera de prouver
- Un chef d'équipe de contrôle désigné nommement, responsable de la gestion journaliere du TIFM et de toutes les décisions de l'équipe (art. 4.1).
- Un accès au périmètre strictement limite au need-to-know : équipe de contrôle, organe de direction, testeurs, fournisseur de renseignements sur les menacés et autorité TIFM uniquement (art. 4.2.a).
- Une consultation documentée des test managers TIBER-LU avant d'impliquer tout membre de la blue team (art. 4.2.b).
- Une procédure de containment : l'équipe de contrôle est informée de toute détection et peut bloquer la remontée de la réponse a incident (art. 4.2.c).
- Des engagements de confidentialité signes par le personnel interne, les prestataires tiers TIC concernes (circulaires CSSF 22/806 et 25/882), les testeurs et le fournisseur de threat intelligence (art. 4.2.d).
- L'usage systématique du nom de code dans toute communication liée au test (art. 4.2.f).
La difficulte n'est pas de rédiger ces règles, mais de prouver qu'elles ont ete respectées en continu pendant les semaines du test, alors que les prestataires TIC sont dans le périmètre et que les accords de sous-traitance (RTS 2025/532) doivent deja prévoir la participation aux tests.
Comment Luxgap automatise ce risque
Notre Luxgap TLPT Secrecy Warden rend impossible la fuite silencieuse du périmètre en transformant les obligations de secret de l'article 4 en journal de preuve horodate, opposable a la CSSF et a la BCL. L'outil s'integre a votre Active Directory, Microsoft Defender, Azure Sentinel et a votre outil ITSM pour cartographier en temps reel qui detient une information sur le TIFM, et alerte la control team des qu'un accès sort du cercle need-to-know valide.
- Génère et fait signer electroniquement les engagements de confidentialité du personnel interne, des prestataires tiers TIC (circulaires 22/806 et 25/882), des testeurs et du fournisseur de threat intelligence, avec traceabilite complète.
- Détecte en temps reel via Defender et Sentinel toute réponse a incident declenchée par la blue team sur le périmètre du test, et notifie instantanement le chef de la control team pour decider du containment (art. 4.2.c).
- Verrouille le registre des personnes habilitées et alerte sur Teams des qu'un compte hors need-to-know accede a une ressource liée au test.
- Substitue automatiquement le nom de code au nom reel du projet dans les tickets ITSM et journalise toute mention du vrai nom comme incident de secret (art. 4.2.f).
- Trace chaque consultation des test managers TIBER-LU avant implication d'un membre de la blue team, avec horodatage opposable (art. 4.2.b).
- Produit un rapport PDF scelle cryptographiquement demontrant le respect continu de l'article 4, integrable au dossier de cloture TIFM remis a la CSSF et alimentant la gestion des risques TIC (circulaire 20/750).
Disponible en complement d'un mandat CISO Luxgap ou en brique SaaS dediée selon votre périmètre. Demandez un devis personnalise et nos équipes preparent une demonstration sur votre périmètre reel, avec un audit blanc gratuit sous 48h pour mesurer votre exposition avant tout engagement.
