Skip to main content

Opérer le SMSI à l'Échelle : Gestion des Actifs, Contrôle des Changements, Risque Fournisseurs et Réponse aux Incidents en Mouvement

"En théorie, il n'y a pas de différence entre la théorie et la pratique. En pratique, il y en a une."

  • Yogi Berra

Introduction : L'Écart Entre Conception et Opération​

Chaque SMSI a l'air bon sur le papier. Les politiques sont cohérentes. Le registre des risques est réfléchi. La DdA est complète. L'architecture de documentation est solide. Et puis l'organisation se met en marche - les systèmes changent, les fournisseurs sont intégrés, des incidents se produisent, des employés arrivent et partent, de nouvelles réglementations émergent - et le SMSI prouve soit qu'il est opérationnel, soit qu'il se révèle être un ensemble de documents décrivant une organisation qui n'existe que dans la bibliothèque de politiques.

Le SMSI opérationnel est celui qui fonctionne pendant la réalité désordonnée et continue de la vie organisationnelle. C'est celui où la gestion des actifs suit le rythme de l'expansion cloud et du shadow IT. Où le processus de contrôle des changements est utilisé par les ingénieurs parce qu'il est utile, pas contourné parce qu'il est contraignant. Où la gestion des risques fournisseurs est continue, pas une case à cocher à la signature du contrat.

Ce chapitre traite de cette réalité opérationnelle. Il couvre les quatre domaines où l'écart entre la conception du SMSI et son opération est le plus large, le plus conséquent et le plus souvent exploité.

Partie 1 - La Gestion des Actifs en Mouvement​

1.1 Pourquoi la Gestion des Actifs N'est Jamais Terminée​

L'inventaire des actifs établi lors de la mise en place du SMSI (chapitre 3) était précis à un moment donné. Dès qu'il a été complété, il a commencé à diverger de la réalité. Comprendre pourquoi cette dérive est inévitable est le point de départ pour traiter la gestion des actifs comme un processus continu.

Vélocité de déploiement technologique. Dans les organisations avec des programmes de développement actifs, une infrastructure cloud-native ou une acquisition IT distribuée, de nouveaux actifs voient le jour plus rapidement que les processus d'inventaire manuels ne peuvent les capturer.

Le problème du shadow IT à l'échelle. Le shadow IT - technologie déployée ou utilisée en dehors du processus formel de gouvernance IT - est une conséquence prévisible de l'écart entre les besoins des utilisateurs et la capacité de livraison IT.

Changements d'état des actifs. Des actifs dans l'inventaire peuvent changer d'une manière qui modifie leur profil de risque - un serveur migré des locaux vers le cloud, une base de données qui commence à stocker une nouvelle catégorie de données.

Dynamique des actifs tiers. Les actifs détenus par des tiers changent continuellement à mesure que ces fournisseurs mettent à jour leur infrastructure, leurs politiques et leurs configurations de service.

1.2 Découverte Continue des Actifs : La Dimension Technique​

La gestion opérationnelle des actifs nécessite des mécanismes techniques qui découvrent et inventorient continuellement les actifs.

Analyse de découverte réseau. Des analyses automatisées régulières de l'environnement réseau identifient les appareils connectés, les services en cours d'exécution et les ports ouverts. Des outils commerciaux comme Qualys, Tenable ou Rapid7, ou des outils open source comme Nmap, fournissent une image continuellement mise à jour de ce qui est sur le réseau.

Gestion des actifs cloud. Les fournisseurs de services cloud proposent des services d'inventaire natifs - AWS Config, Azure Resource Graph, GCP Cloud Asset Inventory - qui énumèrent toutes les ressources dans l'environnement cloud. Les environnements multi-cloud nécessitent soit les outils natifs de chaque fournisseur, soit une plateforme de gestion de la posture de sécurité cloud (CSPM) tierce.

Découverte SaaS. Les outils de courtier de sécurité d'accès cloud (CASB) et les plateformes de gestion SaaS analysent le trafic réseau, les autorisations OAuth et les journaux du fournisseur d'identité pour identifier toutes les applications SaaS utilisées.

Découverte et classification des données. Les outils de découverte de données analysent les systèmes de stockage, les partages de fichiers, les bases de données et le stockage cloud pour identifier où se trouvent les données sensibles.

1.3 Le Processus du Cycle de Vie des Actifs​

Acquisition et intégration : Les nouveaux actifs devraient entrer dans l'environnement via un processus qui comprend une évaluation de sécurité avant déploiement.

Classification et attribution de propriété : Chaque actif doit être classifié selon le schéma de classification de l'information et attribué à un propriétaire responsable de sa sécurité.

Surveillance opérationnelle : Une fois dans l'environnement, les actifs doivent être surveillés pour la conformité de sécurité - dérive de configuration, exposition aux vulnérabilités, modifications non autorisées.

Gestion des changements : Les changements apportés aux actifs doivent passer par le processus de gestion des changements.

Décommissionnement et élimination : Lors de la retraite des actifs, le processus doit traiter la sécurité de l'information - suppression sécurisée des données, révocation des permissions d'accès, mise à jour du registre des actifs.

1.4 Le Cycle de Vie de la Classification de l'Information​

La classification de l'information n'est pas un exercice d'étiquetage unique. L'information évolue en sensibilité au fil du temps.

Dérive de classification vers le bas : L'information qui était très sensible à la création peut devenir publique ou perdre sa sensibilité avec le temps. Un plan stratégique confidentiel devient disponible une fois la stratégie annoncée publiquement.

Dérive de classification vers le haut : L'information créée comme routinière peut devenir sensible à mesure que son contexte change.

Déclencheurs de révision de classification : La classification doit être révisée quand l'information est partagée au-delà de son audience initiale, quand son statut réglementaire change, ou quand sa sensibilité temporelle a expiré.

Partie 2 - Le Contrôle des Changements comme Contrôle de Sécurité​

2.1 Pourquoi le Changement est l'Activité Routinière la Plus Dangereuse​

La majorité des incidents de sécurité significatifs non causés par une attaque externe sont causés par un changement - une modification de configuration qui ouvre par inadvertance un port de pare-feu, une mise à jour logicielle qui supprime un contrôle de sécurité, une migration de base de données qui expose des données via une nouvelle interface.

Le contrôle des changements ISO 27001 (Annexe A 8.32) exige que les changements apportés aux équipements et systèmes de traitement de l'information suivent un processus documenté. L'objectif n'est pas bureaucratique - c'est de s'assurer que les implications de sécurité sont évaluées avant que les changements soient effectués, que les changements sont testés avant d'être déployés en production.

2.2 Le Processus de Gestion des Changements Intégrant la Sécurité​

Un processus efficace de gestion des changements pour la sécurité a cinq étapes :

Demande et classification : Chaque changement doit être formellement demandé avec une description de ce qui changera, pourquoi le changement est nécessaire et quel est l'impact attendu. Les changements doivent être classifiés par niveau de risque - changements standard (faible risque, pré-approuvés), changements normaux (nécessitant évaluation et approbation) et changements d'urgence.

Évaluation de l'impact sur la sécurité : Avant qu'un changement soit approuvé, ses implications de sécurité doivent être évaluées - quels contrôles ce changement affecte-t-il ? Change-t-il la surface d'attaque ?

Tests : Les changements doivent être testés dans un environnement hors production avant le déploiement en production.

Déploiement et vérification : Après le déploiement, le changement doit être vérifié comme ayant été implémenté tel qu'intentionné et ayant atteint le résultat attendu.

Revue et enregistrement post-changement : L'enregistrement du changement doit être mis à jour avec le résultat.

2.3 Changements d'Urgence : Le Risque de Sécurité dans le Processus d'Exception​

Les changements d'urgence méritent une attention particulière car ils sont simultanément les changements les plus susceptibles d'introduire des vulnérabilités de sécurité et ceux les moins susceptibles de passer par un examen de sécurité adéquat.

Niveau minimal d'approbation : Même les changements d'urgence doivent nécessiter l'approbation de quelqu'un ayant l'autorité d'accepter le risque associé.

Revue rétrospective obligatoire : Chaque changement d'urgence doit faire l'objet d'une revue rétrospective obligatoire dans un délai défini - généralement 5 jours ouvrables.

Journalisation et piste d'audit : Les changements d'urgence doivent être enregistrés aussi soigneusement que les changements planifiés.

2.4 Gestion de la Configuration et Contrôle des Changements​

La gestion de la configuration - maintenir des configurations documentées et vérifiées pour tous les systèmes - est la discipline complémentaire au contrôle des changements. Là où le contrôle des changements contrôle les changements intentionnels, la gestion de la configuration détecte les changements non intentionnels.

La révision 2022 a ajouté la gestion de la configuration comme contrôle explicite (Annexe A 8.9).

Un programme opérationnel de gestion de la configuration comprend :

Des bases de référence de sécurité définies. Pour chaque catégorie de système, une base de référence documentée définit la configuration requise. Les Benchmarks CIS, les guides de durcissement des fournisseurs sont des sources communes.

L'analyse de conformité automatisée. Comparaison automatisée régulière des configurations réelles des systèmes avec la base approuvée, avec alertes en cas d'écarts. Dans les environnements cloud, les outils CSPM remplissent cette fonction.

La vérification de configuration déclenchée par les changements.

La réponse à la dérive de configuration. Un processus défini pour répondre quand une dérive de configuration est détectée.

Partie 3 - La Gestion des Risques Fournisseurs comme Discipline Continue​

3.1 Le Cycle de Vie des Risques Fournisseurs​

L'évolution la plus significative dans la gestion des risques fournisseurs ISO 27001 est le passage de la diligence raisonnable au moment du contrat à la gestion continue des risques fournisseurs.

L'approche traditionnelle était : évaluer le fournisseur à l'achat, inclure des exigences de sécurité dans le contrat, classer le contrat, et ne traiter à nouveau de la sécurité des fournisseurs que si un incident se produit. Cette approche était insuffisante en 2013. En 2024, elle est professionnellement indéfendable.

Le cycle de vie de la gestion continue comprend :

Évaluation à l'intégration : Avant qu'une nouvelle relation fournisseur commence, le fournisseur est évalué selon les exigences de sécurité appropriées au risque qu'il représente.

Exigences contractuelles : Les éléments contractuels clés pour la sécurité sont :

  • Exigences minimales de contrôle de sécurité
  • Dispositions de droit d'audit
  • Exigences de notification et d'approbation pour les sous-traitants
  • Exigences de notification d'incidents
  • Exigences de retour et suppression des données à la fin du contrat
  • Exigences de continuité des activités

Surveillance continue : Surveillance du renseignement sur les menaces pour les incidents chez le fournisseur, surveillance de l'intelligence externe - services de notation de sécurité, bases de données de violations publiques.

Révision périodique : À des intervalles définis - au moins annuellement, plus fréquemment pour les fournisseurs à haut risque.

Sortie et fin de relation : Lors de la fin d'une relation fournisseur, les aspects de sécurité de la sortie doivent être gérés - retour et suppression vérifiée des données, révocation des accès, rotation des identifiants.

3.2 Le Cadre de Hiérarchisation des Fournisseurs​

Niveau 1 - Fournisseurs Critiques : Définition : Fournisseurs avec un accès privilégié aux systèmes de production, fournisseurs qui traitent des volumes significatifs de données personnelles sensibles, fournisseurs dont la défaillance ou la compromission impacterait directement la capacité opérationnelle de l'organisation. Exemples : Prestataires de services managés avec accès administratif à l'infrastructure ; fournisseurs cloud hébergeant des systèmes centraux ; processeurs de paiement. Exigences de gestion : Évaluation complète à l'intégration ; exigences contractuelles avec droits d'audit ; révisions de sécurité trimestrielles ou semestrielles.

Niveau 2 - Fournisseurs à Haut Risque : Définition : Fournisseurs avec accès aux systèmes ou données organisationnels sans accès privilégié. Exemples : Fournisseurs SaaS traitant des données organisationnelles. Exigences de gestion : Évaluation par questionnaire de sécurité à l'intégration ; clauses contractuelles standard ; révision annuelle.

Niveau 3 - Fournisseurs Standard : Définition : Fournisseurs qui fournissent des biens ou services sans accès aux systèmes d'information organisationnels. Exemples : Fournitures de bureau, restauration, services informatiques non sensibles. Exigences de gestion : Conditions contractuelles standard ; pas d'évaluation de sécurité spécifique requise.

3.3 La Revue des Fournisseurs Critiques : Ce qu'Elle Doit Couvrir​

Revue du profil d'accès : Quel accès ce fournisseur possède-t-il actuellement ? Son profil d'accès a-t-il changé ?

Revue de l'historique des incidents : Le fournisseur a-t-il connu des incidents de sécurité depuis la dernière revue ?

Changements de sous-traitants : Le fournisseur a-t-il engagé de nouveaux sous-traitants depuis la dernière revue ?

Statut de certification et conformité : La certification de sécurité du fournisseur est-elle à jour ?

Stabilité financière et opérationnelle : Un fournisseur en difficulté financière peut être moins capable de maintenir ses investissements de sécurité.

Revue de conformité contractuelle : Le fournisseur respecte-t-il les exigences de sécurité définies dans le contrat ?

Évaluation des changements de service : Le fournisseur a-t-il apporté des changements matériels à la façon dont il fournit ses services ?

3.4 Risque de Quatrième Partie : Les Fournisseurs des Fournisseurs​

L'attaque SolarWinds a démontré clairement que les programmes de gestion des risques tiers qui se concentrent exclusivement sur les fournisseurs directs sont structurellement incomplets. L'attaque a été conduite contre le pipeline de build de SolarWinds - une relation de quatrième partie du point de vue des milliers d'organisations finalement affectées.

Approches pratiques pour la gestion des risques de quatrième partie :

Répercussion contractuelle : Exiger dans les contrats fournisseurs que le fournisseur applique des exigences de sécurité équivalentes à ses sous-traitants.

Notification des sous-traitants matériels : Exiger que les fournisseurs identifient leurs sous-traitants matériels - ceux ayant accès aux données de l'organisation - et notifient tout changement.

Analyse de composition logicielle : Pour le risque de la chaîne d'approvisionnement logicielle, des outils automatisés qui analysent les composants logiciels, bibliothèques et outils de build peuvent identifier les risques de dépendance.

Surveillance du renseignement sur les menaces : Surveiller les sources de renseignement sur les menaces pour les incidents affectant les grands fournisseurs de logiciels et plateformes d'infrastructure couramment utilisés.

Partie 4 - La Réponse aux Incidents en Mouvement​

4.1 Le Modèle de Capacité de Réponse aux Incidents​

Une capacité de réponse aux incidents n'est pas un document. C'est une combinaison de personnes préparées, de processus testés, de technologie appropriée et de jugement exercé qui permet à une organisation de détecter, contenir, enquêter, corriger et tirer des enseignements des incidents de sécurité.

La plupart des organisations ont le document. Moins ont la capacité. L'écart entre les deux est l'écart de préparation - la différence entre savoir ce qui devrait se passer quand un incident se produit et être capable de l'exécuter sous pression quand cela arrive.

4.2 Détection des Incidents : La Première et Difficile Étape​

La fatigue d'alertes est le principal mode de défaillance de la détection. Les outils de surveillance de sécurité génèrent des alertes en volumes qui dépassent souvent la capacité de l'équipe à les enquêter.

Le problème de la menace inconnue. La détection basée sur les signatures ne détecte pas les nouvelles attaques, les techniques de "living-off-the-land" qui utilisent des outils légitimes.

Les lacunes de visibilité. La plupart des organisations ont une meilleure visibilité sur leur infrastructure sur site que sur leurs environnements cloud.

Le défi de détection des menaces internes. Les initiés ont un accès légitime aux systèmes et données ; leur comportement est attendu et donc moins susceptible de déclencher la détection d'anomalies.

4.3 Les Premières 24 Heures : Guide du Praticien​

Heures 0–1 : Détection et triage initial

Questions de triage :

  • Y a-t-il des preuves crédibles de compromission, ou s'agit-il d'un faux positif ?
  • Si compromission, quel est le périmètre ?
  • L'attaque est-elle en cours ou a-t-elle pris fin ?
  • Y a-t-il une menace immédiate pour les opérations critiques ?

Heures 1–4 : Confinement et escalade

Contenir la menace : Empêcher l'attaquant d'étendre son accès. Les options de confinement vont de l'isolation des systèmes affectés aux interventions plus ciblées.

Préserver les preuves : Avant d'apporter des modifications aux systèmes affectés, capturer des preuves légales - images de systèmes, captures mémoire, extraits de journaux. La tension entre l'urgence du confinement et la préservation des preuves est l'un des défis pratiques les plus difficiles.

Escalader de manière appropriée : Qui doit être informé, et que doivent-ils savoir ? L'escalade interne doit être guidée par la classification de l'incident et des critères d'escalade prédéfinis.

Heures 4–12 : Investigation et communication

Détermination du périmètre : À quels systèmes a-t-on accédé ? Quelles données ont pu être exposées ?

Horloge de notification réglementaire : Si l'incident implique des données personnelles, l'horloge de notification des 72 heures du RGPD commence à courir dès que l'organisation prend conscience qu'une violation de données personnelles s'est probablement produite.

Gestion des communications : Qui communiquera avec les régulateurs, clients, forces de l'ordre et médias ?

Heures 12–24 : Remédiation et récupération

Éradication : Supprimer la présence de l'attaquant de l'environnement - logiciels malveillants, portes dérobées, comptes non autorisés. L'éradication partielle qui laisse à l'attaquant un chemin de retour dans l'environnement entraîne une re-compromission.

Récupération : Restaurer les systèmes affectés à l'état opérationnel, en vérifiant les contrôles de sécurité avant de se reconnecter aux réseaux de production.

4.4 Notification Réglementaire : La Dimension Conformité de la Réponse aux Incidents​

Notification des violations RGPD :

  • À l'autorité de contrôle : Dans les 72 heures suivant la prise de connaissance d'une violation de données personnelles. La notification doit inclure la nature de la violation, les catégories et le nombre approximatif de personnes concernées, les mesures prises ou proposées.
  • Aux personnes affectées : Sans délai indu lorsque la violation est susceptible d'entraîner un risque élevé pour les droits et libertés des personnes.

Défi pratique : Les organisations qui tentent de compléter leur investigation avant de notifier manquent généralement le délai. L'approche correcte est de notifier tôt avec les informations disponibles.

Notification des incidents NIS2 (pour les entités essentielles et importantes) :

  • Notification précoce : Dans les 24 heures suivant la prise de connaissance d'un incident significatif.
  • Notification d'incident : Dans les 72 heures - mise à jour avec évaluation initiale.
  • Rapport final : Dans un mois après la soumission de la notification d'incident.

Classification et signalement des incidents DORA (pour les entités financières) : DORA introduit un régime de signalement en trois étapes pour les incidents TIC majeurs, avec notification initiale dans les 4 heures suivant la classification comme majeur, rapport intermédiaire dans les 72 heures et rapport final dans un mois.

4.5 La Revue Post-Incident : Convertir les Incidents en Améliorations​

Une revue post-incident efficace répond à cinq questions :

Que s'est-il passé ? Une reconstruction factuelle de la chronologie de l'incident.

Pourquoi cela s'est-il produit ? Analyse des causes profondes - pas seulement la cause immédiate mais les facteurs organisationnels et de processus sous-jacents.

Comment était la réponse ? Une évaluation honnête de l'efficacité de la réponse.

Quels risques cet incident a-t-il révélés ? Le registre des risques doit être mis à jour pour refléter ce que l'incident a révélé.

Que va-t-il changer ? Des actions correctives spécifiques, attribuées, délimitées dans le temps qui traitent les causes profondes identifiées.

Partie 5 - Le Calendrier Opérationnel du SMSI​

5.1 Le Rythme de la Gestion de la Sécurité Opérationnelle​

Un SMSI qui fonctionne bien a un rythme - un calendrier défini d'activités récurrentes qui maintient le système de management à jour, les enregistrements de preuves alimentés, et la posture de sécurité continuellement évaluée et ajustée.

5.2 Activités Opérationnelles Hebdomadaires​

Revue de la surveillance de sécurité : Révision des alertes SIEM, des flux de renseignements sur les menaces et des rapports d'événements anormaux.

Revue des analyses de vulnérabilités : Révision des résultats automatisés des analyses de vulnérabilités pour les constatations de gravité critique et élevée.

Attribution et révocation des accès : Traitement des demandes d'accès et des révocations d'accès reçues pendant la semaine.

Revue de la gestion des changements : Revue des demandes de changement soumises pendant la semaine pour l'impact sur la sécurité.

5.3 Activités Opérationnelles Mensuelles​

Rapport d'indicateurs de sécurité : Compilation et distribution du rapport mensuel d'indicateurs de sécurité à la direction. Les indicateurs principaux doivent inclure : délai moyen de détection (MTTD), délai moyen de réponse (MTTR), statistiques de gestion des vulnérabilités, taux de complétion des révisions d'accès, taux de complétion de la formation.

Surveillance de la sécurité des fournisseurs : Revue des sources de renseignements sur les menaces pour les incidents chez les fournisseurs clés.

Mise à jour du registre des risques : Revue du registre des risques pour tout changement intervenu pendant le mois.

Revue de la conformité aux correctifs : Revue de l'état de conformité aux correctifs sur tous les systèmes dans le périmètre.

5.4 Activités Opérationnelles Trimestrielles​

Briefing de sécurité à la direction : Présentation d'un briefing de sécurité trimestriel à l'équipe dirigeante.

Cycle de révision des accès : Conduite d'une revue formelle des droits d'accès pour les systèmes à haute valeur et les données sensibles.

Simulation de phishing : Conduite d'un exercice de simulation de phishing contre un échantillon représentatif du personnel.

Revue des fournisseurs de Niveau 1 : Conduite de revues de sécurité trimestrielles formelles pour les fournisseurs de Niveau 1 (critiques).

Test de continuité des activités : Conduite d'au moins un test de continuité des activités ou de reprise après sinistre par trimestre.

5.5 Activités Opérationnelles Annuelles​

Actualisation complète de l'évaluation des risques : Conduite d'une revue complète du registre des risques.

Programme d'audit interne : Exécution du programme annuel d'audit interne, couvrant tous les aspects du SMSI.

Revue de direction : Conduite de la revue de direction formelle annuelle couvrant toutes les entrées requises par la Clause 9.3.

Cycle de révision des politiques : Revue de toutes les politiques du SMSI.

Révision de la DdA : Revue de la Déclaration d'Applicabilité pour sa mise à jour.

Revue des fournisseurs - portefeuille complet : Conduite d'une revue annuelle du portefeuille complet de fournisseurs.

Test de pénétration : Conduite d'un test de pénétration annuel de l'environnement dans le périmètre.

Actualisation de la formation de sensibilisation : Mise à jour du contenu de la formation annuelle de sensibilisation à la sécurité.

Partie 6 - Mettre à l'Échelle le SMSI : Taille, Complexité et Contraintes de Ressources​

6.1 Le SMSI des Petites Organisations​

Risque de concentration dans les rôles de sécurité. Dans les petites organisations, une seule personne peut être responsable de la majorité des activités du SMSI. Cela crée un risque de concentration : quand cette personne est indisponible, les activités du SMSI s'arrêtent.

Atténuations pratiques :

  • Documenter tous les processus du SMSI à un niveau de granularité suffisant
  • Utiliser des auditeurs externes pour la fonction d'audit interne
  • Identifier une personne responsable secondaire pour chaque activité critique du SMSI
  • Automatiser ce qui peut l'être

Implémentation de contrôles priorisée par les ressources. Les petites organisations ne peuvent pas implémenter chaque contrôle à la même profondeur que les grandes. L'évaluation des risques doit conduire une priorisation explicite.

6.2 Le SMSI d'Entreprise : Gérer la Complexité à Grande Échelle​

Le modèle de SMSI fédéré. De nombreuses grandes organisations exploitent un SMSI fédéré - un cadre SMSI central qui définit des normes communes, des exigences minimales et des processus de gouvernance, avec des SMSI subsidiaires ou d'unités commerciales.

Gouvernance inter-fonctionnelle. Un SMSI d'entreprise nécessite des structures de gouvernance qui réunissent les diverses fonctions ayant des responsabilités de sécurité.

Cohérence des politiques et adaptation locale. Les politiques de sécurité d'entreprise doivent être cohérentes dans leurs exigences tout en permettant une flexibilité opérationnelle dans la mise en œuvre.

Agrégation des indicateurs. Le reporting des indicateurs de sécurité d'entreprise nécessite l'agrégation de données de sécurité provenant de toute l'organisation.

Résumé : Ce que le Chapitre 6 a Établi​

Le SMSI opérationnel est l'endroit où la politique de sécurité rencontre la réalité organisationnelle.

La gestion des actifs n'est jamais terminée. Les mécanismes de découverte continue, les disciplines de gestion du cycle de vie et la maintenance de la classification sont les pratiques opérationnelles qui maintiennent le registre des actifs à jour.

Le contrôle des changements est l'un des contrôles de sécurité les plus sous-estimés. Les changements introduisent de l'incertitude dans la posture de sécurité ; le contrôle des changements gère cette incertitude.

La gestion des risques fournisseurs a été définitivement transformée par le paysage des attaques de la chaîne d'approvisionnement. La surveillance continue, la gestion des risques par niveaux et les mécanismes contractuels pour la visibilité sur les relations de quatrième partie sont les exigences opérationnelles d'un programme mature.

La réponse aux incidents est une capacité, pas un document. L'écart entre avoir un plan et pouvoir l'exécuter efficacement sous pression se comble uniquement par la pratique.

Le calendrier opérationnel est le mécanisme pratique qui transforme le SMSI d'un artefact de certification en un système de management de sécurité vivant.

Suivant : Chapitre 7 - Mesurer ce qui Compte : KPIs, Programmes d'Audit Interne, Revue de Direction et Boucles d'Amélioration Continue

© ISO 27001 Wiki - Pour les RSSI, Analystes de Sécurité et Professionnels GRC