Bâtir une pile de cybersécurité de défense, Partie 2 : SIEM/SOAR pour les enclaves classifiées

La Partie 1 a construit la fondation du renseignement. La Partie 2 implémente la couche opérationnelle qui consomme ce renseignement : le SIEM agrège et corrèle la télémétrie, le SOAR automatise la réponse, les deux câblés dans la topologie réseau d'enclaves classifiées qui définit la cybersécurité de défense. Des produits SIEM et SOAR commerciaux existent ; les industrialiser pour un déploiement défense est l'endroit où la plupart des programmes sous-estiment le travail. La Partie 2 décrit à quoi ce travail ressemble réellement.

Le cadrage au niveau pilier figure dans Le guide complet de la cybersécurité de défense ; les détails d'ingénierie SIEM/SOAR plus approfondis dans SIEM et SOAR pour l'intégration militaire.

Étape 1 : architecture de déploiement par enclave

La décision architecturale la plus lourde de conséquences : ne pas faire tourner une seule instance SIEM sur plusieurs niveaux de classification. Chaque enclave classifiée fait tourner sa propre pile SIEM/SOAR avec son propre magasin de données, son propre contenu de détection, son propre journal d'audit. Les piles sont physiquement séparées ; les mouvements de données entre elles passent par des solutions inter-domaines accréditées, jamais par une infrastructure partagée.

Le raisonnement est structurel : les données du SIEM sont un sur-ensemble de classification des sources qu'il ingère. Un SIEM agrégeant des journaux réseau SECRET détient du contenu classifié SECRET ; fusionner ce magasin avec des journaux administratifs NON CLASSIFIÉS élèverait par inadvertance la classification du magasin administratif via l'effet d'agrégation du SIEM. L'isolement par enclave empêche cela.

Le motif de déploiement pour l'exemple courant :

• SIEM NON CLASSIFIÉ — réseaux administratifs, actifs exposés à internet, gestion des fournisseurs. Un SaaS fourni par un éditeur peut être acceptable ici.
• SIEM NATO RESTRICTED — réseaux de mission de coalition, infrastructure attachée à FMN. Auto-hébergé sur infrastructure accréditée ; le SaaS éditeur est rarement acceptable.
• SIEM NATO SECRET — réseaux opérationnels classifiés. Auto-hébergé ; air-gapped d'internet ; mises à jour par canaux contrôlés.
• SIEM classifié national — systèmes nationaux à classification supérieure. Éditeurs uniques disposant d'une accréditation nationale ; déploiement sur mesure.

Le partage de renseignement inter-enclaves s'écoule via la propagation CTI (mécanisme de la Partie 1) et via des rapports de synthèse contrôlés — pas via des tableaux de bord SIEM partagés.

Étape 2 : le pipeline d'agrégation des journaux

Le SIEM est, structurellement, un pipeline de journaux avec une détection superposée. Faire le pipeline correctement rend la détection traitable ; le faire mal et le coût du pipeline domine tout le reste.

Les étapes du pipeline :

Collecte. Agents sur les endpoints (Sysmon sur Windows, auditd sur Linux, agents EDR fournisseurs), capteurs réseau (produits NDR, sondes IDS, collecteurs NetFlow), journaux applicatifs (format propriétaire et Syslog), journaux de plan de contrôle cloud (lorsque le cloud est dans le périmètre), télémétrie OT (Partie 3 de cette série).

Normalisation. Formats sources hétérogènes normalisés vers un schéma commun. Elastic Common Schema (ECS), l'OCSF, schémas spécifiques éditeurs — en choisir un et s'y aligner. Les inadéquations de schéma en production sont une source récurrente de détections manquées.

Enrichissement. Ajouter au journal brut le contexte qui lui manque : classification d'actif issue de l'inventaire (Partie 1), tags CTI du pipeline de renseignement, contexte d'attributs utilisateur depuis les systèmes d'identité, géolocalisation, association d'acteur de menace.

Routage. Les événements s'écoulent vers le palier chaud du SIEM pour la corrélation en direct, vers le stockage froid à long terme pour la rétention forensique, et sélectivement vers le SOAR pour le déclenchement des playbooks. Les règles de routage sont une politique explicite.

Rétention. La cybersécurité de défense impose des exigences de rétention longues — les campagnes étatiques séjournent pendant des mois ou des années. Le pipeline prend en charge une rétention en paliers : chaud (corrélation en direct), tiède (requêtes forensiques récentes), froid (archivage à long terme). Les budgets de rétention sont des décisions programme ; un sous-budget force une suppression prématurée des données.

Étape 3 : le contenu de détection en tant que code

Les règles de détection sur étagère d'un SIEM attrapent les menaces de commodité. La détection de niveau défense attrape les menaces étatiques. L'écart, c'est le contenu de détection : des règles adaptées à l'inventaire des actifs, au modèle de menace et au pipeline CTI.

La discipline du contenu-de-détection-en-tant-que-code :

Sigma rules comme format source. Sigma est le format neutre d'éditeur pour les règles de détection ; les règles écrites en Sigma se convertissent vers Splunk, Elastic, Sentinel, QRadar et d'autres. Écrire en Sigma garde la détection portable ; le tuning spécifique éditeur a lieu au déploiement.

Règles par actif et par acteur de menace. Une détection générique « commande PowerShell encodée » attrape du bruit. « Commande PowerShell encodée sur un hôte NATO SECRET depuis un utilisateur hors de l'OU ingénierie » est un signal. L'inventaire des actifs et le modèle de menace informent la spécificité de la règle.

Tests CI contre des données d'événement capturées. Les règles de détection sont testées unitairement en CI. Des traces d'événements capturées lors d'incidents passés et d'exercices red-team servent de vérité terrain. Un changement de règle qui ne détecte plus l'incident capturé est une régression qui bloque le merge.

Cartographie MITRE ATT&CK. Chaque règle se mappe à une ou plusieurs techniques ATT&CK. La cartographie permet l'analyse de couverture (quelles techniques sont bien couvertes, lesquelles sont des angles morts) et un reporting de niveau achat sur la posture défensive de la plateforme.

Gestion des faux positifs. Les règles produisent des alertes. Les alertes produisent de la charge SOC. La discipline du tuning FP — mesurer le taux de FP par règle, raffiner les règles pour réduire le bruit, retirer les règles qui ne peuvent être tunées — est structurelle. Les SOC qui se noient dans les FP manquent les TP.

Étape 4 : ingénierie des playbooks SOAR

Le SOAR (Security Orchestration, Automation, and Response) automatise la réponse aux événements détectés. Un playbook est un workflow versionné, testé, revu, que le SOAR exécute à l'alerte.

La discipline des playbooks :

Versionnés dans le contrôle de source. Les playbooks sont du code — YAML, JSON, DSL spécifiques éditeurs. Ils vivent dans le dépôt aux côtés des règles de détection, sont revus avant déploiement, et se déploient via le même processus de contrôle de changement que le code applicatif.

Testés en CI. Des traces d'incidents capturées servent d'entrées de test. Un playbook qui ne s'exécute plus correctement face à la trace capturée bloque le merge.

Portes de confirmation humaine pour les actions à conséquences. Le SOAR peut isoler un hôte, désactiver un compte utilisateur, bloquer une plage réseau, terminer un processus. Chacune de ces actions a des conséquences opérationnelles. Le playbook expose l'action proposée et exige une confirmation humaine explicite ; la décision de l'humain est journalisée.

Piste d'audit pour chaque action automatisée. Même les actions qui s'achèvent sans revue humaine (enrichissement d'alerte, création de ticket, recherche de threat intelligence) sont journalisées. La piste d'audit est la base de preuves pour la revue après action.

Chemins de rollback. Une action SOAR qui s'est trompée — mauvais hôte isolé, mauvais utilisateur désactivé — doit être réversible. L'ingénierie des playbooks tient compte de cela dès le départ ; rétro-équiper l'inversion est un travail sur mesure par action.

Étape 5 : intégration inter-CERT

La cybersécurité de défense existe dans une communauté. CERT nationaux (CISA, BSI, ANSSI, CCN-CERT), CSIRT militaires (US-CERT, NCSC, JCDC), CSIRT de coalition (NCIRC de l'OTAN), CSIRT partenaires. La plateforme s'intègre à cette communauté de manière bidirectionnelle.

Les motifs d'intégration :

Consommation entrante de renseignement. Les avis des CERT s'écoulent dans le pipeline CTI (Partie 1) et déclenchent des mises à jour des règles de détection. Les avis sensibles au temps (exploitation active de vulnérabilité, attribution de campagne en cours) reçoivent un traitement prioritaire.

Reporting sortant d'incidents. Les incidents confirmés — en particulier ceux impliquant des TTP étatiques ou des indicateurs pertinents pour la coalition — s'écoulent vers le CERT approprié via STIX/TAXII ou des canaux formels de rapport d'incident. Le reporting respecte la classification : les incidents NATO SECRET vont au NCIRC, pas à un éditeur commercial.

Chasse conjointe. Collaborations périodiques de threat hunting avec des CERT partenaires — lancer des requêtes dans plusieurs environnements nationaux, chercher des TTP adverses qui ne ressortent qu'en agrégat. La chasse conjointe est opérationnellement précieuse et politiquement complexe ; la piste d'audit de la plateforme soutient la revue juridique et politique.

Participation aux exercices. Locked Shields, Cyber Coalition, Crossed Swords — exercices cyber de l'OTAN et partenaires qui testent la coordination inter-CERT. La participation est une preuve de capacité de niveau achat.

Étape 6 : objectifs de performance et d'échelle

Les objectifs SIEM/SOAR qui distinguent les plateformes opérationnelles des prototypes :

• Ingestion de journaux soutenue au débit opérationnel (typiquement 50 000 à 500 000 événements/seconde pour un déploiement défense national), avec gestion de surcharge à 5× la ligne de base.
• Latence de détection inférieure à 60 secondes entre l'arrivée de l'événement et la génération de l'alerte pour les règles sensibles au temps ; inférieure à 5 minutes pour les règles à forte corrélation.
• Latence d'exécution des playbooks inférieure à 30 secondes pour le passage de relais à la revue humaine ; achèvement complet du playbook en quelques minutes pour les chemins automatisés.
• Rétention du stockage mesurée en années pour les environnements à classification élevée ; en paliers pour gérer le coût.
• Performance des requêtes inférieure à 30 secondes pour les requêtes analyste typiques sur données chaudes ; inférieure à 5 minutes pour les requêtes sur données froides.
• Disponibilité à 99,9 %+ pour les composants du palier chaud ; opération dégradée acceptable lors de défaillances du palier froid.

Manquer ces objectifs résulte habituellement de raccourcis architecturaux (ingestion sous-dimensionnée, index mal routés, motifs de requêtes naïfs). Les programmes qui prototypent explicitement contre ces objectifs attrapent les raccourcis avant le déploiement opérationnel.

Étape 7 : sélection éditeur pour un déploiement défense

La liste des éditeurs SIEM/SOAR déployables en défense est plus courte que la liste commerciale. Les critères :

Historique d'accréditation. Les éditeurs disposant d'une accréditation antérieure dans des réseaux classifiés OTAN ou d'États membres ont des preuves que les évaluateurs d'accréditation trouvent crédibles. Un démarrage à froid avec un éditeur non accrédité ajoute 12 à 24 mois au déploiement.

Déployabilité en air-gapped. Le déploiement de l'éditeur doit fonctionner dans des environnements sans sortie internet pour les mises à jour, les flux de threat intel ou la télémétrie. Les produits cloud-only sont exclus pour les classifications supérieures.

Positionnement ITAR-free pour les programmes européens. Voir Logiciels de défense ITAR-free pour les critères. Les déploiements européens préfèrent de plus en plus les éditeurs ITAR-free.

Portabilité du contenu de détection. Le support de Sigma (ou format neutre comparable) garde le contenu de détection de la plateforme portable à travers les transitions d'éditeurs. Le verrouillage éditeur sur le contenu de détection est un risque stratégique.

API ouvertes. Le SIEM/SOAR s'intègre à tout le reste de la pile cyber — plateforme CTI, EDR, capteurs réseau, systèmes d'identité, ticketing. Les API ouvertes ne sont pas négociables.

Les critères détaillés de sélection éditeur pour les logiciels de défense au sens large se trouvent dans Comment choisir un éditeur de logiciels de défense.

Et ensuite

La Partie 2 a construit la couche opérationnelle. Architecture SIEM/SOAR par enclave, pipeline d'agrégation des journaux, contenu de détection en tant que code, discipline des playbooks SOAR, intégration inter-CERT, objectifs de performance, sélection éditeur. La pile détecte et répond désormais à l'échelle à l'intérieur de l'architecture d'enclaves classifiées.

La Partie 3 couvre les couches spécialisées : défense ICS/OT pour la technologie opérationnelle que l'outillage de niveau IT ne traite pas, disponibilité forensique numérique pour l'analyse post-compromission, et les solutions inter-domaines qui déplacent les données appropriées entre enclaves tout en empêchant les flux inappropriés.