Skip to main content

Pourquoi ISO 27001 existe : Le paysage des menaces, l'histoire et la logique de la norme

"La sécurité n'est pas un produit, mais un processus."

  • Bruce Schneier

Introduction : La question que personne ne pose avant d'en avoir besoin​

La plupart des organisations découvrent ISO 27001 de la même façon. Un client majeur envoie un questionnaire fournisseur avec une case cochant "Êtes-vous certifié ISO 27001 ?" Un régulateur publie des recommandations l'encourageant. Un RSSI est recruté et demande pourquoi la certification n'est pas déjà en place. L'équipe commerciale perd un contrat parce qu'un concurrent l'avait et pas eux.

Dans presque tous les cas, la norme arrive comme une exigence commerciale avant d'arriver comme une conviction sécuritaire. Et c'est précisément là que la plupart des implémentations échouent - pas techniquement, pas procéduralement, mais philosophiquement.

Les organisations qui traitent ISO 27001 comme une certification à obtenir plutôt que comme une discipline à pratiquer construisent des SMSI qui réussissent les audits et échouent face aux intrusions. Elles produisent une documentation qui paraît correcte mais qui se comporte de façon incorrecte. Elles cochent des cases, génèrent des politiques que personne ne lit, organisent des formations de sensibilisation que personne n'assimile, et s'étonnent ensuite que la norme ne les ait pas protégées.

Ce chapitre existe pour corriger cela. Avant les numéros de clauses, avant les contrôles, avant les registres de risques et la déclaration d'applicabilité - vous devez comprendre pourquoi cette norme existe, quelles forces l'ont créée, quel problème elle a été conçue pour résoudre, et pourquoi sa logique est plus sophistiquée que la plupart des praticiens ne le pensent. Si vous comprenez le pourquoi, le quoi et le comment deviennent beaucoup plus faciles à implémenter correctement.

Partie 1 - Le monde qui a rendu ISO 27001 nécessaire​

1.1 Le paysage des menaces pré-numérique : quand la sécurité physique suffisait​

Pour comprendre pourquoi les systèmes de management de la sécurité de l'information sont devenus nécessaires, il faut comprendre brièvement le monde avant eux.

Pour la majeure partie du vingtième siècle, la sécurité organisationnelle était la sécurité physique. Les informations sensibles se trouvaient dans des classeurs, des coffres-forts et des pièces à accès restreint. L'espionnage se faisait par des agents humains, pas par des paquets réseau. L'acteur malveillant volait une mallette ou photographiait des documents - il n'exfiltrait pas une base de données via un tunnel chiffré à 3 h du matin depuis un autre continent.

Les contrôles étaient intuitifs parce que les menaces l'étaient. On verrouillait le coffre. On filtrait les employés. On déchiquetait les documents. On plaçait des gardiens à l'entrée. La relation entre actif, menace et contrôle était directe, visible et gérable par une seule personne avec un presse-papiers.

Puis le réseau est arrivé. Et tout a changé de façons que personne n'avait pleinement anticipées.

1.2 Les années 1980 et 1990 : quand les réseaux ont rendu la sécurité invisible​

La commercialisation de l'informatique dans les années 1980 et l'explosion des systèmes en réseau dans les années 1990 ont créé un paradoxe avec lequel les professionnels de la sécurité vivent encore aujourd'hui : plus une organisation devenait connectée, plus elle devenait productive, et plus elle devenait vulnérable simultanément.

L'information a cessé de vivre en un seul endroit. Elle se déplaçait. Elle était copiée. Elle voyageait sur des fils, résidait sur des serveurs dans des centres de données distants, était consultée par des personnes dont l'identité ne pouvait pas être vérifiée en les regardant, et était traitée par des systèmes dont le comportement était opaque pour tout le monde sauf les ingénieurs qui les avaient construits.

Les contrôles traditionnels ne passaient pas à l'échelle. Verrouiller le classeur ne voulait rien dire quand le fichier se trouvait aussi sur un serveur à Londres, mis en cache sur un ordinateur portable à Chicago, et sauvegardé sur une bande dans une installation que personne n'avait visitée depuis deux ans.

Ce qui manquait, ce n'était pas la technologie. Ce qui manquait, c'était la discipline de gestion - une approche systématique, documentée et reproductible pour identifier ce qui devait être protégé, comprendre les menaces pesant sur lui, mettre en œuvre des contrôles proportionnés et vérifier que ces contrôles fonctionnaient réellement.

1.3 La naissance de BS 7799 : la Grande-Bretagne codifie les leçons de la pratique​

Le British Standards Institution a publié BS 7799 en 1995. Ce n'était pas un document révolutionnaire. C'était une codification - une capture structurée des pratiques de sécurité que les grandes organisations britanniques, notamment dans les services financiers et le gouvernement, avaient développées à travers une expérience difficile au cours de la décennie précédente.

En 1998, la Partie 2 de BS 7799 a introduit le concept qui deviendrait le fondement de tout ce qui a suivi : le Système de Management de la Sécurité de l'Information (SMSI). Ce fut un changement de paradigme. La norme ne disait plus seulement voici de bons contrôles à mettre en œuvre. Elle disait voici un système de management que vous devriez construire et exploiter, et voici comment savoir s'il fonctionne.

Le concept de SMSI a transformé la nature de la sécurité de l'information, la faisant passer d'une discipline technique à une discipline de management avec des composants techniques. Cette distinction est d'une importance capitale.

1.4 L'adoption ISO : vers l'international​

BS 7799 Partie 1 a été adoptée comme norme internationale en 2000, devenant ISO/IEC 17799:2000. BS 7799 Partie 2 - la spécification SMSI - est devenue ISO/IEC 27001:2005, la première version formellement certifiable de ce que nous appelons simplement ISO 27001.

La version de 2005 a établi l'architecture de base qui sous-tend encore la norme aujourd'hui :

  • Un système de management construit sur le cycle Plan-Faire-Vérifier-Agir (PDCA)
  • Une exigence de définir le périmètre et le contexte
  • Une exigence de conduire et documenter l'évaluation des risques
  • Une exigence de mettre en œuvre des contrôles de l'Annexe A (ou de justifier leur exclusion)
  • Une exigence de mesurer, surveiller, auditer et améliorer

1.5 ISO 27001:2013 - La maturité de la norme​

La révision de 2013 a apporté plusieurs changements significatifs :

L'adoption de la Structure de Haut Niveau (HLS) / Annexe SL. ISO a réorganisé la partie système de management pour s'aligner sur une structure commune utilisée dans toutes les normes de systèmes de management ISO (ISO 9001, ISO 14001, ISO 22301, etc.). Cela a rendu pratiques les systèmes de management intégrés.

Découplage du PDCA. La version 2013 a supprimé le label PDCA explicite sans abandonner la logique sous-jacente.

Révision de l'Annexe A. L'ensemble de contrôles a été réorganisé en 14 domaines (contre 11 à l'origine).

Accent accru sur les parties intéressées et le contexte. La version 2013 a introduit des exigences explicites pour comprendre le contexte de l'organisation et les besoins des parties intéressées.

1.6 ISO 27001:2022 - La norme actuelle​

La révision de 2022 est la version que toutes les nouvelles implémentations et recertifications ciblent désormais. Les changements principaux sont :

Une Annexe A restructurée. Les 114 contrôles répartis sur 14 domaines de la version 2013 ont été réorganisés en 93 contrôles sur 4 thèmes : Organisationnels (37 contrôles), Personnes (8 contrôles), Physiques (14 contrôles) et Technologiques (34 contrôles).

11 nouveaux contrôles, notamment :

  • Renseignement sur les menaces (5.7)
  • Sécurité de l'information pour l'utilisation des services cloud (5.23)
  • Préparation des TIC pour la continuité des activités (5.30)
  • Surveillance de la sécurité physique (7.4)
  • Gestion de la configuration (8.9)
  • Suppression de l'information (8.10)
  • Masquage des données (8.11)
  • Prévention des fuites de données (8.12)
  • Activités de surveillance (8.16)
  • Filtrage web (8.23)
  • Codage sécurisé (8.28)

Étiquetage par attributs. Chaque contrôle de l'Annexe A 2022 est maintenant étiqueté avec des attributs - type de contrôle (préventif, détectif, correctif), propriétés de sécurité de l'information (confidentialité, intégrité, disponibilité), concepts de cybersécurité, capacités opérationnelles et domaines de sécurité.

Partie 2 - La logique de la norme​

2.1 Ce qu'est ISO 27001 (et ce qu'elle n'est pas)​

ISO 27001 n'est pas une norme de sécurité technique. C'est une norme de système de management dont les contrôles de sécurité sont un composant.

Cette distinction n'est pas sémantique. Elle a des implications profondes sur la façon dont la norme doit être implémentée, comment elle doit être auditée, et ce qu'elle peut et ne peut pas faire pour une organisation.

ISO 27001 ne prescrit pas de contrôles techniques spécifiques. L'Annexe A fournit un ensemble de référence de contrôles, mais la norme n'exige pas que chaque organisation implémente chaque contrôle.

ISO 27001 ne garantit pas la sécurité. Une organisation certifiée peut toujours être victime d'une intrusion. La norme ne promet pas que l'information ne sera jamais compromise - elle promet que l'organisation dispose d'une approche systématique pour identifier, évaluer, traiter et surveiller les risques de sécurité de l'information.

ISO 27001 exige des preuves, pas des affirmations. La norme n'est pas satisfaite en disant "nous avons une politique." Elle est satisfaite en démontrant que la politique existe, est communiquée, est comprise, est implémentée et est révisée.

2.2 Les trois piliers : Confidentialité, Intégrité, Disponibilité​

La Confidentialité est la propriété selon laquelle l'information est accessible uniquement aux personnes autorisées à y accéder.

L'Intégrité est la propriété selon laquelle l'information est exacte, complète et n'a pas été modifiée de manière non autorisée ou non détectée.

La Disponibilité est la propriété selon laquelle l'information et les systèmes sont accessibles quand les utilisateurs autorisés en ont besoin.

2.3 Le SMSI : pourquoi un système de management et non une liste de contrôle​

La pensée basée sur les risques résout le problème de la liste de contrôle. L'ISMS (SMSI) s'en sort grâce à ce que les normes de systèmes de management ISO appellent l'amélioration continue - un cycle structuré et documenté de :

  1. Planification - comprendre le contexte, définir le périmètre, évaluer les risques, sélectionner les contrôles
  2. Mise en œuvre - mettre en place les contrôles, documenter les procédures, former le personnel
  3. Vérification - surveiller les performances, mener des audits internes, mesurer les résultats
  4. Action - répondre aux constatations, corriger les non-conformités, améliorer le système

2.4 La pensée basée sur les risques : le cœur intellectuel d'ISO 27001​

ISO 27001 exige des organisations qu'elles :

  1. Identifient leurs actifs informationnels - quelles informations existent, où elles résident, qui en est propriétaire
  2. Identifient les menaces et les vulnérabilités pertinentes pour ces actifs
  3. Évaluent la probabilité et l'impact de la matérialisation de ces menaces
  4. Déterminent les options de traitement des risques - accepter, éviter, transférer ou atténuer
  5. Sélectionnent les contrôles qui traitent les risques identifiés de manière proportionnée
  6. Documentent le raisonnement justifiant chaque décision

Partie 3 - Le contexte du paysage des menaces​

3.1 Le facteur humain : pourquoi les personnes sont le vecteur d'attaque dominant​

Le rapport Verizon Data Breach Investigations 2022 a révélé que l'élément humain était impliqué dans 82 % des violations analysées.

ISO 27001 répond à cette réalité à plusieurs niveaux :

La Clause 7.3 (Sensibilisation) exige que les personnes travaillant sous le contrôle de l'organisation soient sensibilisées à la politique de sécurité de l'information.

Les contrôles de l'Annexe A dans le thème Personnes couvrent le contrôle préalable à l'embauche (6.1), les termes et conditions d'emploi (6.2), la sensibilisation, l'éducation et la formation à la sécurité de l'information (6.3), le processus disciplinaire (6.4), les responsabilités après la résiliation (6.5), les accords de confidentialité (6.6) et le travail à distance (6.7).

3.2 Risque lié aux tiers et à la chaîne d'approvisionnement : les vecteurs que vous ne contrôlez pas​

L'attaque SolarWinds de 2020 a compromis le pipeline de construction logicielle d'une plateforme de gestion IT largement utilisée, permettant à des acteurs malveillants de distribuer des mises à jour malveillantes à environ 18 000 organisations.

Les contrôles Annexe A 5.19 à 5.22 traitent de la sécurité de l'information dans les relations avec les fournisseurs. La révision 2022 a ajouté 5.23 (Sécurité de l'information pour l'utilisation des services cloud).

3.3 Les rançongiciels et la disponibilité : la menace qui a tout changé​

La vague d'attaques par rançongiciel qui s'est intensifiée à partir d'environ 2016 - WannaCry (2017), NotPetya (2017), l'attaque de Colonial Pipeline (2021), l'attaque du HSE Irlande (2021) - a démontré que les acteurs malveillants pouvaient générer un levier financier non pas en volant des données mais en les chiffrant.

L'Annexe A 5.30 (Préparation des TIC pour la continuité des activités) - un nouveau contrôle dans la version 2022 - exige explicitement que la préparation des TIC soit planifiée, implémentée, maintenue et testée.

3.4 Les facteurs réglementaires et juridiques : pourquoi la dimension conformité compte​

Le Règlement Général sur la Protection des Données (RGPD), en vigueur dans l'Union européenne depuis 2018, exige que les organisations mettent en œuvre des "mesures techniques et organisationnelles appropriées" pour assurer la sécurité des données personnelles.

La Directive sur la Sécurité des Réseaux et des Systèmes d'Information 2 (NIS2), entrée en vigueur dans l'UE en 2023, impose des exigences de sécurité spécifiques aux opérateurs de services essentiels.

DORA (la Loi sur la Résilience Opérationnelle Numérique), applicable aux entités financières de l'UE à partir de janvier 2025, impose des exigences de gestion des risques TIC qui s'alignent substantiellement avec l'approche d'ISO 27001.

Partie 4 - Qui a besoin d'ISO 27001 et pourquoi​

4.1 Les profils d'organisations​

ISO 27001 est agnostique aux secteurs. Elle a été implémentée avec succès par :

  • Les institutions financières gérant des données clients et de transaction très sensibles
  • Les organisations de santé protégeant les dossiers patients et les systèmes cliniques
  • Les fournisseurs de services cloud dont les clients exigent l'assurance de la sécurité des données
  • Les sous-traitants gouvernementaux travaillant avec des informations officielles classifiées ou sensibles
  • Les organisations manufacturières protégeant la propriété intellectuelle et la technologie opérationnelle
  • Les cabinets juridiques et de services professionnels gérant la confidentialité des clients
  • Les startups cherchant à démontrer leur maturité en matière de sécurité à des clients entreprises
  • Les opérateurs d'infrastructure critique soumis à des exigences réglementaires de sécurité

4.2 L'argumentaire commercial : ce que la certification apporte réellement​

Accès au marché. Dans un nombre croissant de secteurs, la certification ISO 27001 est un prérequis pour l'approbation des fournisseurs.

Efficacité de la diligence raisonnable. La certification remplace les évaluations de sécurité longues et coûteuses par un justificatif reconnu, audité de manière indépendante.

Réduction du coût des incidents. Les organisations dotées de systèmes de management de la sécurité matures connaissent moins d'incidents et de moindre coût.

Positionnement réglementaire. Le calcul des amendes RGPD prend explicitement en compte si une organisation avait mis en place des "mesures techniques et organisationnelles appropriées".

Assurance. Les organisations dotées de SMSI certifiés peuvent accéder à une meilleure couverture à des primes plus basses.

Culture. ISO 27001, correctement implémentée, transforme la façon dont une organisation pense à la sécurité de l'information.

4.3 Le cas d'utilisation abusif : quand ISO 27001 devient un exercice de papier​

Le mode de défaillance le plus courant est le SMSI de conformité uniquement : un SMSI conçu pour réussir un audit plutôt que pour gérer la sécurité. L'antidote est l'engagement de la direction - un engagement véritable et opérationnel de la part du sommet de l'organisation.

Partie 5 - Comprendre la structure de la norme avant de la lire​

5.1 La structure des clauses​

ISO 27001 est organisée en dix clauses, dont les Clauses 4 à 10 contiennent les exigences :

ClauseTitreExigence principale
4Contexte de l'organisationComprendre le contexte interne et externe ; définir le périmètre ; identifier les parties intéressées
5LeadershipEngagement de la direction ; politique de sécurité de l'information ; rôles et responsabilités
6PlanificationÉvaluation des risques ; traitement des risques ; objectifs de sécurité de l'information
7SupportRessources ; compétence ; sensibilisation ; communication ; informations documentées
8FonctionnementPlanification et contrôle opérationnels ; exécution de l'évaluation des risques ; mise en œuvre du traitement des risques
9Évaluation des performancesSurveillance ; mesure ; audit interne ; revue de direction
10AméliorationNon-conformité et action corrective ; amélioration continue

5.2 La relation entre les clauses​

Les clauses ne sont pas indépendantes. Elles forment une séquence logique qui reflète le fonctionnement d'un programme de sécurité bien géré.

5.3 Le rôle de l'Annexe A​

L'Annexe A est normative mais pas prescriptive. Elle exige que chaque contrôle soit considéré - que le processus d'évaluation des risques produise une détermination documentée de l'applicabilité ou non de chaque contrôle, et que la Déclaration d'Applicabilité enregistre et justifie chaque inclusion et exclusion.

Résumé : Ce que le Chapitre 1 a établi​

Historiquement, ISO 27001 est né de décennies d'expérience organisationnelle durement acquise sur le fossé entre les contrôles de sécurité techniques et la discipline de gestion nécessaire pour les déployer efficacement.

Conceptuellement, ISO 27001 est une norme de système de management, pas une spécification technique. Sa logique centrale est basée sur les risques.

Pratiquement, ISO 27001 est importante parce que le paysage des menaces le rend nécessaire, que l'environnement réglementaire l'exige de plus en plus, que le marché le récompense de plus en plus, et que l'alternative - des décisions de sécurité ad hoc, non documentées et non mesurées - produit démontrablement de moins bons résultats.

De manière critique, ISO 27001 n'a de valeur qu'à hauteur de l'engagement organisationnel qui la soutient.

Suivant : Chapitre 2 - Construire le SMSI de zéro : Contexte, périmètre, parties intéressées et adhésion de la direction

© ISO 27001 Wiki - Pour les RSSI, analystes de sécurité et professionnels GRC