Ou l’on apprend que l’ultraliberalisme ne se sent plus de limite. On savait qu’il consistait à réduire l’état à une supposée partie irréductible de défense nationale. On apprend de la main du ministre que même la sécurité informatique est considérée comme inaccessible par cet état. Ils se contenteront donc de tenter de chiffrer certaines communications qui pourraient ne pas encore avoir été lues.
Mouais, j'ai du mal à détecter une quelconque idéologie libérale dans la réponse du ministère, mais plutôt un abandon argumenté de l'idée de contrôler la chaine logicielle, y compris pour les applications militaires. OK, avec du logiciel libre, tu as le code, mais qui va auditer le code? Entre les applications métier, les logiciels dédiés au matériel militaire, et toute l'administration et les services de communication, il doit y avoir des milliards de lignes de code à auditer, des milliers de logiciels à recompiler et à redistribuer… Sans compter que, pour être tout à fait pragmatique, auditer la chaîne logicielle ne te met pas à l'abri de failles matérielles qui sont encore plus difficiles à auditer, surtout quand la France n'a pas la capacité industrielle de produire ce matériel.
Du coup, la solution du logiciel propriétaire "standard" est un constat d'échec, mais ça serait se voiler les yeux de croire qu'en passant à du logiciel libre la situation serait plus contrôlée du point de vue de la sécurité.
Le reste (passage progressif au logiciel libre, désengagement vis-à-vis des grands industriels de l'informatique…) est le discours ambigü classique des gouvernements successifs, qui se donnent des objectifs idéalistes mais qui ne se donnent pas les moyens de les atteindre, avec en toile de fond l'idée que personne parmi les technocrates décideurs ne comprend réellement les enjeux.
OK, avec du logiciel libre, tu as le code, mais qui va auditer le code? Entre les applications métier, les logiciels dédiés au matériel militaire, et toute l'administration et les services de communication, il doit y avoir des milliards de lignes de code à auditer, des milliers de logiciels à recompiler et à redistribuer…
Cet argument, qui est une reformulation du même argument exprimé par le ministère des armées, ne me parait pas pertinent. Tout d'abord, un audit ne porte par forcément sur la totalité du code et auditer ne serait-ce que 1% du code, c'est mieux que ne rien savoir du code. Le coût que représente un audit serait très certainement amorti par le gain fait sur les licences.
Les logiciels ne sont pas forcément à recompiler ou à redistribuer. La plupart des logiciels libres pourraient être utilisés sans modification.
un audit ne porte par forcément sur la totalité du code
Quand on parle d'applications militaires, je ne vois pas l'intérêt de n'auditer que des bouts par ci par là un peu au hasard.
auditer ne serait-ce que 1% du code, c'est mieux que ne rien savoir du code
Tu as des exemples? Par exemple, disons que tu as des ressources pour auditer 1% du code de ton logiciel de traitement de texte. Tu vas auditer, par exemple, la gestion de la mémoire tampon, pour des raisons de sécurité (tu ne veux pas que du texte effacé reste en RAM, etc). Tu fais ça dans MS Word (on va dire que tu as négocié avec Microsoft pour avoir accès à 1% du code) ou dans Libre Office. Ça t'a avancé à quoi? Tu penses que tu as gagné un peu en sécurité? Par exemple, tu te rends compte que MS Word, pour cette activité spécifique, gère mieux la mémoire. Du coup, tu bascules tout ton parc sous Word?
Les logiciels ne sont pas forcément à recompiler ou à redistribuer
Là, idem, en termes de sécurité, je vois mal installer les paquets par défaut d'une distribution grand public sur un serveur militaire qui gère des informations critiques. Tu te fais ch… à auditer le code, tu veux être certain que c'est bien ce code qui tourne sur tes machines, non? La sécurité militaire, c'est censé être un truc sérieux.
Posté par nico4nicolas .
Évalué à 5.
Dernière modification le 15 janvier 2020 à 14:59.
Quand on parle d'applications militaires,
Un logiciel de traitement de texte n'est pas un logiciel spécifiquement militaire.
je ne vois pas l'intérêt de n'auditer que des bouts par ci par là un peu au hasard.
C'est une pratique très fréquente lors des audits. Il est impossible d'auditer de façon exhaustive donc on va prendre des morceaux choisis. C'est vrai pour du code mais aussi pour des processus de fabrication.
Tu as des exemples?
Non, c'était une opinion et, pourtant, je sais que le mieux est l'ennemi du bien. L'avantage que je vois c'est que le logiciel libre (ou open source) permet un audit sur la partie de code choisie par l'auditeur. Dans le cas d'un logiciel propriétaire, l'ouverture du code se ferait d'un commun accord (et peut être avec un dédommagement financier). C'est à dire que si l'auditeur veut auditer 2% du code, ou un autre morceau de code, l'auditeur est libre comme le code.
Par contre, voici un extrait de la circulaire que j'ai mis en lien dans mon précédent message :
Une règle simple à appliquer serait de réinjecter systématiquement de 5 à 10% des coûts de licences évités. Cela permet de contribuer de manière utile dans tous les cas, de ne pas mettre en risque le gain économique d'usage du libre, sans pour autant faire systématiquement une étude poussée de gain complet.
En participant au développement d'un logiciel, une certain maitrise peut être acquise et les parties développées sont connues.
je vois mal installer les paquets par défaut d'une distribution grand public sur un serveur militaire qui gère des informations critiques. Tu te fais ch… à auditer le code, tu veux être certain que c'est bien ce code qui tourne sur tes machines, non?
Oui, tu as raison en ce qui concerne la compilation. En ce qui concerne la distribution, je n'ai pas idée mais la circulaire interministérielle contient le §3.3.1.2. "Un déploiement de logiciel sur une grande infrastructure" :
Un exemple d'usage des logiciels libres dans un système d’information critique d’une direction ministérielle a permis de diviser par 10 les coûts de fonctionnement des applicatifs. Cette réduction nette des coûts a été obtenue en mettant en place un marché de maintenance dans des conditions très strictes (délais de 48h de résolution…) sur plus de 100 souches logicielles.
Quand il s'agit de postes utilisateurs, le déploiement de nouvelles briques ou de mises à jours peut se faire de manière homogène sur l'ensemble du parc, sans coût particulier (pas de rachats de licences, pas d’achat de licence évolutive), ce qui facilite le maintien de l'homogénéité du parc et induit une baisse des coûts de support utilisateurs et une augmentation de la qualité.
Un exemple ne pouvant servir de règle, il doit rester ce qu'il est : un exemple dont les détails nous sont inconnus.
Posté par Renault (site web personnel) .
Évalué à 5.
Dernière modification le 15 janvier 2020 à 15:52.
Un logiciel de traitement de texte n'est pas un logiciel spécifiquement militaire.
Non, et alors ? Si c'est utilisé par l'armée, il faut plus de garanties que pour le grand public quand même. Si Word est troué et permet de fuiter les documents militaires stratégiques élaborés ou consultés avec Word, c'est un problème.
Pour prendre un autre exemple, le téléphone du président de la République n'est pas un outil militaire. Mais de par les échanges effectués avec, il est sensible et les applications employées doivent exiger plus que pour le grand public.
C'est une pratique très fréquente lors des audits. Il est impossible d'auditer de façon exhaustive donc on va prendre des morceaux choisis. C'est vrai pour du code mais aussi pour des processus de fabrication.
Cela dépend, et cela n'est valide que si la qualité est assez homogène au sein du produit. Pour un logiciel de cette taille cela me paraît assez improbable.
Et beaucoup d'audits sont exhaustifs, sinon ils n'ont pas d'intérêts non plus.
Je trouvais l'expression "application militaire" utilisée dans le précédent message portait à confusion. Ce que tu écris me parait beaucoup plus explicite : "utilisé par l'armée". Je n'ai pas voulu insinuer que le logiciel n'avait pas besoin d'offrir des garanties sécuritaires.
Et beaucoup d'audits sont exhaustifs, sinon ils n'ont pas d'intérêts non plus.
Mon expérience personnelle (par définition très limitée) ne m'a pas donné à voir beaucoup d'audits exhaustifs. Par contre, j'ai souvent vu des auditeurs demander de tout montrer, de tirer sur un fil, d'inspecter ce qui en remontait et de recommencer avec un autre fil.
# Sécurité hors de portée
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 5.
Ou l’on apprend que l’ultraliberalisme ne se sent plus de limite. On savait qu’il consistait à réduire l’état à une supposée partie irréductible de défense nationale. On apprend de la main du ministre que même la sécurité informatique est considérée comme inaccessible par cet état. Ils se contenteront donc de tenter de chiffrer certaines communications qui pourraient ne pas encore avoir été lues.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Sécurité hors de portée
Posté par arnaudus . Évalué à 8.
Mouais, j'ai du mal à détecter une quelconque idéologie libérale dans la réponse du ministère, mais plutôt un abandon argumenté de l'idée de contrôler la chaine logicielle, y compris pour les applications militaires. OK, avec du logiciel libre, tu as le code, mais qui va auditer le code? Entre les applications métier, les logiciels dédiés au matériel militaire, et toute l'administration et les services de communication, il doit y avoir des milliards de lignes de code à auditer, des milliers de logiciels à recompiler et à redistribuer… Sans compter que, pour être tout à fait pragmatique, auditer la chaîne logicielle ne te met pas à l'abri de failles matérielles qui sont encore plus difficiles à auditer, surtout quand la France n'a pas la capacité industrielle de produire ce matériel.
Du coup, la solution du logiciel propriétaire "standard" est un constat d'échec, mais ça serait se voiler les yeux de croire qu'en passant à du logiciel libre la situation serait plus contrôlée du point de vue de la sécurité.
Le reste (passage progressif au logiciel libre, désengagement vis-à-vis des grands industriels de l'informatique…) est le discours ambigü classique des gouvernements successifs, qui se donnent des objectifs idéalistes mais qui ne se donnent pas les moyens de les atteindre, avec en toile de fond l'idée que personne parmi les technocrates décideurs ne comprend réellement les enjeux.
[^] # Re: Sécurité hors de portée
Posté par nico4nicolas . Évalué à 6.
Cet argument, qui est une reformulation du même argument exprimé par le ministère des armées, ne me parait pas pertinent. Tout d'abord, un audit ne porte par forcément sur la totalité du code et auditer ne serait-ce que 1% du code, c'est mieux que ne rien savoir du code. Le coût que représente un audit serait très certainement amorti par le gain fait sur les licences.
Les logiciels ne sont pas forcément à recompiler ou à redistribuer. La plupart des logiciels libres pourraient être utilisés sans modification.
Si on se fie à la circulaire interministérielle sur l'usage du logiciel libre dans l'administration, on y trouve davantage d'avantages que d'inconvénients. A noter également la production chaque année du socle interministériel des logiciels libres donc un début d'audit est réalisé.
[^] # Re: Sécurité hors de portée
Posté par arnaudus . Évalué à 3.
Quand on parle d'applications militaires, je ne vois pas l'intérêt de n'auditer que des bouts par ci par là un peu au hasard.
Tu as des exemples? Par exemple, disons que tu as des ressources pour auditer 1% du code de ton logiciel de traitement de texte. Tu vas auditer, par exemple, la gestion de la mémoire tampon, pour des raisons de sécurité (tu ne veux pas que du texte effacé reste en RAM, etc). Tu fais ça dans MS Word (on va dire que tu as négocié avec Microsoft pour avoir accès à 1% du code) ou dans Libre Office. Ça t'a avancé à quoi? Tu penses que tu as gagné un peu en sécurité? Par exemple, tu te rends compte que MS Word, pour cette activité spécifique, gère mieux la mémoire. Du coup, tu bascules tout ton parc sous Word?
Là, idem, en termes de sécurité, je vois mal installer les paquets par défaut d'une distribution grand public sur un serveur militaire qui gère des informations critiques. Tu te fais ch… à auditer le code, tu veux être certain que c'est bien ce code qui tourne sur tes machines, non? La sécurité militaire, c'est censé être un truc sérieux.
[^] # Re: Sécurité hors de portée
Posté par nico4nicolas . Évalué à 5. Dernière modification le 15 janvier 2020 à 14:59.
Un logiciel de traitement de texte n'est pas un logiciel spécifiquement militaire.
C'est une pratique très fréquente lors des audits. Il est impossible d'auditer de façon exhaustive donc on va prendre des morceaux choisis. C'est vrai pour du code mais aussi pour des processus de fabrication.
Non, c'était une opinion et, pourtant, je sais que le mieux est l'ennemi du bien. L'avantage que je vois c'est que le logiciel libre (ou open source) permet un audit sur la partie de code choisie par l'auditeur. Dans le cas d'un logiciel propriétaire, l'ouverture du code se ferait d'un commun accord (et peut être avec un dédommagement financier). C'est à dire que si l'auditeur veut auditer 2% du code, ou un autre morceau de code, l'auditeur est libre comme le code.
Par contre, voici un extrait de la circulaire que j'ai mis en lien dans mon précédent message :
En participant au développement d'un logiciel, une certain maitrise peut être acquise et les parties développées sont connues.
Oui, tu as raison en ce qui concerne la compilation. En ce qui concerne la distribution, je n'ai pas idée mais la circulaire interministérielle contient le §3.3.1.2. "Un déploiement de logiciel sur une grande infrastructure" :
Un exemple ne pouvant servir de règle, il doit rester ce qu'il est : un exemple dont les détails nous sont inconnus.
[^] # Re: Sécurité hors de portée
Posté par Renault (site web personnel) . Évalué à 5. Dernière modification le 15 janvier 2020 à 15:52.
Non, et alors ? Si c'est utilisé par l'armée, il faut plus de garanties que pour le grand public quand même. Si Word est troué et permet de fuiter les documents militaires stratégiques élaborés ou consultés avec Word, c'est un problème.
Pour prendre un autre exemple, le téléphone du président de la République n'est pas un outil militaire. Mais de par les échanges effectués avec, il est sensible et les applications employées doivent exiger plus que pour le grand public.
Cela dépend, et cela n'est valide que si la qualité est assez homogène au sein du produit. Pour un logiciel de cette taille cela me paraît assez improbable.
Et beaucoup d'audits sont exhaustifs, sinon ils n'ont pas d'intérêts non plus.
[^] # Re: Sécurité hors de portée
Posté par nico4nicolas . Évalué à 5.
Je trouvais l'expression "application militaire" utilisée dans le précédent message portait à confusion. Ce que tu écris me parait beaucoup plus explicite : "utilisé par l'armée". Je n'ai pas voulu insinuer que le logiciel n'avait pas besoin d'offrir des garanties sécuritaires.
Mon expérience personnelle (par définition très limitée) ne m'a pas donné à voir beaucoup d'audits exhaustifs. Par contre, j'ai souvent vu des auditeurs demander de tout montrer, de tirer sur un fil, d'inspecter ce qui en remontait et de recommencer avec un autre fil.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.