Journal Assurer la sécurité informatique sur le modèle de la sécurité alimentaire

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
12
2
fév.
2021

Sommaire

En regardant ce qui permet aux attaquants de réussir à pénétrer ou altérer des systèmes informatiques, on constate qu'une des causes principales est l'utilisation de logiciels ou technologies obsolètes. Nous, développeurs et administrateurs, savons identifier les outils trop vieux et plus assez sécurisés, donc dangereux, mais cette culture est difficilement partagée avec les utilisateurs et décideurs.

Pour pallier à ce problème, je propose qu'on se mette à utiliser deux outils simples et efficaces en matière de sécurité alimentaire :

  • les dates de péremption
  • la liste des ingrédients

Liste des ingrédients

Tous les logiciels, services et outils que nous proposons sont constitués par l'assemblage de composants plus simples, plus génériques :

  • un logiciel "bureau" repose a minima sur un noyau et une architecture et/ou un runtime (jvm, bash…). Il est écrit dans un langage spécifique et, le plus souvent, dépend de composants tiers (bibliothèques, qu'elles soient partagées au niveau du système ou embarquées dans le binaire).
  • un service web simple repose, côté serveur, sur un OS, un serveur web, le plus souvent un interpréteur (PHP, Python,…) et une base de données, quelle que soit sa forme. Côté client, ça repose sur un navigateur et souvent un paquet de dépendances diverses (JS, CSS) gérées par un gestionnaire de dépendances (bower, puis npm…)
  • un service plus complexe peut être constitué de containers ou de machines virtuelles, orchestrés par un outil spécifique (docker-compose puis, à l'échelle du dessus, kubernetes, helm…).
  • un objet connecté repose sur un firmware et là aussi, des dépendances logicielles ou logiques (protocoles).

Bref, tout ce que nous produisons, mettons en service, maintenons est composé de briques plus petites. Et il suffit qu'une de ces briques soit sujette à une faille pour que la sécurité de l'ensemble soit compromise, de la même manière qu'il suffit qu'un des ingrédients soit pourri pour que mon hachis parmentier devienne impropre à la consommation.

D'où la proposition suivante : communiquer avec la description du produit la liste de ses ingrédients. Il ne s'agit pas de simplement publier le code source (on le fait déjà), mais d'afficher une notice assez courte pour être lue et assez précise pour identifier les principaux composants et risques de sécurité associés, en ajoutant un lien vers la page "durée de vie" de chaque composant si elle existe ou, à défaut, vers la liste des versions dudit logiciel.

Exemples (fictifs) :
- org.gnome.Lollypop-1.4.15 : Gstreamer 1.18, gnome 3.38, plate-forme freedesktop 20.08
- dolicloud : Dolibarr 12.0, Debian 10 Buster (Apache 2.4.38, PHP 7.3, mariadb 10.3)
- gitlab (image docker) : gitlab-ce 13.5.7, docker engine, ubuntu 16.04, postgresql, redis

C'est assez proche de la liste des dépendances d'un logiciel, présente dans les métadonnées des paquets binaires (.flatpak, .rpm, .deb, dockerfile…), mais filtrée pour ne garder que ce qui est significatif et ordonnée pour mettre en avant les composants les plus importants.

Dates limites

En Europe, selon les produits, deux dates peuvent être indiquées :

  • date limite de consommation, après laquelle le produit ne doit plus être consommé (viande,…)
  • date limite d'utilisation optimale, après laquelle le produit peut perdre certaines de ses qualités mais peut, la plupart du temps, être consommé sans danger.

On peut appliquer les mêmes concepts pour les logiciels et systèmes :

  • la date limite de consommation est la date de fin du support du produit ou la date la plus courte parmi celles de ses ingrédients
  • la date limite d'utilisation optimale peut correspondre à la durée qui sépare deux versions (elle n'a de sens que quand plusieurs versions du logiciel ou de ses dépendances sont maintenues en parallèle).

Ces notions existent déjà et sont utilisées, notamment pour les systèmes d'exploitation ("date de fin de vie" ou de "fin de support étendu"). Je propose ici de généraliser la définition de ces concepts à tous nos projets informatiques mais aussi d'afficher cette information de façon plus visible pour l'utilisateur final : dès la page de téléchargement ou dans le corps même de l'application. C'est ce qu'avait fait Jamie Zawinski sous une forme assez radicale pour xscreensaver par exemple.

Ces dates se déduisent assez mécaniquement de la liste des ingrédients : le produit devient nécessairement dangereux à partir du moment où l'une de ses dépendances n'est plus à jour ou plus maintenue. Il n'est pas toujours évident de connaître la durée du support pour telle ou telle bibliothèque ou logiciel, mais observer l'historique des versions permet souvent d'avoir une idée.

Les objectifs

Généraliser l'affichage de ces indications permettrait :
- de responsabiliser les utilisateurs/clients vis-à-vis des outils qu'ils déploient, en les informant clairement des limites temporelles de validité
- d'en finir avec l'idée que déployer un logiciel ou un outil serait un investissement "one-shot" : ce sont des coûts récurrents et il faut planifier (budgéter !) la maintenance dès la mise en place
- d'en finir avec le "deploy&forget" et les applications "legacy" qui tournent dans le même état depuis des années, avec d'énormes trous de sécurité sans que personne ne s'en occupe
- d'encourager les développeurs/intégrateurs à s'appuyer sur des outils éprouvés et maintenus sur du long terme plutôt que sur des technologies bleeding-edge qui seront abandonnées très vite, ou à s'engager à maintenir ces outils s'ils sont abandonnés par leurs concepteurs.

Ce journal est un appel à commentaires : qu'en pensez-vous ?

  • # Mouais

    Posté par  . Évalué à 9.

    Pousser les gens à changer de logiciel perce qu'une brique n'a pas eu besoin d'évoluer depuis longtemps risque de les pousser vers des solutions moins testées, voir permettre à des gens de se spécialiser dans le renouvellement des briques pour y rajouter des trucs indésirables;

    C'est aussi une ode à la consommation, car on fait rarement des softs pour une vieille machine.

    y a t'il plus de faille dans les vieille briques que dans les nouvelles ?

    Pour les entreprises, le soucis ne changera pas: celle qui savent ce que c'est payent une équipe ou la maintenance, les autres ne voient pas l'intérêt de bloquer du temps / des ressources pour risquer de remplacer un truc qui marche par un truc qui plante.

    Enfin, en tant que développeur (open source depuis peu :P) je suis incapable de te donner une date pour les biques que je code.
    1) si je suis le seul dessus et que je me plante dans un accident de speeder la date de fin de support que j'aurais donné est forcément erronée
    2) si y a une faille dans une brique, elle est déjà périmée ton décideur il va dire pas besoin de mettre à jour, il est valable jusqu'à tant.

    Bref à part donner un faux sentiment de sécurité, je ne pense pas que ça soit une riche idée.

    Par contre lister l'ensemble des briques constituant un logiciel permet à ceux en assurant leur sécurité de s'assurer de leur risque.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: Mouais

      Posté par  (site web personnel) . Évalué à 3.

      Pousser les gens à changer de logiciel perce qu'une brique n'a pas eu besoin d'évoluer depuis longtemps risque de les pousser vers des solutions moins testées, voir permettre à des gens de se spécialiser dans le renouvellement des briques pour y rajouter des trucs indésirables;

      L'idée est de pousser les gens à aller vers des solutions maintenues.

      Assez rapidement, le décideur se rend compte qu'un logiciel stable est moins coûteux qu'un logiciel tout récent : on privilégiera Ubuntu LTS à la dernière version, RHEL à Fedora, un noyau LTS à celui le plus récent, etc.

      Enfin, en tant que développeur (open source depuis peu :P) je suis incapable de te donner une date pour les biques que je code.

      Il est très difficile de garantir une "durée de maintenance", on ne peut pas faire ça tout seul. Il faut une organisation (entreprise ou communauté) pour rendre effective cette garantie dans le temps. Et cette contrainte pousse à automatiser les processus (mises à jour, tests, rebuilds,…), ce qui est une bonne chose.

      C'est l'enjeu de cette proposition: rendre ces questions "plus visibles". Pas en définissant une mesure 100% objective mais en donnant un indicateur lisible (bien qu'imparfait - même les produits non périmés peuvent faire l'objet de rappels).

      • [^] # Re: Mouais

        Posté par  (site web personnel) . Évalué à 5.

        Et il faut avoir la possibilité de réinstaller les logiciels en question, donc d'en avoir des copies disponibles dans les bonnes versions, et de toujours savoir les installer (parce que tu peux perdre ta machine physique ou ta VM ou devoir mettre à jour ton conteneur, parce que tu dois gérer un désastre de site, etc.) Même chose pour le côté build, ça suppose que tu sais retrouver tous les composants logiciel qui sont incorporées dans tes binaires par exemple (et qu'ils sont disponibles dans les bonnes versions).

      • [^] # Re: Mouais

        Posté par  . Évalué à 4.

        Assez rapidement, le décideur se rend compte qu'un logiciel stable est moins coûteux qu'un logiciel tout récent : on privilégiera Ubuntu LTS à la dernière version, RHEL à Fedora, un noyau LTS à celui le plus récent, etc.

        … commence par lister pour une installe minimale toutes les briques utilisées,

        ensuite installe le serveur graphique

        et recommence ;)

        La liste est bien trop longue pour avoir une pertinence sur la prise de décision; et si tu te limites aux briques principales, tu risque de zapper celle qui sera à l'origine de la faille (récemment sudoedit, pas certains que sudo fasse partie des briques que tu aurais listé spontanément)

        C'est le rôle de ton admin sys de savoir ce qui tourne sur quel machines, ajouter une date théorique à coté de tel ou tel composant n'a pas de sens :
        la faille n’apparaît pas magiquement à la date indiquée, ni n'attend celle-ci pour exister.

        Tu parles des distrib LTS, justement c'est déjà le cas, on indique qu'on va gérer les mises à jours jusqu'à tel date, le faire au niveau des briques n'a pas de sens. Pareil pour les langages comme le java qui sorts des versions comme on sort des iphones, mais qui indique lesquelles bénéficieront d'un support.

        Quand tu payes un logiciel à une SSII ESN, tu as une période de garanti et/ou de support qui fait parti du contrat.

        Assez rapidement, le décideur se rend compte qu'un logiciel stable est moins coûteux qu'un logiciel tout récent :

        Non très rapidement il va se rendre compte que ne rien changer est bien plus rentable, si en plus tu le noie sous l'information il prend le risque d'être passé à coté du truc que tout le monde sait comme essentiel et qui va lui retomber sur le coin de la gueule; à partir de là 2 solutions :
        a) faire comme tout le monde
        b) ne rien faire

        Bref on a déjà au niveau macro ce que tu réclame au niveau micro; regarde about:license dans firefox rien que le nombre, dit toi que coté brique y'en a encore plus. J'ajouterai que tu veux remplacer un service informatique par un service commercial, et ça ce n'est JAMAIS une bonne idée.

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: Mouais

          Posté par  . Évalué à 2.

          Salut,

          tu veux remplacer un service informatique par un service commercial, et ça ce n'est JAMAIS une bonne idée.

          Bin si tu es dans le service commercial, si !

          En vrai, je préfère effectivement l'option d'avoir un service informatique

          Matricule 23415

        • [^] # Re: Mouais

          Posté par  (site web personnel) . Évalué à 2.

          La liste est bien trop longue pour avoir une pertinence sur la prise de décision; et si tu te limites aux briques principales, tu risque de zapper celle qui sera à l'origine de la faille (récemment sudoedit, pas certains que sudo fasse partie des briques que tu aurais listé spontanément)

          Ça permet justement de mettre en valeur l'intérêt d'une distribution GNU/Linux. Écrire "Debian 10 Buster (apache 2.4.38, PHP 7.3, mariadb 10.3)", c'est affirmer que tu suis la distribution Debian (et les mises à jour) sur ces paquets, donc que tu es autant à jour que la distribution Debian 10, ce qui est tout à fait bon jusqu'à juillet 2022 (d'où l'intérêt du lien vers la page release). Préciser PHP7.3 permet de signaler au lecteur attentif qu'il y a un choix fait de suivre la politique Debian (tenter de maintenir la version PHP toute la durée de vie de la distrib, même quand cette version n'est officiellement plus supportée, en backportant les patchs de sécurité), mais il est possible de lister PHP en-dehors de Debian 10 si on fait les mises à jour autrement (backports, sury ou autre).

          En pratique, sous réserve de mettre en place les mises à jour automatiques, pas mal de projets peuvent donc lister uniquement 1 composant : la distribution employée et sa version (bien qu'il soit plus pertinent de préciser les 2-3 principales* applications installées depuis les dépôts Debian). Celles qui nécessitent une application qui n'est pas fournie par la distribution doivent ajouter cette application au premier niveau.

  • # Déjà l'idée est top

    Posté par  . Évalué à -1.

    Salut,

    J'ai pertinenté rien que pour l'idée contenu dans le titre.
    Je ne sais pas si cette idée aboutira ni à quelle forme elle pourrait aboutir.

    Indépendamment du contenu du journal, je trouve cette idée géniale et je veux envoyer plein de bonnes ondes positives pour quelle aboutisse à quelque chose.

    Bravo de l'avoir eu ;)

  • # Tidelift

    Posté par  . Évalué à 1.

    Ca m'a fait penser à Tidelift : https://tidelift.com/.

    Le principe est que les porteurs (lifters) d'un logiciel s'engagent à tenir à jour la liste des versions maintenues ou pas et la liste des failles de sécurité avec les versions affectées et à faire gaffe aux licences.

    Les souscripteurs payent pour ce service et l'argent récolté est versé en cascade aux lifters des bibliothèques utilisées.

    Le lien avec le journal c'est que ce système est censé assurer aux souscripteurs

    • sécurité juridique : ils n'ont pas besoin de revoir les licences des dépendances des dépendances,…

    • sécurité technique : ils voient quelles versions sont maintenues ou pas

    En pratique ça reste déclaratif. C'est pas parce que le porteur dit qu'il maintient qu'il le fait vraiment. La licence libre s'applique avec ses restrictions de responsabilité. Idem pour les licences.

    J'en sais pas plus sur le business model ni sur l'algo de partage.

  • # Analogie avec un autre modèle : la sécurité du médicament

    Posté par  . Évalué à 10.

    Je vais prendre un domaine que je connais mieux que la sécurité alimentaire: la sécurité de la prescription médicamenteuse. Dans ce domaine, on a aussi quelques principes généraux :

    Entre deux médicaments équivalents, privilégier le plus ancien

    Il n'est pas rare d'avoir le choix entre deux médicaments de la même classe thérapeutique. Quand ça arrive, il faut se dire que le médicament le plus ancien a été plus prescrit, plus étudié, et que son profil de sécurité est mieux connu. Il est donc plus sûr de donner le médicament le plus ancien.

    Dans le monde logiciel, il n'est pas courant d'avoir deux logiciels exactement identiques. Cependant, les différentes versions d'un logiciel diffèrent généralement par 3 types de patchs : les correctifs de sécurité, les correctifs de bug non-sécurité, les ajouts de fonctionnalité. Tous ces patchs pouvant amener des failles de sécurité, il peut être intéressant de se limiter aux patchs strictement nécessaires, dans la mesure du possible.

    Un autre enseignement est l'effet de masse : plus un logiciel sera utilisé, plus il sera audité et plus il sera sûr. Le pire étant sans doute, dans ce domaine, le logiciel édité à la rache par une SSII pour un client unique.

    Au-delà de 3 médicaments, on ne sait plus très bien qui fait quoi

    Il est courant de prendre en charge plusieurs pathologies, surtout chez la personne âgée. Cependant, les médicaments n'ont pas une infinité de voies métaboliques d'activation/transport jusqu'à la cible/dégradation et il n'est pas rare qu'ils entrent en compétition, ce qui peut aboutir à désactiver ou suractiver un médicament, dans des proportions généralement non mesurables. Une grosse partie du travail du prescripteur consiste à choisir les maladies qu'il souhaite traiter et celles qu'il est moins risqué de laisser évoluer.

    Dans le domaine logiciel, une analogie serait que la faille d'un logiciel expose potentiellement d'autres logiciels de la même machine. Une protection repose donc sur le cloisonnement des services : de nos jours, il est tellement facile de virtualiser qu'il serait dommage de se priver de la sécurité supplémentaire apportée par la possibilité de séparer, logiciellement voire physiquement, les différents services critiques.

    Il n'existe pas de thérapeutique efficace et dépourvue d'effets secondaires

    (corollaire 1 : si ça ne donne jamais aucun effet secondaire à qui que ce soit, c'est probablement inefficace (cf. homéopathie). Corollaire 2 : ne prenez des médicaments en automédication que si vous savez vraiment ce que vous faites)

    Les systèmes vivants sont des systèmes complexes. Il n'existe pas de médicament qui n'ait qu'une seule cible biologique et qu'un seul effet possible sur cette cible. Et même s'il n'avait qu'un seul effet, il y aurait toujours le risque de dépasser l'effet recherché (un antihypertenseur qui fait trop baisser la pression artérielle et provoque des étourdissements et des chutes, un anxiolytique qui finit par endormir, etc.)

    Ce principe découle directement du fait qu'en biologie, et encore plus en médecine, on ne choisit pas son objet d'action. On ne peut pas dire à un patient "Désolé, votre corps n'est pas le bon, on ne va pas le soigner" ou "Votre foie n'est pas à la dernière version, on va d'abord faire une màj". En informatique, ce postulat est partiellement faux, mais seulement partiellement. Il est théoriquement possible d'avoir la maîtrise complète de sa machine. Théoriquement car ça suppose d'avoir accès au code source de tous les logiciels qui tournent, le temps de le lire, et les capacités de le comprendre. C'est déjà quasi-impossible rien qu'avec des logiciels libres, et ça devient impossible tout court avec des logiciels propriétaires (pas d'accès au code source).

    Une solution est de simplifier au maximum le système : "Keep it simple, stupid". Pour chaque service, chaque démon, chaque logiciel préinstallé, se demander s'il est pertinent pour le service visé, et sinon, l'éliminer impitoyablement.

    Ça, ce sont les sources. Le mouton que tu veux est dedans.

  • # c'est juste pas pareil

    Posté par  (site web personnel) . Évalué à 9.

    Je trouve l'analogie peu pertinente.
    Dans le cas de l'alimentaire, on sait ce qui provoque la péremption : développement microbien, altération chimique des composés, voire des trucs juste marketing qui ne rendent pas le produit inconsommable mais juste invendable, comme le changement de couleur.
    Tout cela est mesurable, reproductible, analysé en labo avec une marge de sécurité donnée, bref la date de péremption n'est pas donnée au hasard.
    Il existe aussi un tas d'aliments sans date de péremption, genre les fruits et légumes.

    Dans le cas d'un logiciel, il peut tourner avec des failles pendant des années sans que personne ne s'en rende compte, ou alors un hacker malin ou chanceux peut trouver une faille le lendemain de la sortie du soft. Rien de prédictible là dedans. Je me demande bien comment pourrait être calculé la date de péremption.

    Les problèmes des mises à jour dans l'industrie sont souvent dus à des vieux softs qui ne sont plus maintenus (voire qui tournent uniquement sous de vieux OS, genre la graveuse qui n'a un pilote que sous win98), ou dont la migration vers une version plus récente (d'un ERP par exemple) coûte trop cher. Dans tous les cas les admins sont bien entendu parfaitement au courant, sauf que la décision "ça coûte trop cher" n'est généralement pas prise par les admins qui se taperont quand même toute la merde si le ratio bénéfice-risque qui était correct tant qu'une faille n'était pas exploitée devient tout à coup moins rentable.

    Il existe déjà pleins d'outils pour gérer les contrats de maintenance, les dates de fin de support, etc. La comparaison avec une bouteille de lait dont on rajoute un euro au bout de trois mois pour décaler sa date de péremption trois mois plus tard a aussi ses limites.

  • # Recouvrir d’un manteau

    Posté par  . Évalué à 3.

    Bonjour,

    Je suis grammar nazi mais je me soigne, je n’interviens plus que sur deux erreurs de grammaire : « pallier à » et « avoir tord ». Tu as malheureusement commis la première faute :

    Pour pallier à ce problème

    On dit « pallier ce problème »

    Par ailleurs « pallier » c’est contourner, pratiquement mettre la poussière sous le tapis, ce n’est pas résoudre. Tu manques de prétention ! ;)

  • # Software BOM

    Posté par  . Évalué à 3.

    J'arrive après la bataille, mais ce que tu me racontes s'apparente à une Software bill of materials : une liste de composants utilisés, avec diverses informations pour retrouver leur origine, leur licence, la durée de leur support, etc. Ça vient du monde de la gestion de chaîne logistique, et moi je l'ai surtout connu en électronique : chaque composant utilisé sur un schéma est listé, avec ses caractéristiques, ses fournisseurs, et le temps pendant lequel il est garantit d'être produit et disponible, donc également le stock et l'approvisionnement. Ça permet de gérer ton histoire de « péremption » un peu mieux : ça n'est pas parce que quelque-chose est « vieux » qu'il est mauvais, c'est juste qu'il faut qu'il y ait quelqu'un « derrière » pour assurer qu'il soit disponible et avec un support.

    Je ne connais pas l'écosystème logiciel autour de ça, mais j'en ai de plus en plus entendu parler récemment, surtout lié aux attaques visant des éléments logiciels qu'on ne pensait même pas avoir inclus, comme tu l'évoques.

    • [^] # Re: Software BOM

      Posté par  . Évalué à 4.

      En français on parle de nomenclature de fabrication ou nomenclature de composants.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.