Soutenir la conformité TIBER-EU
UserLock et FileAudit soutiennent les principaux objectifs du cadre de conformité TIBER-EU.
Le cadre TIBER-EU est un cadre européen de processus et de gouvernance qui vise à renforcer la cyber-résilience des entités fournissant des infrastructures financières essentielles à l'UE. Fondé sur une expertise et une expérience communes, le cadre a été conçu par la BCE et les banques centrales nationales de l'UE, et publié en mai 2018. Il a été mis à jour en 2024 afin d'assurer l'alignement avec les normes techniques réglementaires relatives aux tests de pénétration fondés sur la menace (TLPT) du règlement sur la résilience opérationnelle numérique (DORA).
En France, la Banque de France a publié un guide national d'implémentation TIBER-FR. L'objectif est de définir clairement des orientations sur la manière dont les autorités, les entités, les fournisseurs de renseignements sur les menaces et les testeurs de l'équipe rouge doivent collaborer pour tester et améliorer la cyber-résilience des entités en menant des cyberattaques contrôlées. Il ne s'agit pas d'une norme de contrôles de sécurité technique.
Le cadre TIBER-EU peut également aider les autorités compétentes et les entités financières à satisfaire aux exigences relatives aux tests de pénétration fondés sur la menace prévus par DORA. L'adoption du cadre TIBER-EU peut contribuer à remplir certaines exigences DORA.
Bien que conçu pour le secteur financier, le cadre TIBER-EU est utile à tous les secteurs critiques souhaitant renforcer leur résilience.
Dans le cadre de TIBER-EU, UserLock et FileAudit peuvent contribuer à renforcer les défenses soumises aux tests et à produire les preuves dont dépend l'exercice. Le rapport de l'équipe bleue et l'exercice de rejeu ne peuvent tout simplement pas avoir lieu sans des journaux d'audit de qualité.
La plupart des exigences obligatoires du cadre TIBER-EU portent sur les rôles, les livrables et la méthodologie de test, des domaines où un logiciel de sécurité informatique ne peut, bien évidemment, pas prétendre apporter de contribution.
Ce que nous cherchons à montrer ci-dessous se limite aux exigences pour lesquelles UserLock ou FileAudit apportent une contribution réelle :
Démontrer des défenses solides à des fins de test
Fournir des journaux d'audit détaillés pour produire les preuves dont dépend le test
Nous avons intentionnellement omis les exigences TIBER pour lesquelles les produits ne présentent aucune pertinence.
Contrôles d'accès pour protéger les systèmes que l'équipe rouge tentera de compromettre
Gestion des sessions et pistes d'audit des connexions utilisées par l'équipe bleue pour détecter les attaques
Journaux d'accès aux fichiers pour fournir des preuves destinées au rapport de test de l'équipe bleue
Alertes d'anomalies en temps réel qui testent les capacités de détection de l'organisation
Conservation des enregistrements d'audit pour le rejeu de la phase de clôture et les rapports
Application des restrictions d'accès pour valider les contrôles du principe du moindre privilège en conditions de test
Gouvernance : désignation du Control Team, du TCT ou du Test Manager
Processus : collecte de renseignements sur les menaces, création de scénarios ou rédaction du RTTP
Gestion des prestataires : approvisionnement, contrats ou certifications TIP/RTT
Reporting : production du RTTR, BTTR, TSR ou du plan de remédiation
Adoption du cadre : mise en œuvre nationale TIBER-XX ou liaison avec le TKC
Scénarios de red teaming physique ou d'ingénierie sociale
Exigence | Type | UserLock | FileAudit |
|---|---|---|---|
Phase de préparation : exigences côté entité | |||
L'entité effectue une évaluation des risques et met en place des contrôles de gestion des risques pour faciliter un test contrôlé et sécurisé sur des systèmes de production en production réelle. | Obligatoire | Fournit une visibilité en temps réel des sessions et des contrôles d'accès au niveau des comptes qui alimentent l'évaluation des risques ; les administrateurs peuvent définir et appliquer des restrictions avant la fenêtre de test. L'équipe informatique peut appliquer des contrôles d'accès, une authentification multifacteur (MFA) et des politiques de session aux utilisateurs, groupes et unités organisationnelles (UO) Active Directory. | Les rapports de permissions sur les fichiers aident l'équipe à identifier les accès trop permissifs aux référentiels de données supportant les FIC avant le début du test, réduisant ainsi la surface d'attaque avant les tests. |
Le périmètre du test inclut les personnes, les processus et la technologie supportant les Fonctions Critiques ou Importantes (FCI). Le test est réalisé sur des systèmes de production en production réelle. | Obligatoire | Le déploiement par agent de UserLock est pleinement opérationnel dans les environnements de production Windows en production réelle (ou dans des environnements de test) et maintient les politiques dans des scénarios hors ligne ou air-gappés. | FileAudit surveille en temps réel les fichiers Windows en production, les serveurs de fichiers et le stockage cloud contenant des données supportant les CJI/FCI (les mêmes systèmes que ceux ciblés par l'équipe rouge durant le test). |
Seul le Control Team est informé du test. Tous les autres membres du personnel — l'équipe bleue — restent dans l'ignorance et s'acquittent normalement de leurs tâches tout au long des tests. | Obligatoire | La surveillance des connexions et les alertes d'anomalies fonctionnent en continu sans nécessiter que l'équipe bleue en soit informée. Les capacités de détection normales de l'équipe bleue sont préservées sans modification. | La surveillance des accès aux fichiers et les alertes d'événements se poursuivent normalement sans nécessiter de modifications de configuration de la part de l'équipe bleue, garantissant un comportement de détection authentique et non influencé pendant les tests. |
Phase de test : ce que rencontrera l'équipe rouge | |||
Le RTT exécute des scénarios d'attaque ciblant les personnes, les processus et la technologie supportant les FCI, en testant les capacités de protection, de détection et de réponse de l'entité. | Obligatoire | La MFA de UserLock, les limites de sessions simultanées et les contrôles d'accès contextuels font partie des défenses actives auxquelles l'équipe rouge doit faire face, testant directement la posture de sécurité de l'organisation. | La surveillance des accès aux fichiers en temps réel signifie que tout accès de l'équipe rouge aux référentiels de données supportant les FCI est capturé et peut déclencher des alertes pour l'équipe bleue, testant directement la capacité de détection. |
Pendant les tests actifs, le RTT procède phase par phase. Toutes les actions sont journalisées pour l'exercice de rejeu, comme preuves pour le RTTR, et pour référence future. | Obligatoire | Chaque événement de connexion, session, tentative échouée et utilisation de privilège est journalisé avec horodatage, identité, poste de travail et résultat, fournissant la piste d'audit côté entité nécessaire pour démontrer les actions du RTT. | Tous les événements d'accès aux fichiers sont journalisés avec leur contexte complet : utilisateur, chemin, opération et horodatage. Cela constitue les preuves dont l'équipe bleue a besoin pour reconstituer les déplacements de l'équipe rouge dans les référentiels de données. |
La durée minimale des tests actifs est de 12 semaines. Le RTT vise à atteindre tous les jalons définis pour les systèmes supportant les FCI, à travers toutes les phases d'attaque (entrée, traversée, sortie). | Obligatoire | Les contrôles d'accès basés sur les sessions et la surveillance aident à résister activement aux mouvements latéraux de l'équipe rouge pendant toute la fenêtre de 12 semaines. L'équipe bleue peut bloquer en continu des comptes et forcer la déconnexion de sessions présentant une activité suspecte, détecter des sessions simultanées et limiter les accès selon des facteurs tels que l'heure, l'adresse IP et le dispositif. | La surveillance continue des activités sur les fichiers pendant toute la durée des tests garantit que les accès de l'équipe rouge aux jalons de données sont capturés à tout moment durant la fenêtre de 12 semaines, et pas uniquement lors des sessions de surveillance avec présence humaine. |
Le red teaming physique (par exemple, l'installation d'un dispositif sur site) est autorisé dans le périmètre, sous réserve que toutes les précautions nécessaires soient prises et qu'aucune limite légale ne soit franchie. | Optionnel | Si un attaquant physique obtient un accès local, le verrouillage des dispositifs de UserLock (après n minutes d'inactivité), la détection de sessions simultanées et les restrictions d'accès basées sur le poste de travail restent actifs en tant que contrôles. | Les accès aux fichiers depuis un dispositif physiquement installé sont capturés dans le journal d'audit, fournissant des preuves des tentatives d'accès aux données via ce vecteur d'intrusion physique pour l'équipe bleue et l'exercice de rejeu. |
Phase de clôture : reporting, rejeu et remédiation | |||
L'équipe bleue est informée du test et produit un rapport de test de l'équipe bleue (BTTR), en mettant en correspondance ses actions avec celles du RTT à l'aide d'une chronologie des détections. | Obligatoire | Le journal d'audit de UserLock fournit une chronologie complète et inviolable de tous les événements de connexion pendant la période de test. Il constitue la source principale utilisée par l'équipe bleue pour corréler l'activité détectée avec les actions du RTT. | Le journal d'événements de FileAudit portant sur tous les accès aux fichiers durant la période de test donne à l'équipe bleue des preuves concrètes et horodatées des données auxquelles l'équipe rouge a accédé, quand, depuis quel emplacement et depuis quel compte utilisateur. |
Lors de l'exercice de Purple Teaming, l'équipe bleue et l'équipe rouge travaillent ensemble pour identifier des étapes d'attaque alternatives et la manière dont l'équipe bleue aurait pu y répondre. | Obligatoire | Les données d'audit des sessions et des connexions permettent d'analyser la façon dont des chemins d'attaque alternatifs (par exemple, le credential stuffing, les mouvements latéraux) auraient été visibles dans les journaux, et si les seuils d'alerte existants les auraient détectés. | L'historique des accès aux fichiers permet d'explorer des chemins alternatifs d'exfiltration de données et d'évaluer si les règles de surveillance des fichiers de l'équipe bleue auraient déclenché des alertes selon différentes approches du RTT. |
Après les exercices de rejeu et de Purple Teaming, l'entité produit un plan de remédiation pour traiter les vulnérabilités et causes profondes identifiées lors des tests. | Obligatoire | Lorsque des lacunes dans les contrôles d'accès ou la gestion des sessions sont identifiées durant les tests, UserLock fournit les contrôles de remédiation spécifiques pour les combler : déploiement de la MFA, limites de durée de session, restrictions par poste de travail. | Lorsque les contrôles d'accès aux fichiers s'avèrent insuffisants, l'analyse des permissions et les rapports sur les droits d'accès de FileAudit permettent une remédiation ciblée, en renforçant les accès aux référentiels de données supportant les FCI. |
Les enregistrements d'audit issus du test doivent être protégés, conservés et traités avec des contrôles de confidentialité appropriés, compte tenu de la sensibilité des résultats du test. | Obligatoire | Les enregistrements d'audit sont stockés dans un référentiel centralisé et inviolable, distinct du journal des événements de sécurité Windows. Seuls les administrateurs UserLock disposant des autorisations appropriées ont accès aux journaux, conservés selon des politiques configurables alignées sur le cycle de vie du test. | Les données d'audit des fichiers sont stockées indépendamment des systèmes audités, avec des permissions limitant les personnes pouvant consulter les enregistrements de la période de test, protégeant ainsi la confidentialité des résultats tout au long de la phase de clôture. |
Transversal : contrôles continus côté entité | |||
L'entité doit être en mesure d'évaluer ses capacités de protection, de détection et de réponse — les trois dimensions spécifiquement évaluées par un test TIBER-EU. | Obligatoire | UserLock soutient directement les trois piliers évalués par les tests TIBER : protection (MFA, contrôles d'accès), détection (surveillance des sessions, alertes en temps réel, journaux d'audit) et réponse (blocage de compte en un clic, déconnexion forcée). | FileAudit contribue à la détection (alertes en temps réel sur les accès anormaux aux fichiers, identification des actions par compte utilisateur) et les journaux d'audit fournissent des preuves forensiques pour soutenir la réponse et la revue post-incident. |
L'accès à la documentation et aux résultats du test doit être limité au strict besoin d'en connaître tout au long du test. Des noms de code doivent être utilisés dans toutes les communications et documents. | Obligatoire | Les administrateurs UserLock peuvent restreindre l'accès à UserLock et décider qui peut consulter certains rapports. Cela garantit que seuls les membres du Control Team peuvent accéder aux données de connexion de la période de test sans les exposer au personnel de l'équipe bleue. | L'accès aux rapports FileAudit peut être limité à des administrateurs FileAudit nommément désignés, garantissant que les enregistrements d'accès aux fichiers de la période de test ne sont pas visibles par les membres de l'équipe bleue devant rester dans l'ignorance du test. |
Les tests TIBER-EU sont réalisés sur des systèmes de production en production réelle. Les entités doivent disposer de capacités de sauvegarde et de restauration, et veiller à ce que les tests minimisent les risques pour la continuité des FCI. | Obligatoire | Les contrôles de blocage de compte et de déconnexion sont configurés avec des seuils adaptés à la production — empêchant que l'activité de l'équipe rouge ne déclenche par inadvertance des verrouillages massifs susceptibles de perturber les opérations des FCI. | La surveillance des fichiers est en lecture seule et non intrusive. Elle ne modifie pas, ne bloque pas et n'interrompt pas les opérations sur les fichiers des systèmes supportant les FCI, préservant ainsi leur continuité tout au long de la période de test. |