DORA et Netwrix Auditor : journaliser, détecter et produire la preuve

L'article 12 impose aux entités financières de définir les événements qui doivent être journalisés, leur durée de conservation et les mesures nécessaires à la protection des journaux. Le niveau de détail doit être adapté à la finalité du contrôle. DORA demande notamment de journaliser les événements relatifs au contrôle d'accès logique et physique, à la gestion des identités, au change management, aux opérations des systèmes TIC et aux activités de trafic réseau.

Netwrix Auditor peut contribuer à cette exigence sur ses sources prises en charge. Ses rapports de changements et d'activité couvrent notamment Active Directory, Microsoft Entra ID, les serveurs de fichiers, SharePoint, SQL Server, Windows Server, VMware et différents environnements Microsoft. Une catégorie spécifique permet également d'examiner l'activité de connexion.

Prenons le cas de Claire, utilisatrice légitime d'une application financière. Une politique IAM peut expliquer pourquoi elle possède un droit, mais un contrôle ou une investigation ultérieure peut nécessiter de savoir si elle s'est effectivement connectée, quel compte a effectué une modification, quelle permission a changé ou sur quelle ressource l'action s'est produite. Netwrix Auditor structure précisément ses données de recherche autour de champs tels que l'auteur de l'action, l'objet concerné, la ressource, la date et, pour certains environnements, le poste à l'origine du changement.

L'intérêt n'est donc pas d'accumuler des journaux pour démontrer qu'ils existent, mais de disposer d'informations permettant de reconstruire une activité lorsque le contrôle interne, la sécurité ou l'investigation en ont besoin.

L'article 23 demande aux entités financières de mettre en place un mécanisme capable de collecter, surveiller et analyser des informations, notamment les logs prévus à l'article 12, afin d'identifier des activités ou comportements anormaux. Pour les actifs soutenant des fonctions critiques ou importantes, le texte exige notamment des outils produisant des alertes sur les anomalies détectées.

Netwrix Auditor permet de définir des alertes sur des événements précis. Ses alertes peuvent être associées à un niveau de risque et participer au mécanisme Behavior Anomalies, qui rapproche certaines anomalies d'un utilisateur et permet ensuite d'examiner les activités correspondantes.

Pour Claire, un changement isolé peut être parfaitement normal, alors qu'une succession de modifications, suppressions ou autres événements inhabituels peut justifier une investigation. Auditor permet de faire émerger ce type de signal à partir des événements qu'il collecte et des règles configurées.

Il faut toutefois conserver une limite claire : Netwrix Auditor ne constitue pas à lui seul le mécanisme complet de détection demandé par DORA. L'article 23 prévoit également la prise en compte de menaces internes et externes, d'informations issues des métiers, de threat intelligence, de notifications de prestataires et d'autres sources. Un SIEM, un SOC, des solutions endpoint, réseau ou cloud peuvent donc rester nécessaires pour disposer de la couverture attendue.

Netwrix Auditor ne décide pas qui doit obtenir un droit et ne bloque pas, par principe, chaque action avant son exécution. Sa fonction principale dans cette architecture est d'apporter visibilité, investigation, alertes et éléments de preuve sur les changements et activités des systèmes qu'il surveille.

Sa contribution à DORA se concentre donc principalement sur l'article 12, en facilitant l'exploitation de certaines traces demandées par le règlement, et sur une partie de l'article 23, en permettant de détecter et investiguer certains comportements ou événements anormaux.

La portée exacte dépend des sources raccordées et des fonctions activées. Une architecture DORA complète doit donc commencer par identifier les événements réglementairement nécessaires, puis vérifier quelles sources sont effectivement couvertes par Auditor et lesquelles doivent être collectées ou analysées par d'autres composants, par exemple sur les chemins d'attaque Active Directory.