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,
--
Maxime DERCHE
OpenPGP public key ID : 0xAE5264B5
OpenPGP public key fingerprint : 7221 4C4F D57C 456F 8E40 3257 47F7 29A6 AE52
64B5
<https://www.mouet-mouet.net/maxime/blog/>
_______________________________________________
Liste de diffusion du %(real_name)s
http://www.frsag.org/
