Bonjour Laurent,
Le 12/07/2022 à 08:25, Laurent Barme a écrit :
Le 12/07/2022 à 07:36, Maxime DERCHE a écrit :
Bonjour Jérôme,
J'espère que tu vas bien. :)
Ma question ne porte pas sur l'existence de logiciels obsolètes donc sur la gestion du risque qu'ils induisent, mais sur le risque induit par la publicité qui en est faite, à plus ou moins bon escient.
Le "risque induit par la publicité qui en est faite" est certainement encore plus dérisoire que celui des logiciels "obsolètes". Comme si une debian 9 devenait dangereuse à partir du 01/07/22, fin de sa LTS !
La frénésie des mises à jour comme solution universelle de sécurité tiens davantage d'une posture dogmatique que d'une réalité opérationnelle.
C'est une réponse opérationnelle donc partielle à une question beaucoup plus générale et par ailleurs largement dépassée aujourd'hui. :)
La question de la date d'obsolescence du logiciel est aujourd'hui un consensus dans toute l'industrie, car tout le monde en a besoin : * le logiciel libre en a besoin pour clarifier sa gouvernance (cycle de vie et gestion de l'effort collectif) ; * le logiciel propriétaire en a besoin pour des raisons économiques (fin de support contractuel) ; * la sécurité en a besoin pour clarifier sa gouvernance (la même règle pour tout le monde, infra et dev inclus) ; * les financier-es en ont besoin pour gérer les coûts à l'avance (eh ouais).
À titre de simple exemple, choisi hors du champ de l'infrastructure : il n'est pas possible de stopper toute l'activité de développement un lundi matin de décembre juste avant les vacances de fin d'année pour exiger une correction immédiate de tous les Apache log4j (ou Spring Boot quelques semaines plus tard) dans tous les projets de toutes les équipes sans avoir une gouvernance claire sur le moment où un logiciel est "considéré" comme obsolète. Ça peut paraître arbitraire, mais d'une part ça ne l'est pas tant que cela puisque clairement affiché par toute une industrie, et d'autre part il n'est pas envisageable de gérer l'obsolescence au cas par cas dans le cadre d'une négociation entre la sécurité et chaque équipe (la sécurité est déjà suffisamment en souffrance comme cela...).
L'arbitraire d'une date fixe d'obsolescence est de plus largement atténué par la pratique sécurité habituelle qui fonctionne en cycles d'amélioration continue reposant sur des "feuilles de routes" généralement trimestrielles... (Sauf cas où le-la RSSI est un-e imbécile qui exige seul-le l'impossible du haut de sa tour d'ivoire.) Donc non Debian 9 n'est pas "dangereuse" à date de fin de support, mais elle peut le devenir quelques heures/jours/semaines/mois plus tard au gré des publications de sécurité : c'est un vrai risque.
Pour conclure, la frénésie des mises à jour n'est que très rarement la solution universelle de sécurité : la doctrine (pire qu'un dogme ?) actuelle est à la défense en profondeur où chaque composant/couche/maillon doit pouvoir assurer sa propre défense individuellement et en autonomie.
C'est très bête mais si la mise à jour était la seule mesure de sécurité cela n'obligerait le crime organisé qu'à migrer massivement vers du 0day, le problème resterait donc le même...
Le débat aujourd'hui dans le milieu sécurité n'est donc plus à justifier la gestion de l'obsolescence du logiciel, mais à couvrir les angles morts comme les offres d'emploi ou l'entraide technique publique. D'où ma question initiale.
Bien cordialement,