Qu'est-ce qu'un SMSI ? Relier le travail de sécurité aux décisions de l'entreprise

Le travail de sécurité peut sembler intense sans être coordonné. L'ingénierie corrige les systèmes, les RH gèrent les départs, les achats évaluent les fournisseurs et la direction approuve les exceptions. Un système de management de la sécurité de l'information relie ces activités à des objectifs communs et à un processus de décision explicite.

Pour un dirigeant, la question importante n'est pas de savoir si l'entreprise dispose de suffisamment de documents de sécurité. Elle est de savoir si la direction peut expliquer ce qui doit être protégé, quels risques comptent, qui est responsable et pourquoi le niveau de protection actuel est acceptable. Un SMSI rend ces réponses reproductibles à mesure que l'entreprise évolue.

Ce qu'un SMSI gère réellement

Un système de management de la sécurité de l'information est le dispositif organisationnel qui permet de gérer les risques liés à la sécurité de l'information. Il comprend des responsabilités, des politiques, des processus, des ressources, des mesures de sécurité et des évaluations. Un logiciel peut le soutenir, mais le logiciel n'est pas le système. Une bibliothèque documentaire peut le décrire, mais les documents seuls ne démontrent pas qu'il fonctionne.

Sa finalité est de protéger trois propriétés de l'information :

• Confidentialité : l'information n'est accessible qu'aux personnes et systèmes autorisés.
• Intégrité : l'information reste exacte, complète et protégée contre toute modification inappropriée.
• Disponibilité : les utilisateurs autorisés peuvent obtenir l'information et utiliser les services associés quand ils en ont besoin.

Ces propriétés se traduisent en enjeux pour l'entreprise. Des données clients exposées peuvent entamer la confiance et créer des obligations légales. Des instructions de paiement erronées peuvent causer une perte financière. Une plateforme de support indisponible peut empêcher l'entreprise de tenir ses engagements envers ses clients.

L'ISO/IEC 27001 fournit des exigences reconnues pour un SMSI doté d'un périmètre défini. Les articles 4 à 10 traitent du contexte de l'organisation, du leadership, de la planification, du support, du fonctionnement, de l'évaluation des performances et de l'amélioration. Une organisation peut développer et faire fonctionner un SMSI avant de viser la certification.

Le système de management fait le lien entre les mesures de protection individuelles et les décisions de l'entreprise. Une sauvegarde est une mesure de sécurité. Décider de ce qui doit pouvoir être restauré, financer la capacité de reprise, la tester et agir lorsque les tests échouent relève du système de management.

Pourquoi la direction a besoin de ces liens

Des décisions de sécurité sont déjà prises dans toute l'entreprise, qu'elle parle ou non de SMSI. Quelqu'un choisit un fournisseur SaaS, approuve un accès à privilèges, accepte un correctif retardé ou s'engage sur une exigence de reprise envers un client. Sans processus partagé, ces décisions peuvent reposer sur des hypothèses différentes et ne laisser personne responsable de leur effet combiné.

Un SMSI donne à la direction une base pour hiérarchiser des ressources limitées. Il aide aussi les équipes à répondre aux questions des clients à partir d'enregistrements tenus à jour, plutôt que de reconstituer leurs pratiques à chaque revue commerciale. Cela ne garantit pas l'issue d'un appel d'offres ; cela rend les affirmations sous-jacentes mieux étayées.

Les liens doivent répondre à des questions concrètes :

Ces liens comptent particulièrement en période de croissance. Des pratiques informelles qui fonctionnent quand tout le monde se connaît deviennent peu fiables lorsque de nouvelles équipes, de nouveaux sites, de nouveaux fournisseurs et de nouveaux engagements clients apparaissent.

Définir un périmètre qui reflète l'activité

Partez du contexte de l'entreprise, pas d'une liste de mesures. Identifiez les services que l'organisation fournit, les informations qu'ils utilisent, les parties intéressées et leurs exigences, ainsi que les conditions internes et externes qui influent sur la sécurité.

Le périmètre définit la frontière du SMSI. Il doit identifier les activités couvertes, les unités organisationnelles, les sites le cas échéant, les technologies et les interfaces avec les autres parties de l'entreprise. Un premier périmètre utile peut couvrir un produit destiné aux clients et ses opérations de fourniture plutôt que toutes les activités de l'entreprise.

Un périmètre ciblé ne peut toutefois pas ignorer les dépendances. Si les RH déclenchent le processus de départ des salariés ayant accès au produit, cette interface compte. Si un fournisseur cloud héberge le service, l'externalisation ne fait pas disparaître la dépendance. Si le support exporte des informations clients, le processus d'export fait partie de l'analyse.

Rédigez une déclaration de périmètre, puis mettez-la à l'épreuve avec trois questions :

• Un client pourrait-il comprendre ce qui est couvert et ce qui ne l'est pas ?
• Avons-nous inclus les dépendances nécessaires pour protéger le service couvert ?
• Des responsables nommément désignés peuvent-ils maintenir le système dans cette frontière ?

Commencer petit est une recommandation pratique, pas une autorisation de tracer une frontière trompeuse. Un périmètre clair avec des responsables identifiés est plus solide qu'un vaste registre que personne ne met à jour. Élargissez-le délibérément lorsque de nouveaux services ou de nouvelles dépendances le justifient.

Attribuer des décisions, pas seulement des tâches

La direction doit fournir l'orientation et le soutien nécessaires à un SMSI ISO 27001. Déléguer la coordination à un responsable sécurité ne transfère pas la responsabilité de la direction en matière de priorités, de ressources et de risque acceptable.

Séparez les responsabilités qui sont souvent regroupées dans le poste d'une seule personne :

Une petite entreprise peut confier plusieurs responsabilités à une même personne. Elle doit néanmoins identifier quel rôle cette personne exerce et où une remise en question indépendante est nécessaire, en particulier pour l'audit interne.

Définissez des seuils d'escalade. Un chef d'équipe peut approuver une exception opérationnelle de courte durée dans des limites convenues ; un risque menaçant des engagements clients majeurs peut nécessiter l'approbation de la direction. Consignez la justification, les conditions, la date d'expiration et l'élément déclencheur de revue. « Accepté par la direction » ne suffit pas si personne ne peut identifier le décideur ni l'exposition acceptée.

Faire de l'appréciation des risques un processus de priorisation

L'appréciation des risques doit décrire des scénarios plausibles, et non simplement nommer des actifs ou lister des faiblesses. « Base de données clients » est un actif. « Un compte administrateur compromis permet l'extraction massive des données clients » est un scénario de risque, avec une cause et une conséquence.

Établissez une méthode d'appréciation documentée et des critères d'acceptation des risques. L'ISO 27001 n'impose pas de formule de cotation particulière. En pratique, définissez des catégories de vraisemblance et d'impact dans un langage que vos décideurs comprennent, en incluant la perturbation opérationnelle, la perte financière, les conséquences contractuelles et, le cas échéant, le préjudice causé aux personnes.

Pour chaque scénario significatif, consignez :

• Le service, les informations et les dépendances concernés.
• La menace ou l'événement et les vulnérabilités pertinentes.
• Les mesures existantes et leurs limites connues.
• La vraisemblance, l'impact et la priorité qui en résulte.
• Le propriétaire du risque et le traitement proposé.

Le traitement peut consister à réduire l'exposition par des mesures, à éviter une activité, à partager certains aspects du risque par des contrats ou une assurance, ou à accepter le risque dans les limites des critères approuvés. Une assurance ne restaure pas des informations perdues, et un contrat fournisseur ne supprime pas les responsabilités de l'organisation.

Distinguez le risque actuel du risque résiduel après traitement. N'abaissez pas une cotation simplement parce qu'une tâche est planifiée. Réévaluez après la mise en œuvre et des preuves de fonctionnement adéquates. Faites approuver le plan de traitement et l'acceptation du risque résiduel par l'autorité définie.

Le registre des risques opérationnels doit rester un registre de décisions : ce qui a changé, pourquoi un traitement a été choisi et quand l'appréciation doit être revue.

Sélectionner les mesures et expliquer leur applicabilité

Les mesures de sécurité sont les moyens utilisés pour modifier le risque. Elles comprennent des protections techniques comme l'authentification multifacteur, des processus organisationnels comme l'évaluation des fournisseurs, des mesures liées aux personnes comme la formation, et des protections physiques pour les appareils et les locaux.

L'Annexe A de l'ISO/IEC 27001:2022 contient 93 mesures de référence : 37 organisationnelles, 8 liées aux personnes, 14 physiques et 34 technologiques. La sélection repose sur les risques ; une organisation ne met pas automatiquement en œuvre toutes les mesures. L'ISO/IEC 27002 fournit des recommandations de mise en œuvre plutôt qu'une exigence de certification distincte pour le SMSI.

Pour l'ISO 27001, déterminez les mesures nécessaires au traitement des risques et comparez-les à l'Annexe A pour vérifier qu'aucune mesure nécessaire n'a été omise. Des mesures peuvent aussi être nécessaires en raison d'exigences légales ou contractuelles, et elles ne se limitent pas nécessairement à l'Annexe A.

La déclaration d'applicabilité consigne les mesures nécessaires, la justification de leur inclusion, leur état de mise en œuvre et la justification de l'exclusion de mesures de l'Annexe A. Elle se distingue du plan de traitement des risques : l'une explique l'ensemble des mesures applicables, l'autre les actions nécessaires pour traiter les risques. Consultez le guide des mesures de l'Annexe A pour cette structure de référence.

Pour chaque mesure retenue, définissez un responsable, le résultat visé, son mode de fonctionnement et les preuves qui démontreront son efficacité. « Contrôle d'accès mis en œuvre » est moins utile qu'un processus explicite couvrant l'approbation, l'attribution, la revue et la suppression.

Les politiques doivent établir des règles que les personnes peuvent suivre. Les procédures doivent expliquer l'exécution. Ni les unes ni les autres ne doivent promettre des revues ou des restrictions techniques que l'organisation ne peut pas réellement maintenir.

Intégrer les preuves aux opérations courantes

Les preuves doivent découler de l'exécution du travail, et non de la reconstitution d'un récit avant un audit. Une revue des accès peut produire une liste d'utilisateurs datée, les décisions du relecteur, des tickets de suppression et la confirmation que les changements ont eu lieu. Un exercice de reprise peut produire les conditions du test, les résultats, les limites observées et les actions de suivi.

Une capture d'écran peut montrer un paramètre à un instant donné. Elle ne prouve pas nécessairement que ce paramètre couvre tous les systèmes concernés ni qu'il est resté efficace pendant toute une période. Les relecteurs doivent examiner le périmètre, la date, la source, l'exhaustivité et la conclusion que la preuve étaye réellement.

Un ensemble pratique de preuves pour un SMSI comprend :

Chaque ligne ne nécessite pas un document distinct. Une petite organisation peut regrouper des enregistrements tant que la clarté et la traçabilité sont préservées. Protégez les preuves elles-mêmes : les exports d'utilisateurs, les enregistrements d'incidents et les captures d'écran peuvent contenir des informations sensibles et doivent faire l'objet de règles d'accès et de conservation appropriées.

Exemple concret : une plateforme de support client

Prenons à titre d'illustration un éditeur de logiciels de 30 personnes utilisant une plateforme de support SaaS. Supposons que la plateforme contienne les noms des clients, leurs coordonnées, l'historique des tickets et, à l'occasion, des pièces jointes de diagnostic. Le personnel utilise des comptes individuels, un prestataire externe héberge l'application et certains tickets sont exportés pour le dépannage. Il s'agit d'hypothèses d'exemple, et non d'un modèle d'entreprise prescrit.

Le périmètre du SMSI couvre les opérations de support client et leurs dépendances : identités du personnel, fournisseur SaaS, accès depuis les terminaux, exports, conservation et dispositifs de reprise. Le responsable du support est propriétaire du service ; l'informatique exploite les contrôles d'accès ; les achats coordonnent l'évaluation du fournisseur ; la direction approuve les risques qui dépassent l'autorité déléguée.

L'appréciation initiale identifie trois scénarios :

Supposons qu'un rapprochement des comptes révèle qu'un ancien salarié dispose encore d'un accès. L'action immédiate consiste à le supprimer et à évaluer si le compte a été utilisé de manière inappropriée. L'action relevant du système de management consiste à déterminer pourquoi la suppression a échoué. Peut-être les RH ont-elles prévenu l'informatique, mais l'application de support ne figurait pas dans la liste de contrôle des départs.

L'action corrective met alors à jour l'inventaire des applications, ajoute la plateforme de support au processus de départ, attribue la responsabilité de la confirmation et vérifie les départs suivants. Clore uniquement le ticket de suppression traiterait la situation immédiate sans en corriger la cause.

Supposons maintenant que le fournisseur SaaS modifie sa liste de sous-traitants ultérieurs. Le responsable du fournisseur examine le changement au regard des exigences contractuelles, de sécurité et, le cas échéant, de protection des données. Il consigne si le changement affecte le traitement des données, les dépendances ou le risque accepté, et si un examen spécialisé est nécessaire. Le changement a un responsable et un circuit de revue au lieu de rester non lu dans une boîte de réception partagée.

La direction reçoit les décisions en suspens : financer une solution de repli plus robuste, réduire les informations collectées dans les pièces jointes ou accepter une exposition résiduelle définie. C'est ainsi que le SMSI relie les constats opérationnels aux choix de l'entreprise.

Instaurer un rythme capable de détecter les changements

Planifiez les revues en fonction du risque, de la fréquence des changements et des obligations. Une revue hebdomadaire des écarts pendant la mise en œuvre initiale et une revue de direction périodique peuvent être des choix pratiques utiles, mais ce ne sont pas des intervalles universels imposés par l'ISO 27001. La norme exige des audits internes et des revues de direction à intervalles planifiés.

Ajoutez des déclencheurs événementiels : incidents, mises en production majeures, acquisitions, changements de fournisseurs, nouvelles obligations légales, engagements clients importants et constats d'audit. Un calendrier seul passera à côté de changements importants survenant entre les réunions programmées.

La surveillance vérifie si les mesures et les objectifs fonctionnent comme prévu. L'audit interne évalue si le SMSI est conforme aux exigences et s'il est mis en œuvre et maintenu de manière efficace. La revue de direction examine la pertinence, l'adéquation et l'efficacité du système et décide des changements et des ressources. Ces activités s'alimentent mutuellement mais ne sont pas interchangeables.

La direction doit recevoir des informations prêtes pour la décision : risques significatifs, traitements en retard, défaillances répétées, constats d'audit, exigences en évolution et contraintes de ressources. Compter les tâches réalisées sans examiner les résultats peut masquer une performance insuffisante. Le guide des indicateurs du SMSI présente des mesures utiles.

La gestion des incidents fait également partie de ce cycle. Définissez les voies de signalement, les critères d'évaluation, les responsabilités de réponse, l'autorité de communication et les dispositifs de reprise. Testez les circuits de contact et la prise de décision au moyen d'exercices. Évaluez les obligations de notification applicables plutôt que de supposer qu'un seul délai couvre tous les incidents.

Après un incident ou une non-conformité, traitez le problème immédiat, recherchez les causes, mettez en œuvre une action corrective et évaluez son efficacité. Des constats répétés sont une raison de repenser la conception du processus ou les ressources, et non de simplement répéter le même rappel.

Distinguer le SMSI, la certification et les obligations légales

Le SMSI est le système que l'organisation fait fonctionner. L'ISO 27001 est une norme au regard de laquelle ce système peut être évalué. La certification est délivrée par un organisme de certification indépendant, et non par l'ISO ou par Secani, et s'applique au périmètre déclaré.

La certification peut être un mécanisme d'assurance utile lorsque des clients ou d'autres parties prenantes l'exigent. Elle ne prouve pas que chaque activité de l'entreprise est couverte, que chaque mesure fonctionne en permanence ni que des incidents ne peuvent pas survenir. Vérifiez le périmètre et le statut plutôt que de considérer un certificat comme une garantie de sécurité à l'échelle de l'entreprise.

L'applicabilité juridique exige une analyse distincte. L'article 32 du RGPD exige des mesures techniques et organisationnelles de sécurité appropriées, fondées sur les risques pertinents. La directive NIS2 traite de la supervision par la direction, des mesures de gestion des risques et de la notification des incidents pour les entités couvertes, par le biais de sa transposition nationale.

Un SMSI peut organiser les preuves et les responsabilités qui soutiennent ces obligations, mais la certification n'établit pas la conformité au RGPD ou à NIS2. Il n'est pas non plus exact d'affirmer qu'un SMSI ne peut jamais être exigé par la loi : les règles nationales ou sectorielles applicables doivent être vérifiées.

Éviter trois échecs de mise en œuvre prévisibles

Adopter des modèles sans les adapter. Les modèles peuvent fournir une trame, mais les responsables doivent confronter chaque engagement à la pratique réelle. Une politique exigeant des revues que personne n'effectue crée un écart non maîtrisé.

Tracer une frontière que personne ne peut maintenir. Un inventaire ambitieux n'est pas utile si les responsabilités et les dépendances sont floues. Commencez par une frontière de service défendable, puis élargissez-la selon un plan explicite.

Considérer la certification comme la ligne d'arrivée. Le système doit perdurer à travers les changements de personnel, les changements de fournisseurs, les incidents et les nouveaux produits. Budgétez l'exploitation, la revue et l'amélioration, et pas seulement la documentation initiale.

Une mise en garde connexe concerne l'automatisation non relue. Les enregistrements collectés automatiquement et les synthèses générées par l'IA peuvent soutenir le travail, mais des personnes doivent toujours déterminer la pertinence, évaluer les écarts et approuver les conclusions.

Rendre concrète la première décision de la direction

Choisissez un service représentatif et demandez à son responsable d'apporter une déclaration de périmètre, une cartographie des dépendances, des scénarios de risque initiaux, les mesures actuelles et les décisions en suspens. Convenez de qui peut accepter un risque, des ressources disponibles et du moment où l'avancement sera examiné. Vous obtenez ainsi un point de départ maîtrisable sans prétendre que toute l'organisation est déjà couverte.

Le modèle d'espace de travail de Secani soutient ce processus en modélisant les services et les objets cibles qui les soutiennent, en reliant les preuves aux exigences, aux mesures et aux décisions, et en attribuant les responsabilités et les tâches de revue. Les équipes peuvent transformer des preuves manquantes ou des responsabilités floues en tâches. Les suggestions assistées par l'IA restent des brouillons soumis à une revue humaine, les sources et les approbations restant traçables.

La prochaine discussion de la direction doit donc être précise : quel service protégeons-nous en premier, quelle exposition exige une décision maintenant, et quelles preuves montreront que cette décision a porté ses fruits ?