Prendre rendez-vous

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

Comment mettre en œuvre de manière structurée l'obligation d'utiliser des systèmes de détection des attaques selon le § 31 BSIG – du guide d'orientation du BSI aux preuves à fournir, en passant par les sources de journaux et le detection engineering.

En Allemagne, les opérateurs d'installations critiques sont légalement tenus d'utiliser des systèmes de détection des attaques (Systeme zur Angriffserkennung, SzA) – une obligation régie, depuis la transposition de NIS2, par le § 31, alinéa 2, BSIG. Le BSI précise ce qui est considéré comme approprié dans son guide d'orientation (Orientierungshilfe), avec des exigences MUSS, SOLLTE et KANN (« doit », « devrait », « peut ») et un modèle de degrés de mise en œuvre de 0 à 5. Mais l'efficacité réelle de la détection des attaques ne se joue pas sur le papier : elle dépend de la couverture des sources de journaux, de la qualité des règles de détection et de processus de réaction réellement pratiqués. Cet article met en perspective le cadre juridique, les exigences du BSI et les briques techniques – des règles Sigma et du mapping ATT&CK au cycle de vie des cas d'usage.

L'essentiel en un coup d'œil

01

Obligation légale : § 31, alinéa 2, BSIG

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).

02

Guide d'orientation du BSI : MUSS, SOLLTE, KANN et degrés de mise en œuvre

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.

03

Sources de journaux et journalisation : la visibilité avant l'analytique

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.

04

Detection engineering : règles Sigma et mapping ATT&CK

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.

05

Briques technologiques : SIEM, EDR et NDR

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.

06

Cycle de vie des cas d'usage et lacunes fréquentes

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.

Normes & sources

Le contenu de cette page s'appuie sur les guides et études suivants, accessibles publiquement.

Bundesrepublik Deutschland / gesetze-im-internet.de · 2025

Gesetz über das Bundesamt für Sicherheit in der Informationstechnik und über die Sicherheit in der Informationstechnik von Einrichtungen (BSIG)

Nouvelle version issue de la loi de transposition de NIS2, en vigueur depuis le 06.12.2025 ; les dispositions déterminantes sont le § 2 (définition légale des SzA), le § 31, alinéa 2 (obligation d'utilisation pour les opérateurs d'installations critiques) et le § 39 (preuves tous les trois ans).

Bundesamt für Sicherheit in der Informationstechnik (BSI) · 2024

Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung, Version 1.1

Précise les exigences MUSS, SOLLTE et KANN relatives à la journalisation, à la détection et à la réaction et définit le modèle de degrés de mise en œuvre 0–5 pour la fourniture des preuves.

The MITRE Corporation · 2026

MITRE ATT&CK v19 (Updates – April 2026)

Version actuelle de la base de connaissances ; matrice Enterprise avec 15 tactiques, 222 techniques et 475 sous-techniques comme taxonomie de référence pour le mapping de couverture de la détection.

SigmaHQ · 2026

About Sigma – Sigma Detection Format

Documentation du format de signature ouvert basé sur YAML pour les événements de journaux, y compris la conversion dans les langages de requête SIEM via sigma-cli et pySigma.

SigmaHQ (GitHub) · 2026

SigmaHQ/sigma – Main Sigma Rule Repository

Dépôt de règles maintenu par la communauté, dont les règles de détection peuvent être traduites en requêtes SIEM spécifiques aux produits.

Rendre votre détection des attaques prête pour l'audit ?

Nous vous accompagnons dans l'analyse d'écarts par rapport au guide d'orientation du BSI, dans le detection engineering et dans la fourniture des preuves selon le § 39 BSIG. Contactez-nous pour un premier entretien sans engagement.