Analyse de risques EBIOS RM — ce qui est publiable
SMSI · 2 — la méthode EBIOS RM appliquée à l'infrastructure qui héberge ce portfolio : ce qu'elle protège, contre qui, et ce qu'on redoute qu'il arrive. Les deux derniers ateliers — comment une attaque se déroulerait techniquement, et ce qu'il reste de risque après traitement — ne sont pas publiés, et la fin de cette page explique pourquoi.
EBIOS RM est une méthode, pas un label. Publiée par l'ANSSI, elle structure l'analyse de risques par ateliers successifs, du métier vers la technique. Elle alimente ici la Déclaration d'Applicabilité ISO/IEC 27001:2022 : on ne choisit pas des mesures parce qu'elles figurent dans une liste, on les choisit parce qu'un risque identifié les appelle.
Les cinq ateliers, et ce qui en est publié
Chaque atelier répond à une question et produit un livrable. Les trois premiers décrivent ce qu'on protège et ce qu'on craint : les publier ne donne aucun avantage à un attaquant. Les deux derniers décrivent les chemins d'attaque et l'état des défenses après traitement : les publier reviendrait à écrire soi-même le plan de bataille.
| Atelier | Question | Livrable | Publié |
|---|---|---|---|
| 1 — Socle de sécurité | Qu'est-ce que je protège, et avec quoi ? | Valeurs métier, biens supports, périmètre | Oui, ci-dessous |
| 2 — Sources de risque | Qui pourrait s'y intéresser, et pour quoi faire ? | Couples source de risque / objectif visé | Oui, ci-dessous |
| 3 — Scénarios stratégiques | Qu'est-ce que je redoute qu'il arrive ? | Événements redoutés | Oui, ci-dessous |
| 4 — Scénarios opérationnels | Par quel chemin technique ? | Chemins d'attaque détaillés | Non — sur demande |
| 5 — Traitement du risque | Que fait-on, et que reste-t-il ? | Plan de traitement, risques résiduels | Non — sur demande |
Atelier 1 — ce que ce SMSI protège
Deux valeurs métier, et elles ne pèsent pas le même poids. La réputation professionnelle est la raison d'être du site : c'est elle qu'un recruteur consulte. Les données des visiteurs, elles, n'appartiennent pas à leur propriétaire — ce sont les données de personnes qui n'ont rien demandé, et c'est ce qui les rend prioritaires.
Valeurs métier
- Réputation professionnelle — ce que le site donne à voir d'un travail, au moment précis où quelqu'un décide de rappeler ou non.
- Données des visiteurs — les consultations tracées par lien nominatif, et ce qu'elles disent des personnes qui ont ouvert le lien.
Biens supports
- La machine virtuelle qui héberge le service.
- Le serveur web en frontal, qui termine les connexions.
- La base de données applicative, qui contient le contenu éditorial et les consultations.
- Les accès d'administration, clés comprises.
- Le nom de domaine et sa zone DNS, sans lesquels rien n'est joignable.
Le détail nominatif de ces biens supports — versions, adresses, emplacements — vit dans le périmètre et l'inventaire des actifs, avec la cotation de chacun en confidentialité, intégrité et disponibilité.
Atelier 2 — qui pourrait s'y intéresser
Quatre sources de risque ont été retenues. Aucune n'est spectaculaire, et c'est le résultat le plus utile de l'exercice : un portfolio personnel n'intéresse pas un attaquant étatique. Il intéresse ce qui passe par là, et il est exposé à celui qui l'administre.
| Source de risque | Ce qu'elle cherche | Pourquoi elle est retenue |
|---|---|---|
| Scanner opportuniste | Une machine mal configurée, n'importe laquelle | Permanent et indiscriminé : toute adresse publique le subit |
| Bot d'exploitation | Une faille connue et non corrigée | Exploite en heures ce qui est publié en jours |
| Concurrent de candidature | Nuire à la crédibilité au bon moment | Peu probable, mais l'impact tombe pile au moment qui compte |
| Erreur d'administration | Rien — elle ne cherche pas | La plus probable des quatre. Une seule personne administre, sans revue par un pair |
Retenir sa propre erreur comme source de risque principale n'est pas une coquetterie : c'est ce qui justifie les mesures les plus contraignantes du SMSI — procédure de changement écrite, déploiement automatisé plutôt que manuel, secrets hors du dépôt, registre des incidents. Un incident de présentation survenu le 12 septembre 2026, causé par une manœuvre de ma part et non par un tiers, a confirmé cette cotation.
Atelier 3 — ce qu'on redoute qu'il arrive
Trois événements redoutés. Ils sont formulés du point de vue de ce qu'on perd, pas de la manière dont on le perd — c'est la différence entre un événement redouté et un scénario d'attaque, et c'est aussi ce qui rend les premiers publiables et les seconds non.
| Événement redouté | Valeur métier touchée | Critère | Ce qui le rend grave |
|---|---|---|---|
| Le site affiche autre chose que ce que j'y ai mis, pendant un processus de recrutement | Réputation professionnelle | Intégrité | La fenêtre : quelques heures suffisent si c'est celle où le lien est ouvert |
| La liste des recruteurs ayant consulté le lien sort du périmètre | Données des visiteurs | Confidentialité | Ce sont des tiers : ils n'ont pas choisi ce risque, et l'exposition les concerne |
| Le site est injoignable au moment exact où le lien est cliqué | Réputation professionnelle | Disponibilité | Un lien mort ne se rattrape pas : la personne ne revient pas |
Ces trois événements expliquent un choix d'architecture visible sur le site : l'accès par lien nominatif. Il sert la candidature, mais il crée aussi le deuxième événement redouté — sans traçage des consultations, il n'y aurait rien à faire fuiter. C'est un arbitrage assumé, documenté comme tel, et c'est lui qui impose la conservation limitée décrite dans le registre RGPD.
Ce qui n'est pas publié, et pourquoi
Les ateliers 4 et 5 restent hors ligne.
L'atelier 4 décrit, pour chaque événement redouté, les chemins techniques qui y mènent : par où, dans quel ordre, en exploitant quoi. C'est utile pour décider des mesures. Publié, c'est une liste d'entrées à essayer, triée par efficacité, sur une machine nommément désignée.
L'atelier 5 dit ce qu'il reste de risque après traitement. Publié, il désigne précisément les endroits où les défenses sont les plus faibles, et le fait en connaissance de cause — puisque c'est justement ce que l'exercice mesure.
Ce découpage n'est pas une réserve pudique : la Déclaration d'Applicabilité impose de protéger l'information selon sa sensibilité, et une analyse de risques est l'un des documents les plus sensibles qu'un SMSI produise. Publier l'intégralité serait un écart que la démarche elle-même documenterait.
Les deux ateliers sont communicables sur demande, dans un cadre d'entretien.
Ce qui reste public, en revanche, ce sont les écarts. Les manques connus de cette infrastructure sont écrits en toutes lettres sur la fiche du projet et dans l'extrait de Déclaration d'Applicabilité. Un SMSI qui ne publie que ses réussites n'est pas un SMSI.
Ce que l'analyse a changé
Une analyse de risques qui ne change rien n'a pas servi. Trois décisions viennent directement de ces trois ateliers.
- Un projet a été abandonné. Un outil d'OSINT automatique était prévu : collecter des données publiques sur des personnes, sans les prévenir. L'atelier 2 a fait apparaître que le risque principal n'était pas technique mais juridique, et l'article 14 du RGPD — l'information des personnes dont les données n'ont pas été collectées auprès d'elles — ne pouvait pas être satisfait. Le projet a été repris sur une autre base, sans données personnelles de tiers.
- La conservation des données de visite a été bornée. Le deuxième événement redouté ne peut concerner que des données encore présentes : la durée de conservation est donc devenue une mesure de sécurité, pas seulement une case RGPD.
- La procédure de changement est passée avant la surveillance. L'erreur d'administration étant la source de risque la plus probable, écrire comment on déploie a été traité en priorité sur l'outillage de détection.