ISO 27001

Tout le SMSI repose sur l'analyse de risques. Les mesures de sécurité ne se choisissent pas parce qu'elles sont à la mode ou parce qu'un concurrent les affiche : elles se choisissent parce qu'elles réduisent un risque identifié. Un auditeur qui veut savoir pourquoi Factura chiffre ses sauvegardes doit pouvoir remonter jusqu'à une ligne du registre des risques.

La norme laisse une grande liberté sur la méthode. Elle impose des propriétés : le processus doit être défini, répétable, et produire des résultats cohérents, valides et comparables. Deux personnes qui appliquent la méthode sur le même périmètre doivent arriver à des conclusions proches.

Les étapes imposées par la clause 6.1.2

1. Définir les critères        → échelles, seuil d'acceptation
2. Identifier les risques       → ce qui peut arriver, à quoi, à cause de quoi
3. Analyser les risques         → vraisemblance × conséquence = niveau
4. Évaluer les risques          → comparer au seuil, prioriser
5. Traiter (clause 6.1.3)       → réduire, éviter, transférer, accepter

Chaque risque doit avoir un propriétaire. C'est une exigence explicite, souvent oubliée.

Étape 1 : les critères

Avant d'analyser un seul risque, on fixe les échelles. Factura retient une échelle à 4 niveaux, plus simple à appliquer qu'une échelle à 5 où tout le monde choisit 3.

Vraisemblance

Conséquence

Niveau de risque = vraisemblance × conséquence, de 1 à 16.

                 Conséquence
                 1     2     3     4
Vraisemblance 4  4     8    12    16
              3  3     6     9    12
              2  2     4     6     8
              1  1     2     3     4
 
  1-3  : faible   → acceptable
  4-6  : modéré   → acceptable si le propriétaire le décide et le justifie
  8-9  : élevé    → traitement obligatoire
  12-16: critique → traitement prioritaire, suivi par la direction

Le seuil d'acceptation est une décision de la direction, pas de l'équipe technique. Il doit être écrit avant l'analyse, sinon on finit par ajuster le seuil pour que les résultats arrangent tout le monde.

Étape 2 : identifier les risques

Deux approches existent.

Par les actifs. On inventorie les actifs (données, applications, serveurs, personnes, locaux), puis pour chacun on cherche les menaces et les vulnérabilités. C'était l'approche imposée par la version 2005. Elle est exhaustive mais lourde.

Par les scénarios. On part des événements redoutés et des sources de menace, puis on construit des scénarios plausibles. C'est l'approche d'EBIOS Risk Manager, la méthode publiée par l'ANSSI, et celle que décrit aussi l'ISO 27005 depuis 2022.

La norme accepte les deux. Pour une PME, je recommande un mélange : un inventaire des actifs simple (il est de toute façon exigé par la mesure 5.9), et des risques formulés en scénarios lisibles. Un scénario se rédige avec une structure fixe :

[Source de menace] exploite [vulnérabilité] pour [action],
ce qui entraîne [conséquence] sur [actif].

Exemples chez Factura :

• Un attaquant exploite une dépendance npm vulnérable pour exécuter du code sur l'API, ce qui entraîne une fuite des factures de tous les clients.
• Un ancien salarié conserve son accès GitHub et pousse du code malveillant, ce qui entraîne une compromission de la production.
• Une erreur de manipulation supprime la base de production, et la dernière sauvegarde restaurable date de plus de 24 h.
• Le prestataire d'emails subit une panne de plusieurs jours, les relances de paiement ne partent plus.

Faites l'atelier en équipe : un développeur, un ops, une personne du support, le CTO. Deux heures suffisent pour une première liste de 30 à 50 scénarios. Le support connaît des risques que la technique ignore, par exemple les clients qui envoient des mots de passe par ticket.

Étapes 3 et 4 : analyser et évaluer

Pour chaque scénario, on estime vraisemblance et conséquence en tenant compte des mesures déjà en place. On obtient le risque actuel. Le registre de Factura est un simple fichier YAML versionné dans un dépôt Git, ce qui donne l'historique et la validation par pull request :

- id: R-007
  scenario: >
    Un attaquant exploite une dépendance npm vulnérable pour exécuter
    du code sur l'API et exfiltrer les factures clients.
  actifs: [api-node, base-postgres, donnees-factures]
  proprietaire: lead-dev
  mesures_existantes:
    - Dependabot activé, sans délai de correction défini
  vraisemblance: 3
  consequence: 4
  niveau: 12          # critique
  decision: reduire
  mesures_prevues:
    - "8.8 : politique de correction (critique < 7 jours), alerte Slack"
    - "8.25 / 8.28 : scan SCA bloquant dans la CI"
    - "8.16 : détection d'appels sortants anormaux depuis l'API"
  risque_residuel:
    vraisemblance: 2
    consequence: 4
    niveau: 8
  acceptation_residuel: "CEO, revue de direction du 2026-03-12"
 
- id: R-012
  scenario: >
    Panne prolongée du prestataire d'envoi d'emails, les relances
    de paiement ne partent plus.
  actifs: [service-relances]
  proprietaire: lead-ops
  vraisemblance: 2
  consequence: 2
  niveau: 4           # modéré
  decision: accepter
  justification: >
    Les relances peuvent être différées de quelques jours sans impact
    contractuel. File d'attente persistante existante.

Un tableur fonctionne aussi bien. Les outils GRC spécialisés deviennent intéressants au-delà de quelques centaines de risques, ou pour plusieurs sites.

Le traitement : quatre options

La clause 6.1.3 demande de choisir une option de traitement pour chaque risque :

Partager ne veut pas dire faire disparaître. Une assurance rembourse une partie des coûts, elle ne rend pas les données volées. Et un risque confié à un fournisseur reste sous votre responsabilité vis-à-vis de vos clients.

Comparer avec l'annexe A

C'est l'étape qui distingue ISO 27001 d'une analyse de risques ordinaire. Après avoir choisi les mesures nécessaires, il faut les comparer à l'annexe A pour vérifier qu'aucune mesure nécessaire n'a été oubliée.

L'annexe A n'est pas une liste à appliquer intégralement. C'est une liste de contrôle. Si votre analyse n'a jamais fait ressortir de besoin de sauvegarde, mais que la mesure 8.13 existe, c'est probablement votre analyse qui a un trou.

Les mesures peuvent aussi venir d'ailleurs : référentiel de l'ANSSI, CIS Controls, exigences d'un client. La norme n'exige pas de se limiter à l'annexe A.

Les livrables de la clause 6.1.3

Le traitement produit deux documents obligatoires :

1. La déclaration d'applicabilité (DdA, ou SoA en anglais) : pour chacune des 93 mesures, est-elle applicable, pourquoi, et est-elle mise en œuvre ? C'est le document le plus regardé par l'auditeur, détaillé au chapitre suivant.
2. Le plan de traitement des risques : quelles mesures, qui, quand, avec quels moyens.

Enfin, les propriétaires de risques doivent approuver le plan et accepter formellement les risques résiduels. Une trace écrite est nécessaire : un compte rendu de revue de direction, un ticket approuvé, une signature dans le registre.

Quand refaire l'analyse

La clause 8.2 exige une réévaluation à intervalles planifiés et lors de changements importants. Chez Factura, la règle est simple :

• revue complète une fois par an, avant la revue de direction ;
• revue ciblée à chaque changement majeur : nouveau fournisseur critique, nouvelle fonctionnalité qui traite des données sensibles, incident significatif, changement d'hébergeur.

Pour aller plus loin sur les menaces côté code, la cybersécurité pour les développeurs détaille les attaques les plus courantes sur une application web, utiles pour nourrir l'atelier de scénarios.

Le chapitre suivant ouvre l'annexe A et montre comment construire la déclaration d'applicabilité.