Annexe A Démasquée : Chaque Domaine de Contrôle, sa Pertinence vis-à-vis de la Surface d'Attaque et ses Échecs d'Implémentation les Plus Courants
"Un verrou n'est solide que s'il est sur une porte solide."
- Proverbe de sécurité
Introduction : Le Document le Plus Mal Compris en Sécurité de l'Information
L'Annexe A est la partie d'ISO 27001 à laquelle la plupart des organisations se tournent en premier. Avant que l'évaluation des risques soit terminée, avant que le périmètre soit correctement défini, avant que la méthodologie soit documentée - quelqu'un ouvre la norme, se rend à l'Annexe A, et commence à construire un tableur. Cela semble productif. Cela ressemble à du progrès. C'est souvent la première erreur.
L'Annexe A n'est pas une liste de tâches. Ce n'est pas une norme de sécurité minimale. Ce n'est pas un catalogue de contrôles que toutes les organisations doivent implémenter. C'est un ensemble de contrôles de référence - un compendium structuré de contrôles de sécurité que les organisations devraient considérer lors de la conception du traitement des risques, avec l'obligation que chaque contrôle soit soit appliqué, soit explicitement et justifiablement exclu.
Cette distinction est extraordinairement importante en pratique. Les organisations qui traitent l'Annexe A comme une liste de contrôle implémentent des contrôles qui ne répondent pas à leurs risques réels. Les organisations qui la traitent comme une référence - en l'appliquant en aval d'une véritable évaluation des risques - construisent des environnements de contrôle proportionnels, défendables et genuinement protecteurs.
Partie 1 - La Restructuration 2022 : Comprendre la Nouvelle Architecture
1.1 De 114 à 93 : Ce qui a Changé et Pourquoi
La version 2013 d'ISO 27001 organisait 114 contrôles en 14 domaines. La version 2022 les a réorganisés en 93 contrôles répartis en 4 thèmes. La réduction du nombre de contrôles ne représente pas une réduction de périmètre - la plupart des "réductions" reflètent la fusion de contrôles traitant des préoccupations redondantes. Onze nouveaux contrôles ont été ajoutés pour traiter les menaces et technologies que la version 2013 n'avait pas couvertes de manière adéquate.
Les quatre thèmes remplacent la structure en domaines :
| Thème | Contrôles | Focus |
|---|---|---|
| Organisationnel (5.x) | 37 | Politiques, processus, gouvernance, relations fournisseurs, gestion de l'information |
| Humain (6.x) | 8 | Sécurité des ressources humaines - criblage, formation, sensibilisation, fin d'emploi |
| Physique (7.x) | 14 | Sécurité physique et environnementale |
| Technologique (8.x) | 34 | Contrôles techniques - accès, cryptographie, opérations, développement |
1.2 Le Nouveau Système d'Attributs
Chaque contrôle dans l'Annexe A 2022 est étiqueté avec cinq ensembles d'attributs. Ces attributs ne sont pas des exigences - ce sont des outils analytiques qui aident les organisations à filtrer et organiser l'ensemble des contrôles.
Type de contrôle : Préventif (réduit la probabilité d'un incident), Détectif (identifie qu'un incident s'est produit), Correctif (restaure la sécurité après un incident).
Propriétés de sécurité de l'information : Lequel de la triade CIA le contrôle adresse principalement - Confidentialité, Intégrité, Disponibilité.
Concepts de cybersécurité : Alignement avec les fonctions du NIST CSF - Identifier, Protéger, Détecter, Répondre, Récupérer.
Capacités opérationnelles : La capacité de sécurité que le contrôle supporte.
Domaines de sécurité : Gouvernance et écosystème, protection, défense, résilience.
Partie 2 - Contrôles Organisationnels (5.1–5.37)
5.1 - Politiques de Sécurité de l'Information
Objet : Établir la base de gouvernance - un ensemble de politiques approuvées par la direction, communiquées au personnel, et revues à intervalles définis.
Pertinence surface d'attaque : L'absence ou l'inadéquation des politiques crée une exposition indirecte partout. Sans politique de classification de l'information claire, les employés ne savent pas comment traiter les données sensibles.
Échec courant : Les politiques existent sous forme de documents plutôt que de pratiques. Elles sont approuvées par le RSSI et stockées dans un site SharePoint que personne ne connaît. Elles utilisent un langage de modèle générique qui ne reflète pas le contexte réel de l'organisation. Le test le plus sûr : demandez à n'importe quel employé quel est le schéma de classification de l'information de l'organisation. S'il ne peut pas répondre, la politique de classification n'a pas été communiquée.
Ce que signifie bien faire : Un cadre de politique petit et cohérent - une politique de sécurité de l'information de haut niveau, plus des politiques de support pour des domaines spécifiques - qui est rédigé dans un langage adapté à son audience, revu annuellement, intégré à l'intégration des nouveaux employés et visiblement référencé dans les décisions opérationnelles.
5.2 - Rôles et Responsabilités en Sécurité de l'Information
Objet : Veiller à ce que les responsabilités en matière de sécurité soient définies, attribuées et communiquées.
Échec courant : Les rôles sont définis dans la documentation du SMSI mais ne sont pas reflétés dans les fiches de poste, les objectifs de performance ou la pratique opérationnelle. Les propriétaires d'actifs existent sur le papier mais n'ont jamais été informés de ce que la propriété d'actifs exige d'eux.
5.3 - Séparation des Tâches
Objet : Empêcher qu'un seul individu ait la capacité de commettre et de dissimuler un acte frauduleux ou malveillant en séparant les responsabilités conflictuelles.
Pertinence surface d'attaque : Les défaillances de séparation des tâches sont un facteur primaire de fraude interne. Si la même personne peut créer un fournisseur, approuver un paiement et traiter la transaction, un seul compte compromis peut permettre une fraude financière.
Échec courant : La séparation des tâches est traitée comme une préoccupation financière et d'audit plutôt qu'un contrôle de sécurité. L'administrateur informatique qui gère l'Active Directory gère également le SIEM qui détecterait les modifications AD non autorisées.
5.4 - Responsabilités de la Direction
Objet : Demander à la direction à tous les niveaux de soutenir activement la sécurité de l'information dans leurs domaines de responsabilité.
Échec courant : Les responsabilités de sécurité de la direction ne sont pas incluses dans les objectifs de performance des managers. La sécurité est traitée comme quelque chose que fait l'équipe de sécurité, pas comme quelque chose dont les managers sont responsables.
5.5 - Contact avec les Autorités
Objet : Maintenir les contacts appropriés avec les autorités répressives, réglementaires et les services d'urgence.
Pertinence surface d'attaque : Le RGPD exige une notification aux autorités de contrôle dans les 72 heures suivant la prise de connaissance d'une violation de données personnelles. NIS2 exige une notification initiale dans les 24 heures pour les incidents significatifs.
Échec courant : Les contacts existent dans un document maintenu par les services juridiques/conformité et n'est pas accessible à l'équipe de réponse aux incidents à 2h00 du matin quand une violation est découverte.
5.6 - Contact avec des Groupes d'Intérêt Spéciaux
Objet : Maintenir le contact avec des forums de sécurité, associations professionnelles et communautés de partage d'information pertinentes.
Échec courant : Ce contrôle est souvent traité comme une case à cocher - quelques adhésions professionnelles sont notées et le contrôle est marqué comme implémenté. La valeur du contrôle réside dans la participation active.
5.7 - Renseignement sur les Menaces (Nouveau en 2022)
Objet : Collecter, analyser et utiliser le renseignement sur les menaces pertinent pour les risques de sécurité de l'information.
Pertinence surface d'attaque : Il s'agit de l'un des ajouts les plus significatifs de la norme 2022. Les organisations sans capacité de renseignement sur les menaces naviguent à l'aveugle - leurs évaluations des risques sont basées sur des catégories de menaces génériques plutôt que sur les techniques, cibles et outils spécifiques des acteurs malveillants ciblant réellement leur secteur.
Échec courant : Le renseignement sur les menaces est confondu avec l'analyse de vulnérabilités ou les actualités de sécurité génériques. La plupart des organisations consomment le renseignement passivement plutôt qu'activement.
Ce que signifie bien faire : Un processus de renseignement sur les menaces défini qui identifie les sources pertinentes (ISACs, avis gouvernementaux, flux de renseignements des fournisseurs, OSINT), assigne la responsabilité de la consommation et de l'analyse, et établit un mécanisme pour alimenter les décisions de sécurité.
5.8 - Sécurité de l'Information dans la Gestion de Projet
Objet : Intégrer la sécurité de l'information dans la méthodologie de gestion de projet.
Pertinence surface d'attaque : La dette technique de sécurité est presque toujours créée au lancement du projet - quand un nouveau système est conçu sans exigences de sécurité.
Échec courant : La sécurité est une revue de contrôle tardive plutôt qu'une contribution à la conception précoce.
5.9 - Inventaire des Informations et Autres Actifs Associés
Objet : Identifier et maintenir un inventaire des actifs informationnels et de leurs propriétaires.
Pertinence surface d'attaque : Comme établi au chapitre 3, on ne peut pas protéger ce qu'on ne sait pas avoir.
Échec courant : L'inventaire existe mais est incomplet (shadow IT, expansion cloud), obsolète ou insuffisamment détaillé.
5.10 - Utilisation Acceptable des Informations et Autres Actifs Associés
Objet : Définir des règles pour l'utilisation acceptable des actifs informationnels.
Échec courant : La politique est rédigée pour un paysage technologique qui n'existe plus - elle traite de l'e-mail et de la navigation web mais pas des services cloud, des appareils personnels, des outils d'IA ou des environnements de travail à distance.
5.11 - Restitution des Actifs
Objet : Veiller à ce que les employés retournent tous les actifs organisationnels à la fin de leur emploi.
Pertinence surface d'attaque : Les employés licenciés qui conservent l'accès aux systèmes ou informations organisationnels représentent une menace persistante.
Échec courant : Le processus de départ traite le retour d'appareils (ordinateurs portables, téléphones) mais manque les actifs numériques - identifiants de services cloud, copies personnelles de données organisationnelles, accès aux services SaaS souscrits personnellement.
5.12 - Classification de l'Information
Objet : Classer les informations selon leur sensibilité et leur valeur.
Pertinence surface d'attaque : La classification de l'information est le fondement de la protection proportionnelle des données.
Échec courant : Les schémas de classification sont trop complexes, ou la classification est un exercice sur papier sans conséquence opérationnelle.
5.13 - Étiquetage de l'Information
Objet : Appliquer des étiquettes d'information conformément au schéma de classification.
Échec courant : L'étiquetage est appliqué aux nouveaux documents mais pas au stock documentaire existant. Les étiquettes électroniques utilisent des métadonnées qui sont supprimées lorsque les documents sont partagés à l'extérieur.
5.14 - Transfert d'Information
Objet : Veiller à ce que les informations transférées dans et hors de l'organisation soient adéquatement protégées.
Pertinence surface d'attaque : Les données en transit sont exposées à l'interception, la modification et la misdirection.
Échec courant : Les politiques de transfert existent pour les canaux formels mais pas pour les canaux informels que les employés utilisent réellement (messagerie personnelle, WhatsApp, clés USB, stockage cloud personnel).
5.15 - Contrôle d'Accès
Objet : Établir des règles pour contrôler l'accès aux informations et systèmes.
Pertinence surface d'attaque : Les défaillances de contrôle d'accès sont impliquées dans la majorité des incidents de sécurité significatifs.
Échec courant : Les droits d'accès s'accumulent au fil du temps sans révision - les employés changent de rôles, accumulent des permissions des rôles précédents et ont finalement bien plus d'accès que leur rôle actuel ne l'exige.
5.16 - Gestion des Identités
Objet : Gérer le cycle de vie complet des identités - création, maintenance et suppression.
Échec courant : Les comptes obsolètes - anciens employés, anciens contractants, comptes de service pour des systèmes décommissionnés - persistent dans l'annuaire longtemps après que l'accès associé aurait dû être supprimé.
5.17 - Informations d'Authentification
Objet : Contrôler la gestion des informations d'authentification (mots de passe, clés, certificats, jetons).
Pertinence surface d'attaque : Le vol et l'utilisation abusive d'identifiants sont impliqués dans la majorité des violations externes.
Échec courant : Les politiques de mots de passe se concentrent sur les règles de complexité plutôt que sur la longueur. L'authentification multifacteur est déployée pour l'accès externe mais pas pour les systèmes internes. Les mots de passe des comptes de service ne sont jamais changés.
5.18 - Droits d'Accès
Objet : Gérer l'attribution, la modification et la suppression des droits d'accès.
Échec courant : L'attribution d'accès est bien contrôlée mais la modification et la suppression d'accès ne le sont pas. Les changements de rôle ne déclenchent pas de révision d'accès.
5.19 - Sécurité de l'Information dans les Relations avec les Fournisseurs
Objet : Protéger les actifs de l'organisation accessibles ou traités par les fournisseurs.
Pertinence surface d'attaque : Les attaques de la chaîne d'approvisionnement sont devenues l'un des principaux vecteurs de violation précisément parce que les organisations ont investi massivement dans la sécurité périmétrique tout en laissant les relations fournisseurs insuffisamment contrôlées.
Échec courant : La sécurité des fournisseurs est gérée contractuellement mais pas opérationnellement. Le questionnaire de sécurité des fournisseurs est rempli à l'intégration et jamais revisité.
5.20 - Prise en Compte de la Sécurité de l'Information dans les Accords avec les Fournisseurs
Objet : Établir des exigences de sécurité de l'information dans les contrats fournisseurs.
Échec courant : Les clauses de sécurité sont génériques - copiées depuis un modèle et incluses dans chaque contrat quelle que soit le profil de risque du fournisseur. Elles utilisent un langage vague impossible à auditer.
5.21 - Gestion de la Sécurité de l'Information dans la Chaîne d'Approvisionnement TIC
Objet : Traiter les risques de sécurité de l'information associés à la chaîne d'approvisionnement en produits et services TIC.
Pertinence surface d'attaque : Les attaques de la chaîne d'approvisionnement logicielle - compromission des pipelines de build logiciel, mécanismes de mise à jour ou dépendances open source pour distribuer du code malveillant - ont émergé comme l'un des vecteurs d'attaque les plus sophistiqués. SolarWinds, Kaseya et Log4Shell sont des exemples très médiatisés.
Échec courant : Le risque de la chaîne d'approvisionnement TIC est traité comme une décision d'achat (évaluation de la sécurité du fournisseur au moment de l'achat) plutôt qu'une préoccupation de sécurité continue.
5.22 - Surveillance, Révision et Gestion des Changements des Services des Fournisseurs
Objet : Surveiller, réviser et gérer régulièrement les changements apportés aux services des fournisseurs.
Échec courant : La révision des fournisseurs est effectuée annuellement plutôt que continuellement. Les changements apportés aux services des fournisseurs ne sont pas systématiquement surveillés.
5.23 - Sécurité de l'Information pour l'Utilisation des Services Cloud (Nouveau en 2022)
Objet : Établir des processus pour l'acquisition, l'utilisation, la gestion et la sortie des services cloud.
Pertinence surface d'attaque : Les services cloud introduisent des considérations de sécurité uniques - modèles de responsabilité partagée, risques de multi-location, préoccupations de souveraineté des données.
Échec courant : Les organisations supposent que l'utilisation d'un grand fournisseur cloud (AWS, Azure, GCP) signifie que la sécurité est prise en charge. Le modèle de responsabilité partagée est mal compris. Les compartiments de stockage cloud mal configurés ont été la cause directe de nombreuses expositions de données significatives.
5.24 - Planification et Préparation de la Gestion des Incidents de Sécurité de l'Information
Objet : Planifier et préparer la gestion des incidents de sécurité de l'information.
Pertinence surface d'attaque : Les organisations qui commencent à planifier leur réponse aux incidents après qu'une violation est en cours perdent un temps critique et font des erreurs évitables.
Échec courant : Les plans de réponse aux incidents existent sous forme de documents mais n'ont jamais été testés. Ils contiennent des informations de contact obsolètes. Les décisions clés - quand impliquer les forces de l'ordre, quand notifier les régulateurs - n'ont pas été pré-autorisées.
5.25 - Évaluation et Décision sur les Événements de Sécurité de l'Information
Objet : Établir des critères pour évaluer les événements de sécurité et déterminer s'ils constituent des incidents.
Échec courant : Les critères d'escalade sont vagues, appliqués de manière incohérente et non communiqués au personnel qui prend les décisions d'évaluation de première ligne.
5.26 - Réponse aux Incidents de Sécurité de l'Information
Objet : Répondre aux incidents conformément aux procédures documentées.
Échec courant : Les procédures de réponse couvrent le confinement et l'éradication techniques mais pas le cycle de vie complet de l'incident - continuité des activités, gestion des communications, notification réglementaire, exigences de conservation légale.
5.27 - Apprentissage des Incidents de Sécurité de l'Information
Objet : Utiliser les connaissances acquises des incidents pour réduire les risques futurs.
Échec courant : Les revues post-incident se concentrent sur ce qui s'est passé plutôt que sur pourquoi cela s'est passé et quels changements systématiques empêcheraient la récurrence. Les mêmes types d'incidents se répètent parce que les causes profondes n'ont pas été traitées.
5.28 - Collecte de Preuves
Objet : Définir et implémenter des procédures pour l'identification, la collecte, l'acquisition et la préservation des preuves.
Pertinence surface d'attaque : Les preuves non correctement préservées peuvent être irrecevables dans les procédures judiciaires ou insuffisantes pour les enquêtes réglementaires.
Échec courant : Les périodes de conservation des journaux sont trop courtes pour soutenir les enquêtes sur les incidents - de nombreuses attaques ont des durées de présence de semaines ou mois.
5.29 - Sécurité de l'Information Pendant les Perturbations
Objet : Planifier le maintien ou la restauration de la sécurité de l'information à un niveau approprié pendant une perturbation.
Échec courant : Les plans de continuité des activités traitent de la résilience opérationnelle mais pas de la résilience de sécurité.
5.30 - Préparation des TIC pour la Continuité des Activités (Nouveau en 2022)
Objet : Planifier, implémenter, maintenir et tester la préparation des TIC pour assurer la disponibilité des informations.
Échec courant : Les procédures de sauvegarde existent mais n'ont pas été testées. La récupération après ransomware n'a pas été spécifiquement répétée.
5.31 - Exigences Légales, Réglementaires et Contractuelles
Objet : Identifier et documenter les exigences légales, réglementaires et contractuelles pertinentes.
Échec courant : Le registre des exigences est maintenu par les services juridiques/conformité et n'est pas intégré dans le SMSI.
5.32 - Droits de Propriété Intellectuelle
Objet : Implémenter des procédures appropriées pour protéger les droits de propriété intellectuelle.
Échec courant : La gestion des licences logicielles n'est pas suivie. Les obligations de licence open source ne sont pas évaluées.
5.33 - Protection des Enregistrements
Objet : Protéger les enregistrements contre la perte, la destruction, la falsification et l'accès non autorisé.
Échec courant : Les calendriers de conservation existent mais ne sont pas opérationnalisés - les données s'accumulent indéfiniment.
5.34 - Confidentialité et Protection des Informations Personnelles
Objet : Identifier et respecter les exigences pour la préservation de la confidentialité et la protection des informations personnelles.
Échec courant : La confidentialité et la sécurité sont gérées par des équipes différentes avec une coordination limitée.
5.35 - Révision Indépendante de la Sécurité de l'Information
Objet : Réviser indépendamment l'approche de gestion de la sécurité de l'information.
Échec courant : L'audit interne a une expertise de sécurité insuffisante pour mener des revues significatives des contrôles techniques.
5.36 - Conformité aux Politiques et Normes de Sécurité de l'Information
Objet : Réviser régulièrement la conformité avec les politiques, règles et normes de sécurité de l'information.
Échec courant : La revue de conformité est limitée à la documentation - vérification que les politiques existent plutôt que vérification qu'elles sont suivies.
5.37 - Procédures d'Exploitation Documentées
Objet : Documenter les procédures d'exploitation des équipements de traitement de l'information.
Échec courant : Les procédures sont non documentées - les opérations critiques dépendent des connaissances tribales détenues par des personnes spécifiques.
Partie 3 - Contrôles Humains (6.1–6.8)
6.1 - Criblage
Objet : Effectuer des vérifications d'antécédents sur les candidats à l'emploi.
Pertinence surface d'attaque : La menace interne commence à l'embauche.
Échec courant : Le criblage est appliqué de manière incohérente - les cadres supérieurs et les dirigeants ne sont pas criblés malgré leur accès plus élevé.
6.2 - Termes et Conditions d'Emploi
Objet : Établir des obligations de sécurité contractuelles pour les employés et contractants.
Échec courant : Les obligations de sécurité sont enfouies dans de longs contrats de travail que les employés signent sans lire.
6.3 - Sensibilisation, Éducation et Formation en Sécurité de l'Information
Objet : Veiller à ce que tout le personnel reçoive une formation de sensibilisation à la sécurité appropriée.
Pertinence surface d'attaque : Il s'agit du contrôle qui traite le plus directement la surface d'attaque humaine.
Échec courant : Formation de conformité annuelle que les employés cliquent sans s'y engager. Le taux de complétion de la formation est mesuré comme indicateur de sécurité, plutôt que le changement de comportement.
Ce que signifie bien faire : Un programme de formation en couches - sensibilisation de base pour tout le personnel, formation spécifique au rôle pour les rôles à haut risque, campagnes de phishing simulées qui identifient les vulnérabilités spécifiques.
6.4 - Processus Disciplinaire
Objet : Établir un processus disciplinaire formel pour les employés qui ont violé les politiques de sécurité.
Échec courant : Le processus disciplinaire existe dans la politique RH mais les violations de politique de sécurité ne sont pas reconnues comme déclencheurs disciplinaires.
6.5 - Responsabilités Après Résiliation ou Changement d'Emploi
Objet : Veiller à ce que les responsabilités de sécurité qui survivent à l'emploi soient clairement communiquées et appliquées.
Échec courant : Les obligations post-emploi sont dans le contrat de travail mais ne sont jamais discutées lors du départ. Les anciens employés conservent des copies des informations organisationnelles sur des appareils personnels.
6.6 - Accords de Confidentialité ou de Non-Divulgation
Objet : Utiliser des accords de confidentialité ou de NDA pour protéger les informations organisationnelles.
Échec courant : Les NDA sont génériques et ne sont pas adaptés aux informations spécifiques protégées ou aux risques spécifiques de la relation.
6.7 - Télétravail
Objet : Implémenter des mesures de sécurité pour protéger les informations accessibles, traitées ou stockées dans des lieux de télétravail.
Pertinence surface d'attaque : Le travail à distance a considérablement étendu la surface d'attaque. Le réseau domestique est généralement bien moins contrôlé que le réseau d'entreprise.
Échec courant : La politique de sécurité du travail à distance a été développée précipitamment pendant la pandémie et n'a pas été revue depuis.
6.8 - Signalement des Événements de Sécurité de l'Information
Objet : Établir un mécanisme permettant aux employés de signaler les événements de sécurité observés ou suspectés.
Pertinence surface d'attaque : La durée de présence moyenne des menaces persistantes avancées est mesurée en semaines à mois. Les employés peuvent observer des indicateurs de compromission pendant cette période.
Échec courant : Le mécanisme de signalement existe mais n'est pas communiqué. Les employés qui signalent des incidents ne reçoivent pas de retour.
Partie 4 - Contrôles Physiques (7.1–7.14)
7.1 - Périmètres de Sécurité Physique
Objet : Définir et implémenter des périmètres de sécurité pour protéger les zones contenant des informations sensibles.
Échec courant : Les périmètres de sécurité physique sont définis pour les centres de données mais pas pour les zones où des travaux sensibles sont régulièrement effectués.
7.2 - Contrôle d'Accès Physique
Objet : Contrôler l'accès physique aux zones sécurisées.
Échec courant : Les listes de contrôle d'accès pour les zones sécurisées ne sont pas régulièrement révisées. Les accréditations d'accès physique des anciens employés ne sont pas révoquées rapidement.
7.3 - Sécurisation des Bureaux, Salles et Installations
Objet : Concevoir et implémenter la sécurité physique pour les bureaux, salles et installations.
Échec courant : Les politiques de bureau propre existent mais ne sont pas appliquées. Les tableaux blancs contenant des informations sensibles ne sont pas effacés en fin de journée.
7.4 - Surveillance de la Sécurité Physique (Nouveau en 2022)
Objet : Surveiller en continu les locaux pour les accès physiques non autorisés.
Échec courant : La CCTV couvre les points d'entrée mais pas les zones internes. La surveillance est enregistrée mais pas revue sauf après des incidents connus.
7.5 - Protection Contre les Menaces Physiques et Environnementales
Objet : Se protéger contre les menaces physiques et environnementales - incendie, inondation, séismes, pannes de courant.
Échec courant : La surveillance environnementale est implémentée dans le centre de données principal mais pas dans les installations secondaires.
7.6 - Travail dans les Zones Sécurisées
Objet : Concevoir et implémenter des mesures de sécurité pour le travail dans les zones sécurisées.
Échec courant : Des contractants non escortés travaillent dans les salles de serveurs.
7.7 - Bureau Propre et Écran Propre
Objet : Définir et implémenter des règles de bureau propre et d'écran propre.
Échec courant : La politique existe mais la conformité comportementale n'est pas surveillée. Les délais de verrouillage automatique de l'écran sont trop longs.
7.8 - Implantation et Protection des Équipements
Objet : Protéger les équipements contre les menaces environnementales et les accès non autorisés.
Échec courant : Les contrôles environnementaux de la salle serveurs (température, humidité) ne sont pas surveillés avec des alertes. La protection contre les coupures de courant n'a pas été testée dans des conditions réelles de défaillance.
7.9 - Sécurité des Actifs Hors des Locaux
Objet : Protéger les actifs emportés hors site.
Échec courant : Les ordinateurs portables sont chiffrés mais les téléphones mobiles et les tablettes ne le sont pas.
7.10 - Supports de Stockage
Objet : Gérer le cycle de vie des supports de stockage.
Pertinence surface d'attaque : Les supports de stockage éliminés sans effacement sécurisé constituent un risque direct pour la confidentialité.
Échec courant : Les procédures d'élimination des médias existent pour les équipements gérés centralement mais pas pour les appareils terminaux retournés par le personnel.
7.11 - Utilités de Support
Objet : Protéger les installations de traitement de l'information contre les pannes de courant et autres perturbations.
Échec courant : La protection électrique est implémentée pour les systèmes primaires mais pas pour les équipements réseau ou les systèmes de sécurité physique.
7.12 - Sécurité du Câblage
Objet : Protéger le câblage contre l'interception, l'interférence ou les dommages.
Échec courant : Le câblage est protégé dans les centres de données mais pas dans les zones de bureau - les ports réseau dans les salles de réunion accessibles peuvent être utilisés pour un accès réseau non autorisé.
7.13 - Maintenance des Équipements
Objet : Maintenir correctement les équipements pour assurer leur disponibilité et intégrité continues.
Échec courant : La maintenance est effectuée sur les équipements primaires mais pas sur les systèmes de sauvegarde.
7.14 - Élimination ou Réutilisation Sécurisée des Équipements
Objet : Vérifier que toutes les données sensibles ont été supprimées ou écrasées avant l'élimination ou la réutilisation des équipements.
Échec courant : La suppression standard du système d'exploitation ou le formatage est utilisé plutôt que l'écrasement sécurisé ou la destruction physique.
Partie 5 - Contrôles Technologiques (8.1–8.34)
8.1 - Appareils Terminaux Utilisateurs
Objet : Protéger les informations stockées sur, traitées par ou accessibles via les appareils terminaux.
Échec courant : La protection des terminaux est déployée sur les appareils d'entreprise gérés mais pas sur les appareils personnels utilisés pour le travail.
8.2 - Droits d'Accès Privilégiés
Objet : Restreindre et gérer l'utilisation des droits d'accès privilégiés.
Pertinence surface d'attaque : Les comptes privilégiés - ceux avec un accès administratif aux systèmes, bases de données, infrastructure réseau et outils de sécurité - sont la cible principale des attaquants sophistiqués.
Échec courant : Les comptes privilégiés sont utilisés pour les tâches quotidiennes (email, navigation web) en même temps que les tâches administratives. L'activité d'accès privilégié n'est pas enregistrée ou surveillée.
Ce que signifie bien faire : Des comptes privilégiés séparés utilisés exclusivement pour les tâches administratives. Accès privilégié juste-à-temps accordé pour des tâches spécifiques et révoqué immédiatement après. Journalisation complète de toute activité d'accès privilégié.
8.3 - Restriction d'Accès à l'Information
Objet : Restreindre l'accès aux informations et aux fonctions applicatives.
Échec courant : L'accès est contrôlé au niveau du système (qui peut accéder à l'application) mais pas au niveau des données (quels enregistrements l'utilisateur peut voir).
8.4 - Accès au Code Source
Objet : Restreindre l'accès au code source des programmes.
Pertinence surface d'attaque : Le code source est une cible de grande valeur pour le vol de propriété intellectuelle et pour les attaques de la chaîne d'approvisionnement.
Échec courant : Les référentiels de code source sont accessibles à tous les développeurs. Les anciens développeurs conservent l'accès au référentiel après leur départ. Des secrets (clés API, identifiants) sont encodés en dur dans le code source.
8.5 - Authentification Sécurisée
Objet : Implémenter des technologies et procédures d'authentification sécurisées.
Pertinence surface d'attaque : L'authentification est le principal mécanisme de contrôle d'accès aux informations.
Échec courant : L'authentification multifacteur est déployée de manière sélective - l'accès externe nécessite la MFA mais les systèmes internes ne le font pas.
8.6 - Gestion de la Capacité
Objet : Surveiller et ajuster l'utilisation des ressources pour assurer les performances et la disponibilité du système.
Échec courant : La planification de la capacité traite les opérations normales mais pas la réponse aux incidents.
8.7 - Protection Contre les Logiciels Malveillants
Objet : Implémenter des contrôles pour se protéger contre les logiciels malveillants.
Échec courant : L'antivirus est déployé sur les terminaux mais pas sur les serveurs ou les charges de travail cloud. La détection est basée sur les signatures et ne détecte pas les nouveaux logiciels malveillants sans fichier.
8.8 - Gestion des Vulnérabilités Techniques
Objet : Gérer les vulnérabilités techniques des systèmes d'information.
Pertinence surface d'attaque : Les vulnérabilités non corrigées sont le deuxième vecteur d'attaque le plus exploité après la compromission d'identifiants. Le délai entre la divulgation de la vulnérabilité et l'exploitation s'est considérablement raccourci.
Échec courant : Les processus de correctifs traitent les systèmes d'exploitation et les applications majeures mais manquent les microprogrammes, les appareils réseau, les appareils IoT et les bibliothèques tierces.
8.9 - Gestion de la Configuration (Nouveau en 2022)
Objet : Définir, documenter, implémenter, surveiller et réviser les configurations de sécurité.
Échec courant : Les bases de référence de sécurité existent sur le papier mais la dérive de configuration - systèmes qui ont été modifiés par rapport à la base - n'est pas détectée ou corrigée.
8.10 - Suppression de l'Information (Nouveau en 2022)
Objet : Supprimer les informations stockées dans les systèmes d'information lorsqu'elles ne sont plus nécessaires.
Échec courant : Les calendriers de conservation sont définis mais la suppression n'est pas opérationnalisée.
8.11 - Masquage des Données (Nouveau en 2022)
Objet : Utiliser le masquage des données conformément aux politiques et réglementations applicables.
Échec courant : Les données de production sont utilisées dans les environnements de développement et de test sans masquage.
8.12 - Prévention des Fuites de Données (Nouveau en 2022)
Objet : Appliquer des mesures de prévention des fuites de données aux systèmes traitant des informations sensibles.
Échec courant : Les outils DLP sont déployés mais en mode surveillance plutôt qu'en mode blocage.
8.13 - Sauvegarde de l'Information
Objet : Maintenir et tester régulièrement les copies de sauvegarde.
Pertinence surface d'attaque : L'intégrité de la sauvegarde est le principal déterminant des résultats de récupération après ransomware.
Échec courant : Les sauvegardes sont effectuées mais jamais testées. Les sauvegardes ne sont pas isolées de l'environnement de production - un ransomware chiffre les sauvegardes avec les données de production. Les objectifs de délai de récupération et de point de récupération sont définis mais n'ont jamais été validés.
8.14 - Redondance des Installations de Traitement de l'Information
Objet : Implémenter la redondance dans les installations de traitement de l'information.
Échec courant : La redondance est implémentée pour les systèmes primaires mais pas pour les systèmes de sécurité - SIEM, fournisseurs d'identité, systèmes MFA.
8.15 - Journalisation
Objet : Produire, stocker, protéger et analyser les journaux d'activités.
Pertinence surface d'attaque : Les journaux sont le principal enregistrement légal des événements de sécurité.
Échec courant : La couverture des journaux est incomplète. La conservation des journaux est trop courte. Les journaux ne sont pas centralisés. L'intégrité des journaux n'est pas protégée.
8.16 - Activités de Surveillance (Nouveau en 2022)
Objet : Surveiller les réseaux, systèmes et applications pour détecter les comportements anormaux.
Échec courant : La surveillance est basée sur des alertes plutôt que sur le comportement. La fatigue d'alerte fait que les incidents réels sont manqués parmi le bruit.
8.17 - Synchronisation de l'Horloge
Objet : Synchroniser les horloges des systèmes de traitement de l'information.
Échec courant : La corrélation des journaux lors de l'investigation d'incident dépend de timestamps précis à travers tous les systèmes.
8.18 - Utilisation de Programmes Utilitaires Privilégiés
Objet : Contrôler et restreindre l'utilisation des programmes utilitaires capables de contourner les contrôles système.
Échec courant : Des outils système puissants (outils de vidage de mots de passe, scanners réseau, outils d'accès distant) sont disponibles pour tous les utilisateurs ayant un accès administratif.
8.19 - Installation de Logiciels sur les Systèmes Opérationnels
Objet : Implémenter des procédures sécurisées pour l'installation de logiciels.
Échec courant : Les utilisateurs ont des droits d'administrateur local qui leur permettent d'installer des logiciels sans approbation IT.
8.20 - Sécurité des Réseaux
Objet : Sécuriser les réseaux et les appareils réseau.
Échec courant : La segmentation réseau est implémentée au périmètre mais pas en interne. Le trafic est-ouest (entre les systèmes internes) n'est pas surveillé.
8.21 - Sécurité des Services Réseau
Objet : Identifier, implémenter et surveiller les mécanismes de sécurité pour les services réseau.
Échec courant : Les fournisseurs de services réseau tiers ne sont pas tenus de démontrer leur conformité continue aux exigences de sécurité.
8.22 - Ségrégation des Réseaux
Objet : Segmenter les groupes de services d'information, d'utilisateurs et de systèmes au sein des réseaux.
Pertinence surface d'attaque : La segmentation réseau est l'un des contrôles les plus efficaces pour limiter le rayon de souffle d'une attaque réussie.
Échec courant : Les environnements de développement, test et production ne sont pas correctement séparés. Les réseaux de technologie opérationnelle (OT) et IT ne sont pas segmentés.
8.23 - Filtrage Web (Nouveau en 2022)
Objet : Gérer l'accès aux sites Web externes pour réduire l'exposition aux contenus malveillants.
Échec courant : Le filtrage Web est déployé mais des exceptions sont accordées libéralement. L'inspection SSL n'est pas implémentée.
8.24 - Utilisation de la Cryptographie
Objet : Définir et implémenter des règles pour l'utilisation efficace de la cryptographie.
Échec courant : Les normes cryptographiques sont définies mais non appliquées - les systèmes hérités utilisent des algorithmes obsolètes (MD5, SHA-1, DES, RC4).
8.25 - Cycle de Développement Sécurisé
Objet : Établir des règles pour le développement sécurisé de logiciels et de systèmes.
Pertinence surface d'attaque : La couche applicative est la surface d'attaque la plus fréquemment ciblée pour les systèmes accessibles sur le Web. L'injection SQL, les scripts intersites, la désérialisation non sécurisée sont tous évitables grâce à des pratiques de développement sécurisées.
Échec courant : Les tests de sécurité sont effectués en fin de cycle de développement plutôt que tout au long.
8.26 - Exigences de Sécurité des Applications
Objet : Identifier, spécifier et approuver les exigences de sécurité de l'information lors du développement ou de l'acquisition d'applications.
Échec courant : Les exigences de sécurité sont génériques plutôt que spécifiques à l'application.
8.27 - Architecture et Principes d'Ingénierie Sécurisés du Système
Objet : Établir, documenter, maintenir et appliquer des principes pour l'ingénierie de systèmes sécurisés.
Échec courant : Les principes d'architecture de sécurité existent au niveau stratégique mais ne sont pas traduits en guide d'ingénierie pratique.
8.28 - Codage Sécurisé (Nouveau en 2022)
Objet : Appliquer des principes de codage sécurisé au développement logiciel.
Échec courant : La formation au codage sécurisé est fournie lors de l'intégration mais n'est pas actualisée. Les outils d'analyse statique sont disponibles mais pas intégrés dans le pipeline de développement.
8.29 - Tests de Sécurité dans le Développement et l'Acceptation
Objet : Définir et implémenter des processus de tests de sécurité.
Échec courant : Les tests de sécurité consistent en un seul test de pénétration avant les versions majeures plutôt qu'une activité continue.
8.30 - Développement Externalisé
Objet : Diriger, surveiller et réviser les activités liées au développement logiciel externalisé.
Échec courant : Le code produit par des développeurs externalisés n'est pas examiné pour les problèmes de sécurité avant l'intégration.
8.31 - Séparation des Environnements de Développement, Test et Production
Objet : Séparer les environnements de développement, test et production.
Échec courant : Des données de production sont utilisées dans des environnements de test sans assainissement.
8.32 - Gestion des Changements
Objet : Appliquer des procédures de gestion des changements.
Échec courant : La gestion des changements est appliquée aux changements planifiés mais pas aux changements d'urgence.
8.33 - Informations de Test
Objet : Sélectionner, protéger et gérer de manière appropriée les informations de test.
Échec courant : Des données de production - données personnelles des clients, enregistrements financiers - sont utilisées dans les environnements de test et de développement sans anonymisation. Ceci constitue à la fois un défaut de contrôle de sécurité et, là où des données personnelles sont impliquées, une violation du RGPD.
8.34 - Protection des Systèmes d'Information Lors des Tests d'Audit
Objet : Planifier et convenir des tests d'audit impliquant l'évaluation des systèmes opérationnels.
Échec courant : Les outils d'audit utilisés dans les environnements de production ne sont pas contrôlés.
Partie 6 - Mettre l'Annexe A en Pratique
6.1 La Séquence d'Implémentation des Contrôles
Les contrôles fondamentaux d'abord : Certains contrôles de l'Annexe A sont des prérequis pour d'autres. L'inventaire des actifs (5.9) doit exister avant que l'évaluation des risques puisse être significative. La politique de contrôle d'accès (5.15) doit être définie avant que les droits d'accès (5.18) puissent être provisionnés correctement.
Les contrôles à haute visibilité tôt : Les contrôles visibles aux employés - la politique de sécurité de l'information, la politique d'utilisation acceptable, le programme de sensibilisation - ont un impact organisationnel large.
Les contrôles à haut risque de manière urgente : Si l'évaluation des risques identifie des risques critiques, les contrôles qui les traitent ne font pas partie d'un plan d'implémentation par phases - ce sont des éléments de remédiation urgents.
6.2 Le Cadre de Preuve des Contrôles
Pour chaque contrôle implémenté, le SMSI doit être en mesure de produire des preuves que le contrôle existe, est opérationnel et est efficace.
| Type de Preuve | Exemples |
|---|---|
| Politique / procédure | Document de politique, enregistrements de signature d'accusé de réception |
| Configuration technique | Captures d'écran du système, exports de configuration, rapports d'outils |
| Enregistrements de processus | Procès-verbaux de réunion, enregistrements d'approbation, journaux de révision |
| Enregistrements de formation | Enregistrements de complétion, résultats d'évaluation |
| Enregistrements de tests | Rapports de tests de pénétration, résultats d'analyse de vulnérabilités, enregistrements de tests de sauvegarde |
| Enregistrements de surveillance | Extraits de journaux, enregistrements d'alertes, enregistrements d'incidents |
Résumé : Ce que le Chapitre 4 a Établi
L'Annexe A n'est pas une liste de contrôle. C'est un ensemble de référence structuré de 93 contrôles répartis en quatre thèmes - Organisationnel, Humain, Physique et Technologique - qui représente le savoir cumulé de la communauté des normes sur la façon dont les organisations devraient protéger l'information.
Chaque contrôle a un objet, une dimension de surface d'attaque et un mode d'échec caractéristique. Comprendre les trois - pas seulement l'objet, mais comment il échoue typiquement - c'est ce qui sépare les praticiens qui implémentent des contrôles efficacement de ceux qui les implémentent formellement.
Les 11 nouveaux contrôles dans la version 2022 - renseignement sur les menaces, services cloud, gestion de la configuration, suppression de l'information, masquage des données, prévention des fuites de données, surveillance de la sécurité physique, activités de surveillance, filtrage web, codage sécurisé et préparation des TIC pour la continuité des activités - traitent collectivement les lacunes les plus significatives de la version 2013.
Suivant : Chapitre 5 - L'Architecture de Documentation : Ce qui Doit Exister, Ce qui Doit Être Prouvé et Ce qui Tue les Certifications
© ISO 27001 Wiki - Pour les RSSI, Analystes de Sécurité et Professionnels GRC