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,