Politique Logging & Monitoring ISO 27001 : Word [A.8.15-16]

La politique de logging et monitoring ISO 27001 est un pilier fondamental de la détection des incidents de sécurité et de la traçabilité des actions dans le Système de Management de la Sécurité de l'Information. Elle répond aux exigences des contrôles A.8.15 — Journalisation et A.8.16 — Surveillance des activités de l'Annexe A ISO/IEC 27001:2022, qui imposent respectivement que les journaux enregistrant les activités des utilisateurs, les exceptions, les défaillances et les événements de sécurité soient produits, protégés et conservés pendant la durée appropriée, et que les réseaux, les systèmes et les applications soient surveillés pour détecter les comportements anormaux et les événements pouvant indiquer des compromissions. Dans le contexte de la cybersécurité moderne, le logging et le monitoring ne sont plus des activités optionnelles réservées aux grandes organisations : les PME sont tout autant ciblées par des acteurs malveillants sophistiqués, et sans visibilité sur les événements de leurs systèmes, elles sont incapables de détecter une compromission avant que les dommages ne soient irréversibles. Ce template Word, développé par Ayi NEDJIMI, consultant cybersécurité Lead Implementer ISO 27001, définit les événements à journaliser pour chaque type d'actif (serveurs Windows/Linux, équipements réseau, applications web, Active Directory, services cloud), les durées de rétention conformes aux exigences légales et aux bonnes pratiques (12 mois minimum pour les logs de sécurité), les cas d'usage SIEM/SOC (use cases de détection couvrant les attaques les plus fréquentes), les procédures de protection des logs contre la modification ou la suppression, et les KPI de surveillance à communiquer en revue de direction. Il s'adresse aux RSSI qui définissent la stratégie de visibilité sécurité, aux équipes SOC et IT qui opèrent les outils de logging et monitoring, aux auditeurs internes qui vérifient la conformité des pratiques de journalisation, et aux DSI qui dimensionnent les infrastructures de logging. La politique de logging est étroitement liée à la politique de sécurité réseau (A.8.20) pour la collecte des logs réseau, et à la procédure de gestion des incidents pour la réponse aux alertes générées par le monitoring.

Contexte réglementaire et normatif

Le contrôle A.8.15 d'ISO/IEC 27001:2022 exige que les journaux d'événements soient produits pour les activités des utilisateurs, les exceptions et les événements de sécurité de l'information, conservés et protégés contre toute falsification, et analysés régulièrement. Le contrôle A.8.16 exige que les réseaux et les systèmes soient surveillés activement pour identifier les comportements anormaux.

Plusieurs référentiels imposent des exigences de logging spécifiques :

• RGPD (Article 30 et 32) : les journaux d'accès aux données personnelles doivent être conservés pour démontrer la conformité. La durée de conservation des logs doit être définie en tenant compte des droits des personnes (pas de conservation excessive).
• Directive NIS 2 (Article 21.2) : impose la détection des incidents et la surveillance des systèmes comme mesure de gestion des risques. Les entités importantes et essentielles doivent être capables de détecter les incidents en temps quasi-réel.
• ANSSI — Guide SIEM/SOC : recommande un ensemble minimum de sources de logs pour une détection efficace, dont les contrôleurs de domaine AD, les équipements réseau périmètre, les proxies web et les systèmes d'authentification.
• PCI-DSS v4.0 (Exigence 10) : impose des exigences très précises sur la journalisation des actions dans l'environnement de données de titulaires de cartes, incluant les tentatives d'accès non autorisées, les actions des comptes privilégiés et les modifications de configuration.
• Référentiel HDS (Santé) : les systèmes hébergeant des données de santé doivent conserver les logs d'accès pendant une durée minimale et les inclure dans les procédures d'audit.

Structure détaillée du template

Section 1 — Objectifs et périmètre du logging

Définition des objectifs de la politique : détecter les incidents de sécurité en temps utile, faciliter les investigations post-incident (forensic), démontrer la conformité aux exigences normatives et légales, identifier les comportements anormaux et les menaces internes. Périmètre des systèmes soumis à la politique de logging : serveurs, postes de travail, équipements réseau, applications critiques, services cloud, solutions de sécurité.

Section 2 — Catalogue des événements à journaliser

Tableau exhaustif des événements de sécurité à logger par catégorie. Pour chaque source de logs : événements obligatoires (authentifications, changements de privilèges, accès aux données sensibles), événements recommandés (activités anormales détectables), niveau de criticité des événements (informatif, avertissement, critique), et format de log attendu. Ce catalogue couvre : Active Directory (ouvertures/fermetures de session, changements de groupes, création/suppression de comptes, modifications de GPO), équipements réseau (connexions refusées par le firewall, alertes IDS/IPS, modifications de configuration), serveurs (connexions sudo/root sur Linux, accès RDP sur Windows, exécution de scripts PowerShell), applications web (erreurs 401/403/500, injections SQL détectées, tentatives de force brute), et services cloud (connexions depuis des IP inhabituelles, téléchargements massifs, modifications de permissions).

Section 3 — Durées de rétention

Tableau de rétention des logs par catégorie : logs de sécurité (authentifications, accès privilégiés) — 12 mois minimum, 36 mois recommandé ; logs réseau (firewall, proxy) — 12 mois minimum ; logs applicatifs — 6 mois minimum, 12 mois pour les applications critiques ; logs d'accès aux données personnelles — selon les obligations RGPD (durée cohérente avec la durée du traitement). La politique précise les modalités d'archivage (logs compressés et intègres sur stockage froid) et les contraintes de performance (logs actifs sur stockage rapide pour les 90 derniers jours).

Section 4 — Protection des logs

Mesures pour garantir l'intégrité et la confidentialité des logs : centralisation dans un SIEM ou un serveur de logs dédié (les logs ne doivent pas rester uniquement sur les systèmes qu'ils surveillent — un attaquant les effacerait), chiffrement des logs en transit (TLS) et au repos, contrôle d'accès strict aux logs (lecture seule pour les analystes, pas de suppression possible par les administrateurs systèmes), hachage des fichiers de logs pour détection de toute altération (intégrité cryptographique), et sauvegarde des logs hors ligne périodique.

Section 5 — Use cases SIEM et règles de détection

Catalogue des use cases de détection priorisés : force brute sur l'authentification (X tentatives échouées en Y minutes), connexion en dehors des heures ouvrées pour des comptes sensibles, connexion depuis un pays non habituel, escalade de privilèges non planifiée, désactivation d'antivirus ou d'agent de sécurité, exfiltration de données (volume de transfert anormal vers l'extérieur), accès à des fichiers sensibles hors du groupe autorisé, création d'un compte administrateur non référencé dans la procédure JML, et modifications de GPO critiques.

Section 6 — Procédure de réponse aux alertes

Workflow de traitement des alertes générées par le SIEM ou les outils de monitoring : niveaux d'alerte (informatif, modéré, haute priorité, critique), délais de traitement par niveau (critique : 15 minutes 24/7), escalade vers le RSSI ou l'astreinte de sécurité, qualification de l'alerte (vrai positif vs faux positif), déclenchement de la procédure de gestion des incidents si nécessaire, et clôture avec documentation de la cause et des actions correctives.

Guide d'utilisation étape par étape

Étape 1 — Inventaire des sources de logs existantes

Commencez par un inventaire complet des sources de logs disponibles dans votre infrastructure : quels systèmes génèrent des logs, dans quel format (syslog, Windows Event Log, JSON, etc.), vers quelle destination (fichiers locaux, SIEM, solution cloud). Identifiez les lacunes : systèmes sans logging activé ou avec des configurations par défaut insuffisantes (par exemple, Windows Event Log sans politique d'audit avancée).

Étape 2 — Prioriser les sources critiques

Si vous ne pouvez pas tout centraliser immédiatement (contraintes de budget ou de capacité), priorisez les sources les plus critiques pour la détection : contrôleurs de domaine Active Directory, firewalls périmètre, VPN, et serveurs hébergeant les données les plus sensibles. Ces quatre sources couvrent la majorité des vecteurs d'attaque les plus fréquents (phishing → compromission AD, accès réseau non autorisé, vol de données).

Étape 3 — Configurer la politique d'audit Windows

La configuration de la politique d'audit Windows (GPO Audit Policy) est souvent insuffisante par défaut. Activez les catégories d'audit avancées recommandées par Microsoft et les guides ANSSI/CIS : logon events, account logon, account management, privilege use, object access (pour les fichiers sensibles), policy change, system events. Documentez la configuration de la GPO d'audit et la sortie en preuve dans le RTP.

Étape 4 — Déployer ou configurer le SIEM

Le SIEM (Security Information and Event Management) centralise et corrèle les logs de multiples sources. Options disponibles selon la taille de l'organisation : solutions open-source (Wazuh, Elastic SIEM, Graylog) pour les budgets limités, solutions commerciales (Microsoft Sentinel, Splunk, IBM QRadar, Exabeam) pour les organisations avec des exigences plus avancées, SIEM managé (SOC externalisé) pour les PME sans équipe sécurité dédiée. Documentez l'architecture du SIEM (sources connectées, règles de corrélation actives, capacité de stockage) comme evidence pour l'audit.

Étape 5 — Configurer les use cases de détection prioritaires

Implémentez d'abord les use cases de détection couvrant les attaques les plus fréquentes : brute force, mouvement latéral post-compromission AD, exfiltration de données. Chaque use case doit être documenté avec ses règles de corrélation, ses faux positifs connus et leur traitement, et le délai de détection attendu. Testez chaque use case avec des données synthétiques ou en simulation contrôlée.

Étape 6 — Définir la procédure de surveillance et d'astreinte

Définissez qui surveille les alertes SIEM, à quelle fréquence (24/7 ou heures ouvrées seulement), et selon quel processus d'escalade. Pour les PME sans SOC interne, une surveillance en heures ouvrées avec astreinte téléphonique pour les alertes critiques est un compromis acceptable. Pour les organisations soumises à NIS 2 ou avec des systèmes très critiques, une surveillance 24/7 interne ou externalisée est recommandée.

Étape 7 — Protéger les logs contre la falsification

Configurez les droits d'accès sur le SIEM pour que les administrateurs des systèmes sourcant les logs n'aient pas accès à la modification ou suppression des logs. Activez le hachage cryptographique des fichiers de logs pour détecter toute altération. Planifiez des sauvegardes périodiques des logs sur un stockage séparé et hors ligne. Ces mesures sont essentielles pour maintenir la valeur probatoire des logs en cas d'investigation forensic.

Étape 8 — Mesurer et reporter les KPI de monitoring

Définissez des indicateurs de performance de la surveillance : nombre d'alertes traitées par semaine, délai moyen de traitement des alertes critiques, taux de faux positifs, nombre d'incidents détectés par le monitoring vs signalés par les utilisateurs. Ces KPI sont présentés en revue de direction (clause 9.3) pour démontrer l'efficacité du monitoring et justifier les investissements dans les outils et les équipes.

Tableau des contrôles / checklist complète

Points de vigilance pour l'audit de certification

Piège 1 — Politique existante mais logs non configurés en pratique

Avoir une belle politique de logging sans que les systèmes soient réellement configurés pour journaliser les événements requis est l'une des non-conformités les plus embarrassantes. Les auditeurs peuvent demander à voir les logs directement depuis le SIEM ou les systèmes. Remédiation : réalisez un audit de la configuration d'audit sur un échantillon de systèmes représentatifs avant l'audit de certification.

Piège 2 — Durées de rétention insuffisantes

Les logs supprimés après 30 ou 90 jours ne permettent pas d'investiguer des incidents détectés tardivement (ce qui est fréquent — le délai moyen de détection d'une compromission est souvent supérieur à 100 jours). Remédiation : configurez une rétention minimale de 12 mois pour les logs de sécurité et archivez sur un stockage froid au-delà de 90 jours.

Piège 3 — Horloges non synchronisées entre systèmes

Si les logs d'un firewall et d'un serveur ne sont pas horodatés de manière cohérente (décalage horaire), corréler des événements pour reconstituer une attaque devient impossible. Les auditeurs vérifient la cohérence des horodatages. Remédiation : déployez NTP sur tous les équipements avec une source de temps autoritaire commune.

Piège 4 — Logs accessibles aux administrateurs des systèmes sourcants

Si l'administrateur d'un serveur peut effacer les logs de ce serveur, les logs n'ont pas de valeur probatoire en cas de compromission impliquant cet administrateur. C'est aussi le cas pour un attaquant qui compromet un compte admin — la première chose qu'il fera est souvent d'effacer les traces. Remédiation : centralisez les logs en temps réel vers un SIEM ou syslog server où les systèmes sourcants n'ont que des droits en écriture (pas de suppression).

Piège 5 — SIEM avec uniquement des use cases "par défaut"

Les use cases par défaut des SIEM commerciaux ne couvrent pas forcément les menaces spécifiques à votre environnement. Un auditeur questionnera la pertinence des règles de détection. Remédiation : personnalisez vos use cases en fonction de votre profil de risque et documentez la logique de chaque règle de détection.

Intégration dans le SMSI

• Politique réseau (A.8.20) : les logs réseau (firewall, proxy, NetFlow) sont des sources critiques pour le monitoring.
• Politique Anti-Malware et EDR (A.8.7) : les alertes EDR alimentent le SIEM pour la détection des menaces endpoint.
• Procédure de gestion des incidents (A.5.24) : le monitoring génère des alertes qui déclenchent la procédure de gestion des incidents.
• Procédure RCA (Clause 10.1) : les logs sont la matière première de l'analyse des causes racines des incidents.

Bonnes pratiques terrain

Commencez par les logs les plus critiques, pas par tout collecter : vouloir tout logger dès le début génère un volume ingérable de données et une fatigue d'alerte contre-productive. Commencez par les sources les plus critiques (DC, firewall, VPN) et ajoutez progressivement les autres sources.

Investissez dans la qualité plutôt que la quantité : 5 use cases SIEM bien calibrés avec un taux de faux positifs sous 5% sont bien plus efficaces que 50 règles qui génèrent des centaines d'alertes par jour que personne ne traite.

Documentez les faux positifs et leur résolution : chaque faux positif traité est une opportunité d'affiner les règles SIEM. Maintenez un journal de tuning avec les modifications apportées aux règles et leurs justifications — c'est aussi une preuve de maturité opérationnelle.

FAQ

Quelle est la différence entre A.8.15 (journalisation) et A.8.16 (surveillance) ?

A.8.15 traite de la production et de la conservation des journaux : quels événements sont enregistrés, pendant combien de temps, dans quel format, et comment ils sont protégés contre l'altération. C'est la "production de la matière première". A.8.16 traite de l'analyse active de ces journaux pour détecter des comportements anormaux : le monitoring en temps réel (SIEM), les alertes automatiques, la surveillance humaine. C'est "l'utilisation de la matière première". Les deux contrôles sont indissociables : des logs non surveillés n'ont aucune valeur de détection. Des alertes sans logs suffisamment détaillés ne permettent pas d'investiguer. En pratique, une politique de logging efficace couvre les deux aspects dans un unique document, avec des sections distinctes pour la collecte (A.8.15) et la surveillance (A.8.16). L'auditeur évaluera les deux contrôles ensemble en demandant la politique documentée et en vérifiant les preuves opérationnelles (configuration SIEM, exemple d'alertes traitées).

Les PME sans SOC peuvent-elles être conformes à A.8.15-16 ?

Oui. La conformité ne nécessite pas un SOC 24/7 interne avec des dizaines d'analystes. Pour une PME, des mesures adaptées au contexte sont parfaitement acceptables : collecte centralisée des logs sur un serveur syslog ou une solution SIEM abordable (Wazuh open-source, Microsoft Sentinel avec une licence de base), surveillance des alertes critiques en heures ouvrées avec une astreinte téléphonique pour les incidents majeurs, revue hebdomadaire des rapports SIEM par le RSSI ou le responsable IT. L'important est que le monitoring soit réel et documenté — pas seulement décrit dans une politique. Un auditeur ISO 27001 acceptera une organisation de surveillance adaptée à la taille et aux risques de l'organisation, tant que les décisions sont justifiées. Pour les organisations avec des risques élevés (données sensibles, secteur réglementé), un SOC externalisé (MSSP) peut être une option rentable qui combine conformité et efficacité opérationnelle.

Peut-on utiliser les logs Windows Event Viewer comme SIEM de base ?

L'Event Viewer de Windows est un outil de visualisation des logs locaux, pas un SIEM. Il ne centralise pas les logs de multiple systèmes, ne corrèle pas les événements, et ne génère pas d'alertes automatiques. Pour une petite organisation avec peu de serveurs, une collecte via Windows Event Forwarding (WEF) vers un serveur collecteur central est une première étape acceptable — mais elle reste limitée comparée à un SIEM. Les solutions SIEM open-source comme Wazuh ou Elastic Security sont des alternatives gratuites viables pour les organisations avec des contraintes budgétaires. Elles offrent l'essentiel : collecte multi-sources, corrélation, alertes, et dashboards. L'important pour l'auditeur ISO 27001 est que vous puissiez démontrer que vous collectez les événements requis, que vous les conservez suffisamment longtemps, et que vous les surveillez activement — peu importe l'outil utilisé pour y parvenir.