Bonjour,
Le 12/07/2022 à 10:19, Christophe Casalegno via FRsAG a écrit :
Le lundi 11 juillet 2022, 17:49:49 IST Maxime DERCHE a écrit :
Question un peu bête mais je termine à peine mon vendredi :
Vos RSSI vous autorisent encore à avouer publiquement que vous faites
tourner des OS obsolètes ?
Hello
Je dirais que le fait qu'une distribution GNU / Linux (ou qu'un autre
logiciel), soit déclaré "end of life" ne signifie (surtout dans le domaine du
logiciel libre), ni qu'il n'est plus maintenu, ni qu'il est "obsolète" (à
définir précisément).
J'ai maintenu des machines avec des OS (notamment Mandriva) qui étaient
obsolètes depuis bien longtemps, et faisant tourner des applications en php4
tournant sur apache 1.3. Et je suis sur de ne pas être la seule personne au
monde dans ce cas là.
Pour autant, elles ont continué d'être patchées régulièrement lorsque c'était
nécessaire en terme de sécurité (kernel, ghost, shellshock, ssl, etc.) ou de
correction de bugs fonctionnels (MySQL) et n'ont jamais posé le moindre
problème.
Ceci étant, tant qu'il y aura des clients pour avoir ce besoin, il existera
des prestataires pour y répondre : la situation crée le marché. De plus au
bout d'un temps : plus personne ne recherche de vulnérabilités sur ces
versions trop anciennes et trop peu utilisées.. et le risque de 0day est bien
plus important sur un logiciel récent qu'un logiciel obsolète.
Et je ne parle même pas des clients "industriels" on trouve des choses bien
plus anciennes... parfois à des fonctions critiques.
Cela n'engendre pas de problèmes de sécurité particuliers : ces machines
fonctionnent généralement en circuit fermé et la surface d'exposition est
quasi nulle.
Par contre cela peut engendrer de gros problèmes de SAV si les pièces de
rechanges ne sont pas dispo. Le pire que j'ai vu jusqu'à présent, il n'y a pas
si longtemps, c'est un 286 sous MS-DOS enfermé dans une pièce en verre et dont
dépend beaucoup d'activités non seulement de l'organisme mais de tiers.
Bonne semaine à tous,
Là encore, cela relève de l'analyse au doigt mouillé, pas de la gestion de
risque. :)
(Et il faut avouer que même en gestion de risque, la notation du risque se fait sur
une échelle de valeur souvent subjective car il est difficile de construire un barème
raisonné... Donc la gestion de risque au doigt mouillé ne vaut pas mieux.)
Maintenir un service reposant sur des logiciels libres "obsolètes" (obsolètes au
moins sur le papier), c'est effectivement faisable même sur un temps très long
puisqu'il est toujours techniquement et légalement faisable de rétroporter les
corrections. Et le travail peut être réalisé de manière qualitative par des personnes
qualifiées, donc la gouvernance sécurité peut s'organiser et fonctionner correctement
sur cette base, avec une gestion de risque clairement posée.
(L'équipe d'OpenBSD a maintenu Apache HTTPd 1.3 pendant des années sans problème.
C'est par contre inimaginable dans le monde propriétaire/commercial.)
Mais le coût économique devient lourd, et la responsabilité en cas d'erreur devient
de plus en plus floue au fil du temps, car comment reprocher au prestataire qui
maintient un service obsolète depuis longtemps d'avoir cassé quelque chose avec un
patch artisanal introduisant un bug quelconque (par exemple) ?
Je comprend bien qu'il y a des antiquités parfaitement fonctionnelles qui font très
bien leur travail et qu'on a su et pu maintenir en condition de sécurité raisonnable
en durcissant l'environnement puisqu'on ne peut plus durcir le service. Mais
gouverner la sécurité au cas par cas individuel chaque antiquité coûte très cher et
le risque d'erreur est croissant avec le temps.
Au passage l'argument des trucs tellement anciens qu'ils sont devenus sûrs ne tient
ni techniquement (Internet n'oublie jamais rien, l'exploit publié en 19xy est
toujours disponible et fonctionnel) ni juridiquement ("security by design"), et
encore moins moralement face aux personnes concernées qui nous font confiance pour
protéger leurs données...
Réfléchir en terme de marché avantage l'attaquant, pas le défenseur, et cela se fait
au détriment des personnes humaines : il y aura toujours un marché pour héberger des
applications PHP 4 non-maintenues (ou maintenues mais faibles voire indéfendables) au
risque que les données fuitent, et tant pis pour les victimes, même si l'hébergeur a
bien fait son travail.
Il est beaucoup plus simple et sain de se donner une règle claire à partir de
laquelle on gère l'obsolescence comme étant un risque que l'on va traiter de manière
prévisible en fonction du niveau de criticité et des possibilités financières, non ?
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/
