J’ai audité mon homelab contre l’ISO 27001. Mes écarts n’étaient pas techniques.

J’ai passé l’examen ISO/IEC 27001 Lead Implementer fin août, avec 81 %. Deux semaines plus tard, je me suis dit qu’une certification qu’on ne met jamais en pratique reste une ligne sur un CV. J’ai donc décidé d’appliquer la démarche à la seule infrastructure dont je réponds vraiment : mon homelab.

Je m’attendais à un exercice de rédaction. Ça s’est transformé en autre chose.

Le piège du périmètre

Première décision, et j’ai failli la rater. Mon lab sert à deux choses qui n’ont rien à voir : l’usage familial quotidien, et mon activité d’apprentissage et de projets cyber. Mon réflexe était de tout couvrir. Plus c’est large, plus c’est sérieux.

C’est l’inverse. Un périmètre large traité en surface ne démontre rien, et la clause 4.3 ne demande pas de tout couvrir. Elle demande de définir les limites en tenant compte des interfaces et des dépendances avec ce qui reste dehors.

J’ai donc exclu l’usage domestique. Mais pas le pare-feu, ni le commutateur, ni le NAS, ni le lien Internet. Ces équipements portent mon activité incluse, donc ils restent dedans, même s’ils servent aussi à ce qui est exclu. Le segment domestique, lui, devient une source de risque déclarée.

C’est le genre de subtilité qu’on lit vingt fois en formation sans la sentir. On la sent quand on doit tracer la frontière soi-même, sur sa propre installation, en sachant qu’un auditeur regarderait exactement là.

L’audit qui n’était pas prévu

Avant d’écrire quoi que ce soit, j’ai voulu vérifier ce que mon dépôt GitHub public contenait déjà. Il documente mes projets homelab depuis des mois.

J’y ai trouvé des adresses réelles dans certains dossiers et des placeholders dans d’autres. Un plan d’adressage complet publié à côté d’une matrice de flux. Des identifiants d’environnement cloud écrits en dur dans un script. Ils ne sont pas secrets, ce sont des identifiants et non des credentials, mais mis bout à bout ils désignent précisément mon tenant et un principal de service.

Le plus intéressant n’était pas la liste. C’était le motif.

Dans un dossier, j’avais écrit une règle d’exclusion pour mon fichier d’inventaire, avec un commentaire expliquant pourquoi. La règle était là. Elle était commentée. Je l’avais écrite et jamais activée.

Ailleurs, j’avais déjà appliqué le bon réflexe : un fichier d’exemple sans valeurs réelles, les vraies dans un fichier ignoré. Donc je connais la pratique. Je l’applique quand j’y pense. Je ne vérifie jamais.

C’est là que j’ai compris ce que je cherchais depuis le matin. Une bonne pratique et un contrôle ne sont pas la même chose. Un contrôle, c’est une bonne pratique plus le moyen de vérifier qu’elle s’applique. Tout mon écart tenait dans ce “plus”.

Ce que l’analyse de risques a fait remonter

J’ai suivi EBIOS RM pour satisfaire la clause 6.1.2, qui exige un processus défini et reproductible mais laisse le choix de la méthode. Quatre valeurs métier, quatre événements redoutés, trois scénarios stratégiques.

La première difficulté a été de ne pas partir du matériel. Ma tendance naturelle était de faire une valeur métier par équipement, ce qui aurait produit un inventaire déguisé en analyse de risques. Un serveur qui brûle, ça se rachète. Ce qu’il portait, non. La valeur est dans le travail accumulé, pas dans la machine.

La deuxième difficulté a été le volume. En croisant sources de risque, biens supports et valeurs métier, j’obtenais facilement quarante combinaisons. La méthode ne demande pas l’exhaustivité, elle demande de la cohérence. J’ai retenu trois scénarios sur des critères explicites : point d’entrée différent, valeur différente, et surtout traitement différent. Si deux scénarios appellent les mêmes mesures, le second n’apporte rien.

Le scénario qui ressort en tête n’est pas celui que j’attendais. Ce n’est pas le rançongiciel. C’est un contenu porteur d’instructions injectées, ingéré puis traité par un agent disposant d’accès outillés, qui atteindrait les informations que des structures me confient dans le cadre de mon activité d’aidant cyber.

Gravité maximale, parce que c’est le seul scénario dont les conséquences ne restent pas chez moi. Elles touchent des gens qui n’ont aucune prise sur ma sécurité.

Et j’ai buté sur un argument que je me servais à moi-même : ça ne m’est jamais arrivé. Sauf que ma supervision couvre le réseau et les hôtes, pas le comportement de mes agents. Je n’ai pas une observation d’absence, j’ai une absence d’observation. Ce n’est pas la même chose, et j’ai coté en conséquence.

La bonne nouvelle, c’est que le traitement était évident une fois le problème posé correctement. Mes agents n’ont aucun besoin de lire des comptes rendus d’accompagnement. Leur retirer l’accès à ce dossier ne réduit pas le risque, ça supprime le chemin. Cinq minutes.

Les 93 contrôles

J’ai hésité entre une déclaration d’applicabilité restreinte, limitée aux contrôles mobilisés par mes scénarios, et une déclaration complète. La norme tranche : la clause 6.1.3.d demande de justifier les inclusions comme les exclusions sur l’ensemble de l’Annexe A. Une SoA partielle est un exercice pédagogique, pas une SoA.

J’ai pris les 93. 84 applicables, 9 exclusions, toutes motivées par le contexte et jamais par la difficulté de mise en œuvre. Huit d’entre elles découlent de la même cause : je suis seul. Pas de séparation des tâches possible, pas de direction distincte, pas d’accord fournisseur négociable.

Sur les 84 applicables : 14 en place, 47 partiels, 23 absents.

Ce sont les 47 qui racontent l’histoire. Mon système n’est pas dépourvu de sécurité. Il est dépourvu de formalisation. Une politique de sauvegarde qui existe dans ma tête depuis deux ans et nulle part ailleurs. Une classification de l’information que je pratique sans l’avoir écrite. Une couverture d’authentification à deux facteurs que je connais par cœur et que personne d’autre ne peut vérifier.

Et sur les 23 absents, 12 relèvent du thème organisationnel, qui représente pourtant moins de la moitié des contrôles applicables. Procédure de gestion des incidents, revue des droits, objectifs de continuité, suivi des dépendances externes.

Voilà le résultat que je n’attendais pas. Je viens de l’infrastructure. Je pensais découvrir des trous techniques. Mes points forts sont techniques, et presque tous concentrés sur le réseau. Mes écarts sont organisationnels et documentaires.

Une chaîne qu’aucun contrôle isolé n’aurait montrée

Trois constats sont sortis à des moments différents de la journée, sur trois thèmes différents.

Les disques de mes postes ne sont pas chiffrés. Deux portables sortent du domicile et accèdent au stockage réseau. Des données réelles circulent dans mes travaux d’expérimentation.

Pris un par un, chacun se relativise. Ensemble, ils forment un chemin d’exposition d’informations qui ne m’appartiennent pas, et qui ne suppose aucune attaque. Il suffit d’oublier un sac dans un train.

C’est l’apport que je n’aurais obtenu d’aucune autre façon. Ni un scan de vulnérabilités, ni un durcissement CIS, ni un audit technique ne relie trois faiblesses situées dans trois thèmes distincts. Le passage systématique de l’Annexe A, si.

Ce que je ne publie pas, et pourquoi

Une des premières choses écrites ce jour-là a été une règle de publication pour mon dépôt public. Elle interdit notamment de publier une vulnérabilité non corrigée.

Cette règle s’applique à cet article. Je vous donne des comptes, des thèmes et un raisonnement. Je ne donne pas la liste nominative de mes écarts encore ouverts, ni les composants concernés. Ce serait publier une carte de mes faiblesses au moment précis où j’explique que je ne l’ai pas encore corrigée.

J’aurais pu ne rien en dire. J’aurais pu écrire l’article après avoir tout traité, et présenter un système propre. Ça aurait été plus flatteur et beaucoup moins vrai.

Ce que j’en retiens

Le plan de traitement compte 27 mesures réparties en quatre lots, jusqu’à fin décembre. Sept sont faites, les autres sont datées. Aucune organisation certifiée n’a un plan de traitement vide, et un SMSI qui prétendrait tout traiter en une semaine mentirait. Ce qu’un auditeur vérifie, ce n’est pas que tout soit fait, c’est que tout soit su, planifié et assumé.

Ce que la certification m’avait donné, c’était le vocabulaire et la structure. Ce que la journée m’a donné, c’est la sensation physique de la différence entre savoir qu’un contrôle existe et devoir décider s’il s’applique chez moi, dans mon contexte, avec mes contraintes. Sur les 93, il y en a une bonne dizaine où j’ai dû trancher sans être certain, et l’écrire quand même parce qu’une décision tracée vaut mieux qu’une case laissée vide.

Je referai l’exercice dans six mois, quand les quatre lots seront passés. Je suis assez curieux de voir si les 47 partiels auront bougé, ou si j’aurai simplement ajouté des mesures à un plan que je consulte de moins en moins.

Les livrables de ce mini-SMSI sont au nombre de cinq : contexte et périmètre, analyse de risques EBIOS RM, plan de traitement, déclaration d’applicabilité sur les 93 contrôles, et politique de sauvegarde. Les versions anonymisées sont publiées dans mon dépôt homelab, sous SMSI-Homelab/ : github.com/Kurgran/Homelab. La règle de publication qui encadre ce qui y figure et ce qui n’y figure pas est à la racine du dépôt, dans PUBLICATION.md.