Je pensais que 2021 servirait surtout à ranger les solutions montées dans l’urgence en 2020. On a effectivement parlé de travail hybride, du cycle de vie dans Microsoft 365 et d’outils low-code devenus critiques. Puis l’année nous a donné les rançongiciels, la pénurie de puces et Log4Shell juste avant Noël.

Mon point de vue a aussi changé en septembre quand je suis passé de directeur technique à directeur TI chez HLC. Le code et l’architecture restent importants, mais le registre des fournisseurs, identités, équipements, propriétaires et plans de reprise devient une partie directe du système.

Log4Shell, divulguée le 10 décembre, a rendu cette dépendance très concrète. Dans des versions vulnérables de Log4j 2, une chaîne journalisée pouvait contenir une expression JNDI. Le moteur de lookup tentait alors de résoudre une ressource distante. Selon la version et la configuration Java, cette interaction pouvait mener à l’exécution de code ou au moins à une connexion et une fuite d’information.

entrée non fiable contenant ${jndi:ldap://...}
→ application journalise la chaîne
→ Log4j interprète le lookup JNDI
→ requête vers un service contrôlé par l'attaquant
→ chargement/réponse dangereuse selon environnement

Le problème traverse les couches parce qu’une application peut embarquer Log4j dans un fichier JAR, un produit commercial, une image de conteneur ou un outil d’administration. Demander seulement « utilisons-nous Java? » ou chercher un serveur nommé Log4j ne suffit pas.

Répondre avec un inventaire vérifiable

Je structurerais l’incident ainsi :

1. recenser applications, produits, images et versions déployées;
2. demander aux fournisseurs une réponse précise et datée;
3. scanner les artefacts et systèmes, en connaissant les limites du scanner;
4. bloquer temporairement les sorties ou motifs connus lorsque possible;
5. appliquer la mise à jour recommandée ou retirer la composante vulnérable;
6. redémarrer réellement les processus et remplacer les images anciennes;
7. chercher des indices d’exploitation dans les journaux réseau et applicatifs;
8. retester et conserver la preuve de version par environnement.

Un package corrigé dans le dépôt n’aide pas si un ancien conteneur roule encore. Une atténuation par configuration ne remplace pas toujours la mise à jour et peut varier selon la version. Un WAF peut réduire certains vecteurs HTTP, mais la chaîne malveillante peut arriver par un champ, une file ou un protocole qu’il ne voit pas. La sortie réseau des serveurs réduit la portée d’un lookup, sans rendre la bibliothèque saine.

Un inventaire de composants logiciels, ou SBOM, peut relier produit, version et dépendances. Il doit correspondre au build réellement livré et rester interrogeable rapidement. Je veux aussi le propriétaire, la criticité, l’environnement, l’exposition, le fournisseur et le dernier résultat vérifié. Une feuille périmée donne une confiance dangereuse.

Les autres sujets de l’année suivent le même modèle. Une Power App dépend d’un compte et de connecteurs. Une réunion hybride dépend des flux médias, mais aussi du document et des décisions. Une livraison dépend d’événements de plusieurs fournisseurs. Une machine virtuelle dépend encore de composants physiques. Une sauvegarde dépend d’une identité séparée et d’une restauration propre.

Le parcours du Canadien jusqu’en finale a fourni un exemple plus léger d’incertitude : une probabilité raisonnable laisse toujours de la place à un résultat moins fréquent. En TI, cette incertitude ne justifie pas de tout prévoir; elle justifie un état observable et une reprise testée.

Je termine l’année avec un registre plus concret :

Élément	Propriétaire	Dépendance critique	Version/fin de vie	Reprise testée
service client	équipe A	identité + base + Log4j	à vérifier	date/résultat
flux low-code	équipe B	compte + connecteurs	solution 1.4	date/résultat
serveur physique	infrastructure	contrôleur source unique	fin de support connue	date/résultat

La pratique pour 2022 sera de choisir chaque mois un service critique, reconstruire son graphe avec des preuves de production, puis provoquer la perte d’une dépendance. Je préfère trouver un compte oublié ou une bibliothèque cachée pendant cet exercice qu’au milieu d’une vulnérabilité ou d’une restauration réelle.