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/

Répondre à