Un mois au CEA, dont une semaine avec l'équipe S3i (cybersécurité des systèmes d'information industriels). Un contexte où "ça marchera probablement" n'est pas une réponse acceptable.
La culture du rapport d'incident
Écrire un rapport d'incident, ce n'est pas raconter une histoire : c'est produire un document qui doit permettre à quelqu'un d'autre de comprendre, reproduire et corriger, sans toi, parfois des années plus tard.
Structure apprise sur place : 1. Faits : horodatés, sourcés, sans interprétation 2. Analyse : hypothèses explicitement marquées comme telles 3. Recommandations : hiérarchisées par criticité, avec coût estimé
Pentesting : la partie émergée
L'exposition au pentesting m'a laissé une intuition durable : la surface d'attaque n'est presque jamais là où on la cherche. Les failles venaient des interfaces de maintenance oubliées, des mots de passe par défaut jamais changés, des flux inter-réseaux "temporaires" vieux de dix ans.
Le reste du mois : sécurité physique, économique, renseignement
La cyber n'est qu'un quadrant. Le reste du temps passait avec trois autres mondes : sécurité physique (contrôle d'accès, zonage, protection des installations), sécurité économique (protéger le patrimoine informationnel) et renseignement. Trois cultures différentes, une même grille de lecture : penser en vulnérabilités, scénarios de menaces et conséquences, pas seulement en failles logicielles. Ça recalibre : une bonne partie de ce qu'on sécurise en IT se perd aussi par une porte mal fermée ou un document mal rangé.
Ce que ça change dans mon code
Depuis, j'écris chaque système en me demandant : "quel est le mode de défaillance, et qui le détecte ?". La gestion de crise, c'est du design de système appliqué à l'avance.