Éditorial

Analyse du mécanisme qui transforme la certification ISO 27001 en rituel de conformité, de ses bénéfices réels et des contrôles nécessaires pour en faire un levier de sécurité.

~10 min de lecture7 sections

Pourquoi ISO 27001 ne garantit pas la sécurité

ISO/IEC 27001 ne certifie pas qu’un système d’information résiste aux attaques : elle certifie la conformité d’un système de management de la sécurité de l’information (SMSI) à une norme. La différence paraît sémantique ; elle sépare pourtant une organisation qui réduit ses risques d’une organisation qui produit des preuves sur ses intentions.

→ Lire l’explication complète de la marmotte

ISO/IEC 27001 certifie un SMSI, pas une infrastructure sûre

ISO est l’Organisation internationale de normalisation et IEC est la Commission électrotechnique internationale. La norme ISO/IEC 27001 définit les exigences d’un SMSI : périmètre, analyse de risques, responsabilités, objectifs, traitement des écarts, audit interne et amélioration continue. L’annexe A propose une liste de mesures de sécurité, mais n’impose ni architecture précise, ni produit, ni niveau de durcissement universel.

Le certificat porte donc sur un périmètre déclaré. Une entité peut certifier une plate-forme SaaS (Software as a Service), un centre de services ou une partie de son système d’information, sans que les postes bureautiques, les filiales ou les environnements hérités soient inclus. Lire un certificat sans lire son périmètre revient à acheter un extincteur en supposant que le bâtiment possède aussi des murs.

Ce cadre apporte néanmoins deux choses réelles. D’abord, un langage commun dans les appels d’offres : analyse de risques, registre des actifs, gestion des incidents, revue de direction et gestion des fournisseurs désignent des objets comparables. Ensuite, une structure minimale pour les organisations qui n’avaient qu’une collection de procédures éparses, généralement stockées dans un espace documentaire dont le moteur de recherche a demandé l’asile politique.

La limite est nette : un SMSI peut être conforme alors que les contrôles techniques sont faibles, si les risques sont mal évalués, acceptés sans contradiction ou exclus du périmètre. La norme exige un processus de traitement des risques, pas une vérité physique sur l’exposition réelle. Un registre qui classe un accès administrateur partagé comme « risque faible » satisfait peut-être une gouvernance formelle ; il ne rend pas ce compte moins exploitable.

Pour décider si la certification mérite son coût, la question n’est pas « est-elle suffisante ? ». Elle ne l’est jamais. La question est : l’organisation a-t-elle besoin d’un langage contractuel et d’une discipline de gestion, tout en finançant séparément la vérification technique ? Si oui, le certificat est un socle. S’il remplace cette vérification, il devient un décor.

Le modèle économique de la certification crée une pression de complaisance

L’organisme certificateur est payé par l’organisation certifiée. Il opère dans un marché concurrentiel où le client peut changer de prestataire au cycle suivant. L’accréditation encadre les compétences, les méthodes d’audit et l’impartialité, mais elle ne supprime pas l’incitation commerciale : un audit plus long, plus conflictuel ou plus exigeant se vend moins facilement qu’un audit qui se termine avec quelques écarts mineurs et un café tiède.

Cette pression n’implique pas que chaque certificateur fraude. Elle produit un biais plus banal et plus durable : discuter la formulation d’un écart plutôt que son impact, accepter une preuve déclarative là où un test serait nécessaire, limiter l’échantillon pour tenir le nombre de jours acheté. L’audit de certification est une activité à durée bornée. Une intrusion, elle, ne respecte pas le plan de charge.

Le compromis central est là : la certification rend la sécurité achetable et comparable, mais elle la transforme aussi en produit de vérification. Ce qu’on gagne en standardisation, on le paie par une perte de profondeur. Le marché récompense la prévisibilité de l’audit ; la sécurité exige parfois de rendre visible ce qui dérange, y compris quand cela bloque une signature.

La réponse n’est pas de chercher un certificateur réputé « dur ». Cette réputation dépend souvent d’un récit commercial opposé, avec davantage de slides et la même dépendance économique. Il faut plutôt conserver une fonction de contrôle indépendante du budget de certification : audit technique interne, test d’intrusion contractuellement séparé, revue d’architecture et exercices de réponse à incident. La gouvernance de la sécurité doit recevoir ces résultats bruts, pas seulement le statut vert du certificat.

Processus déclarés et pratiques exécutées : la surface d’attaque ignorée

Un audit ISO/IEC 27001 examine principalement des éléments de preuve : politiques, comptes rendus, tickets, registres, résultats de revues, échantillons de changements. Ces éléments démontrent qu’un processus existe et laisse une trace. Ils ne démontrent pas automatiquement que le processus est exécuté sur chaque actif, au bon moment, avec les bons privilèges.

L’écart apparaît dans des mécanismes très concrets :

Une politique impose l’authentification multifacteur, mais les comptes de secours, les comptes de service et les accès d’administration hors fédération y échappent.
Une procédure impose la révocation des accès au départ d’un salarié, mais les jetons d’API (Application Programming Interface), clés SSH (Secure Shell) et sessions déjà ouvertes survivent à la désactivation de l’identité principale.
Une sauvegarde est déclarée réussie parce qu’un travail planifié se termine sans erreur, alors que la restauration échoue faute de clé de chiffrement, de dépendance réseau ou de test de restauration.
Une revue de droits est signée, mais la source de vérité ne contient pas les comptes locaux, les accès fournisseurs ni les privilèges accordés directement dans une application.

Ces écarts constituent une surface d’attaque, pas une imperfection administrative. Un attaquant exploite les divergences entre inventaire et réalité : actifs oubliés, secrets non rotatés, flux réseau exceptionnels, comptes techniques sans propriétaire, journaux non centralisés. Le contrôle documentaire décrit souvent le chemin nominal. L’attaque choisit précisément le chemin qui n’est dans aucun diagramme.

La contre-mesure consiste à relier chaque exigence de sécurité à un signal mesurable, collecté depuis le système contrôlé. Une règle de rotation de clés doit être vérifiée par l’âge réel des clés et les journaux d’usage. Une interdiction d’accès distant par mot de passe doit être testée dans la configuration effective, pas seulement dans une politique. Une architecture cyber défendable possède des assertions techniques associées à ses décisions, avec un propriétaire et une fréquence de contrôle.

Preuve exécutable des contrôles de configuration

Une preuve exécutable est un test rejouable qui interroge l’état réel d’un système. Elle ne remplace pas l’audit humain, car elle ne juge ni la pertinence du risque ni la qualité d’une décision. Elle élimine en revanche une classe entière de preuves décoratives : la capture d’écran prise le jour où quelqu’un se souvient que l’auditeur arrive.

L’exemple suivant vérifie sur un hôte Linux que le démon SSH n’accepte pas l’authentification par mot de passe ni la connexion directe du superutilisateur. Il nécessite OpenSSH Server, Bash et un accès permettant d’exécuter sshd -T. La sortie doit être centralisée dans le système de journalisation et liée à l’inventaire de l’hôte, sinon elle devient un fichier de plus dans le cimetière des pièces jointes.

#!/usr/bin/env bash
# Vérifie la configuration SSH effectivement chargée.
# Pré-requis : openssh-server installé, commande sshd disponible.
set -euo pipefail

effective_config="$(sshd -T 2>/dev/null)"

grep -qx 'passwordauthentication no' <<<"$effective_config"
grep -qx 'permitrootlogin no' <<<"$effective_config"

# Échec non nul si l'une des deux exigences n'est pas appliquée.
printf 'PASS: SSH refuse les mots de passe et la connexion root directe\n'

Ce test doit être versionné avec le référentiel d’infrastructure, exécuté après chaque changement et sur une cadence indépendante des audits externes. Une exception est acceptable si elle est limitée dans le temps, portée par un propriétaire nommé et surveillée. Une exception permanente est une règle déguisée avec une moustache administrative.

Le même principe s’applique aux identités : extraire les comptes à privilèges, vérifier leur facteur d’authentification, détecter les comptes sans propriétaire et rapprocher les accès réels du référentiel RH. Les contrôles d’identités sont particulièrement exposés au théâtre de conformité, car une revue annuelle signée paraît propre alors qu’un compte compromis travaille à la minute.

Exploitation : secrets, supervision, sauvegarde et reprise

La certification ne garantit ni la disponibilité des preuves ni la capacité à restaurer les services après compromission. Ces deux sujets doivent être conçus avant l’audit, pas ajoutés lorsque la liste des écarts devient gênante.

Les secrets utilisés par les outils de supervision, d’automatisation et de collecte de preuves doivent être séparés par fonction. Un compte qui peut lire toutes les configurations, désactiver les alertes et modifier les journaux concentre une capacité de dissimulation trop large. Les identifiants doivent être stockés dans un gestionnaire de secrets, rotatés selon leur criticité et révoqués lors du changement de propriétaire. Une rotation non testée produit fréquemment une panne silencieuse de collecte, puis un audit qui conclut à tort que tout va bien parce que le tableau de bord est resté vert.

Les journaux de sécurité doivent être exportés hors de l’hôte surveillé, protégés contre la modification et conservés selon les scénarios d’investigation. L’horodatage exige une synchronisation fiable : corréler des événements dont les horloges divergent de plusieurs minutes transforme une analyse d’incident en séance de spiritisme.

La sauvegarde doit inclure les configurations, les inventaires, les règles de détection, les autorités de certification internes et les clés nécessaires au déchiffrement. Chiffrer une sauvegarde sans procédure de restauration des clés ne protège pas la sauvegarde : cela la rend indisponible avec une rigueur mathématique. Tester la restauration dans un environnement isolé reste le seul moyen de vérifier la chaîne complète.

La position à tenir est donc stricte : demander ISO/IEC 27001 comme indicateur de maturité organisationnelle, jamais comme preuve de sécurité opérationnelle. Exiger en complément un dossier de contrôles exécutables, des résultats de restauration, une cartographie des privilèges et les écarts ouverts. Le certificat reste un filtre d’entrée. Il ne doit pas devenir le verdict final.

🐝 Ce qui arrive si on s’en passe

Sans contrôles exécutables ni vérification indépendante du budget de certification, le statut de sécurité n’existe qu’entre deux audits : la dérive de configuration survenue le lendemain d’un cycle reste invisible jusqu’au suivant, soit parfois onze mois d’exposition non mesurée. Les arbitrages budgétaires se calent alors sur la liste des écarts formels, et tout actif hors périmètre déclaré cesse d’être financé comme risque. La chaîne contractuelle propage l’effet : un fournisseur évalué sur son seul certificat transmet à ses clients une assurance qu’aucun test ne soutient, et la responsabilité se déplace vers le document plutôt que vers l’état réel. Lors d’un incident, l’absence de tests de restauration rejoués et de journaux exportés prive l’analyse de point de comparaison : impossible de dater la dérive ni de distinguer une panne d’une compromission.

🦫 Explication de la marmotte 🍫

La certification vérifie qu’une organisation a défini une manière de protéger ses informations : elle doit désigner des responsables, identifier des risques, écrire des règles, conserver des preuves et corriger les problèmes trouvés. Un auditeur examine ces éléments pendant une période limitée. Il regarde des exemples de dossiers, de comptes rendus et de changements pour décider si les règles annoncées sont respectées.

Le problème apparaît quand les documents et la réalité divergent. Une règle peut interdire un accès dangereux, alors qu’un ordinateur ou un compte ancien continue de l’autoriser. Une liste peut indiquer que les accès ont été supprimés, alors que des clés numériques, des connexions déjà ouvertes ou des comptes techniques restent actifs. L’auditeur ne peut pas toujours examiner chaque machine, chaque programme et chaque accès.

L’organisme qui réalise l’examen est payé par l’organisation examinée. Des règles encadrent ce travail, mais un organisme trop exigeant risque de perdre des clients. Cela encourage parfois des contrôles limités aux documents les plus faciles à présenter.

La certification garde donc une valeur : elle impose un minimum d’organisation et permet de comparer des fournisseurs. Elle ne protège pas seule contre une attaque. Pour réduire réellement les risques, il faut aussi tester les réglages réels, surveiller les accès, renouveler les secrets, sauvegarder les données et vérifier que leur restauration fonctionne.

Pages voisines

La citent

Pourquoi les certifications pénalisent les PME rigoureuses

Pourquoi ISO 27001 ne garantit pas la sécurité

Elle cite

: les deux pages se citent l’une l’autre.

Pourquoi ISO 27001 ne garantit pas la sécurité

Pourquoi ISO 27001 ne garantit pas la sécurité

ISO/IEC 27001 certifie un SMSI, pas une infrastructure sûre

Le modèle économique de la certification crée une pression de complaisance

Processus déclarés et pratiques exécutées : la surface d’attaque ignorée

Preuve exécutable des contrôles de configuration

Exploitation : secrets, supervision, sauvegarde et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines