Systèmes de détection des attaques (SzA)

L'obligation d'utiliser des systèmes de détection des attaques a été introduite par la loi allemande IT-Sicherheitsgesetz 2.0 et s'appliquait aux opérateurs KRITIS à partir du 1er mai 2023 (§ 8a, alinéa 1a, BSIG, ancienne version). Avec la loi de transposition de NIS2 (NIS2-Umsetzungsgesetz), en vigueur depuis le 6 décembre 2025, elle figure désormais au § 31, alinéa 2, BSIG : les opérateurs d'installations critiques doivent utiliser des systèmes qui « collectent et analysent en continu et automatiquement des paramètres et caractéristiques appropriés issus de l'exploitation courante » – dans le respect de l'état de l'art. Le § 2 BSIG définit les SzA comme des processus soutenus par des outils techniques et une intégration organisationnelle, donc expressément pas comme un simple produit, mais comme l'interaction de la technique et de l'organisation. Conformément au § 39 BSIG, la mise en œuvre doit être démontrée par des audits de sécurité, des contrôles ou des certifications – tous les trois ans dans le nouveau droit (auparavant tous les deux ans selon le § 8a, alinéa 3, BSIG, ancienne version).

La référence pour la mise en œuvre et les contrôles est le guide d'orientation du BSI « Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung » (version 1.1 du 18.11.2024, révisée sur le plan rédactionnel par rapport à la première édition de septembre 2022 ; il se réfère encore à l'ancien cadre juridique). Le guide structure les exigences en trois domaines – journalisation, détection et réaction – et les formule, sur le modèle de l'IT-Grundschutz, comme exigences MUSS, SOLLTE et KANN (« doit », « devrait », « peut ») ; pour aller plus loin, il renvoie notamment aux modules OPS.1.1.5, DER.1 et DER.2.1. L'évaluation repose sur un modèle de degrés de mise en œuvre de 0 à 5 : le degré 3 signifie que toutes les exigences MUSS sont remplies dans tous les domaines ; le degré 4 exige en plus toutes les exigences SOLLTE (exceptions uniquement avec justification solide), le degré 5 inclut les exigences KANN. Pour la preuve, il convient en principe d'atteindre au moins le degré de mise en œuvre 3 ; les écarts vers le bas ne sont admissibles que sur justification.

Une détection efficace commence par la question des données de journalisation effectivement collectées. Le guide d'orientation exige d'identifier tous les systèmes déterminants pour le service critique, de stocker de manière centralisée les données de journaux et de journalisation nécessaires et de les mettre à disposition pour l'analyse sous forme filtrée, normalisée, agrégée et corrélée. L'intégration des sources doit être priorisée de l'extérieur vers l'intérieur – des frontières du réseau vers les zones internes du réseau et, au niveau des systèmes, en partant des systèmes critiques centraux comme les systèmes de conduite de processus et d'automatisation. Le périmètre couvre expressément l'IT et l'OT, de même que les centres de données et les systèmes embarqués. Il faut en outre respecter la protection des données et les délais légaux de suppression, et mettre en place un processus de gestion des changements qui adapte la journalisation lorsque le périmètre évolue.

Les contenus de détection sont de plus en plus développés comme du logiciel : versionnés, testés et réutilisables. Sigma s'est imposé comme format de signature ouvert basé sur YAML pour les événements de journaux ; les règles peuvent être converties dans les langages de requête des plateformes SIEM courantes via sigma-cli et pySigma et échangées via le dépôt SigmaHQ maintenu par la communauté. Pour planifier la couverture, le guide d'orientation du BSI recommande une méthode standardisée comme MITRE ATT&CK ou ATT&CK for ICS. Dans sa version 19 (avril 2026), la matrice Enterprise décrit 15 tactiques, 222 techniques et 475 sous-techniques ; un mapping de ses propres règles sur ATT&CK rend transparent quelles techniques d'attaque sont détectées – et où subsistent des lacunes.

Dans la pratique, la détection des attaques naît de l'interaction de plusieurs briques. Un SIEM collecte et corrèle de manière centralisée les données de journaux issues de sources hétérogènes et assure l'analyse continue et automatisée exigée, avec alerte en cas de dépassement de seuils. L'EDR fournit une télémétrie détaillée et des capacités de réaction sur les postes de travail et les serveurs ; le NDR détecte les anomalies dans le trafic réseau et couvre ainsi aussi les zones où aucun agent ne peut être installé – par exemple les environnements OT ou les systèmes embarqués. Le guide d'orientation exige en outre concrètement une détection de codes malveillants gérée de manière centralisée ainsi que des systèmes de détection d'intrusion réseau (NIDS) aux points de transition entre réseaux internes et externes. Aucun outil ne satisfait à lui seul aux exigences ; ce qui est déterminant, c'est la couverture documentée de l'ensemble du périmètre.

Les cas d'usage de détection ne sont pas un projet ponctuel, mais un portefeuille avec un cycle de vie : analyse des menaces et priorisation, développement des règles, test et calibrage en fonctionnement normal (baselining), exploitation productive avec tuning, ainsi que revue régulière et mise hors service. Le guide d'orientation exige expressément de réajuster les mécanismes de détection sur la base de la qualification des événements pertinents pour la sécurité et de maintenir les signatures constamment à jour. Les lacunes typiques constatées lors des contrôles et des projets sont une couverture incomplète des sources de journaux, en particulier dans les réseaux OT, des processus de réaction absents ou non exercés, l'absence de règle solide pour l'analyse en dehors des heures ouvrées, la fatigue d'alerte due à des règles non calibrées, ainsi que l'absence de documentation de la planification et des exceptions justifiées – ce dernier point apparaît au plus tard lors de l'évaluation du degré de mise en œuvre.