Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    De nombreux systèmes militaires américains critiques pour la sécurité utilisent désormais Linux
    De nombreux systèmes militaires américains critiques pour la sécurité utilisent désormais Linux,
    un système d'exploitation qui répond au mieux aux exigences du gouvernement ?

    L’utilisation de Linux en tant que système d'exploitation flexible, transparent et hautement sécurisé semble de plus en plus devenir un choix de premier plan au sein d'entreprises,d'institutions d'enseignement et de secteurs gouvernementaux. Avec des préoccupations de sécurité nationale qui ont atteint un niveau record aux États-Unis, il semble que la mise en œuvre de Linux pourrait effectivement répondre aux besoins critiques du gouvernement américain en matière de sécurité pour le développement et les installations d'applications.

    En raison de ses racines open source, Linux est considéré fondamentalement comme étant sécurisé, fiable et incroyablement adaptable. Linux intègre une approche de « défense en profondeur » de la sécurité, ce qui signifie que des mesures de sécurité robustes sont mises en œuvre à tous les niveaux de développement et de déploiement. Notons que Linux met l'accent sur la sécurité par la transparence.

    Pour être approuvés pour une utilisation dans des fonctions gouvernementales essentielles, les logiciels et applications doivent être certifiés pour garantir qu'ils répondent à certaines normes de sécurité. Common Criteria, FIPS 140-2 et Secure Technical Implementation Guidelines (STIG) sont trois certifications de sécurité requises par le Département de la Défense des États-Unis. Ces certifications indiquent que la technologie répond aux protocoles de sécurité normalisés et que les outils cryptographiques implémentent correctement leurs algorithmes. Linux a été certifié pour répondre à tous ces critères.
    • Common Criteria : les critères communs (CC) sont un ensemble de normes (ISO 15408) internationalement reconnu dont l'objectif est d'évaluer de façon impartiale la sécurité des systèmes et des logiciels informatiques. Également dénommé Common Criteria, ce référentiel est né d'un partenariat entre le Canada, les États-Unis et l'Europe. Grâce au cadre offert, les utilisateurs de technologies de l’information vont pouvoir utiliser des profils de protection pour spécifier les exigences fonctionnelles de sécurité attendues et les évaluateurs pourront vérifier que les produits sont bien conformes au niveau d’assurance requis.

      La mise en œuvre des Critères Communs décidée par les signataires d’un accord de reconnaissance mutuelle facilite grandement l’acceptation des certificats de sécurité des technologies de l’information émis par l’un des pays signataires. Le produit certifié en toute impartialité par une autorité compétente peut être utilisé sans nécessiter une évaluation plus poussée.

      Bien que présentant de nombreux avantages, l’application de cette norme s’avère coûteuse, difficilement compréhensible pour un non initié et souvent compliquée à mettre en œuvre. C’est la raison pour laquelle plusieurs méthodes d’utilisation ont vu le jour.
    • FIPS : FIPS (Federal Information Processing Standard) 140-2 est une norme établie par le gouvernement des États-Unis relative au chiffrement et aux conditions de sécurité à respecter dans la conception des produits informatiques destinés à traiter des données sensibles, mais non confidentielles. Cette norme vise à garantir que les produits mettent en œuvre des pratiques de sécurité saines, à savoir des méthodes et des algorithmes de chiffrement puissants et approuvés. Elle précise également comment autoriser des personnes et des processus à utiliser le produit et comment concevoir les modules et les composants de manière à sécuriser leurs interactions avec d’autres systèmes. La norme FIPS 140-2 s’applique à tout produit susceptible de stocker ou de transmettre des données sensibles. Cela inclut des matériels tels que périphériques de cryptage des liens, disques durs, disques Flash ou autres supports de stockage amovibles. Les logiciels qui chiffrent les données transmises ou stockées y sont également inclus.
    • Secure Technical Implementation Guidelines (STIG) : Il s'agit d'une méthodologie de cybersécurité pour normaliser les protocoles de sécurité au sein des réseaux, des serveurs, des ordinateurs et des conceptions logiques afin d'améliorer la sécurité globale. Une fois mis en œuvre, ces guides améliorent la sécurité des architectures logicielles, matérielles, physiques et logiques afin de réduire davantage les vulnérabilités.

      La configuration d'un ordinateur de bureau ou d'un serveur d'entreprise est un exemple où les STIG seraient utiles. La plupart des systèmes d'exploitation ne sont pas intrinsèquement sécurisés, ce qui les laisse ouverts aux criminels tels que les voleurs d'identité et les pirates informatiques. Un STIG décrit comment minimiser les attaques basées sur le réseau et empêcher l'accès au système lorsque l'attaquant s'interface avec le système, soit physiquement sur la machine soit sur un réseau. Les STIG décrivent également les processus de maintenance tels que les mises à jour logicielles et les correctifs de vulnérabilité.

      Les STIG avancés peuvent couvrir la conception d'un réseau d'entreprise, couvrant les configurations de routeurs, de pare-feu, de serveurs de noms de domaine et de commutateurs.



    Pour ces raisons, Linux n'est pas seulement un système d'exploitation qui peut servir au développement d'applications gouvernementales à sécurité critique, mais l'ouverture et la flexibilité inhérentes à Linux en font également un candidat intéressant pour les installations qui exigent le plus haut niveau de sécurité et de précision. Cependant, il convient de noter que, comme pour tout système d’exploitation, Linux doit d’abord subir des tests et un développement rigoureux supplémentaires avant d’être intégré dans l’infrastructure informatique du gouvernement américain.

    SELinux: sécurité renforcée grâce aux contrôles d'accès

    Security-Enhanced Linux, abrégé SELinux, est un Linux Security Module (LSM), qui permet de définir une politique de contrôle d'accès obligatoire aux éléments d'un système issu de Linux. SELinux embarque des concepts dont certains s'appuient sur des projets de la National Security Agency des États-Unis, parmi lesquels des recherches sur l'architecture de contrôle d'accès obligatoire (MAC) basée sur Type Enforcement qui a donné naissance au Flask. Une implémentation de référence de cette architecture a été initialement intégrée dans un système prototype SELinux pour démontrer la valeur des contrôles d'accès obligatoires flexibles et comment ces contrôles pourraient être ajoutés à un système d'exploitation. L'architecture a été reconnue pour ses avantages en termes de sécurité et a depuis été intégrée au système d'exploitation Linux traditionnel.

    SELinux impose la séparation des informations sur la base des exigences de confidentialité et d'intégrité, ce qui permet de traiter les menaces et de limiter les dommages qui pourraient être causés par des applications malveillantes ou défectueuses. Son architecture dissocie l'application de la politique d'accès et sa définition. Il permet notamment de classer les applications d'un système en différents groupes, avec des niveaux d'accès plus fins. Il permet aussi d'attribuer un niveau de confidentialité pour l'accès à des objets systèmes, comme des descripteurs de fichiers, selon un modèle de sécurité multiniveau (MLS pour Multi level Security).

    Au départ, SELinux était le sujet de controverse. Nombreuses étaient les personnes qui se disaient préoccupées par l'insertion de code NSA dans Linux, malgré sa transparence. Les rumeurs selon lesquelles la NSA incorporait des portes dérobées et une technologie capable de compromettre la confidentialité des utilisateurs ont proliféré pendant de nombreuses années. Toutefois, cette vague de controverse semble s'être calmée et SELinux est désormais reconnu pour l'amélioration de la sécurité globale de Linux.

    Open source

    Cette dernière décennie, le gouvernement américain s'est vu utilisé de plus en plus de logiciels open source pour déployer de manière économique des technologies avancées hautement sécurisées. Le 8 août 2016, le DSI de la Maison-Blanche a publié une politique fédérale sur le code source qui appelle à la création, au partage et à l'adaptation de nouveaux logiciels à l'aide de méthodes open source afin de tirer parti d'un code « sécurisé, fiable et efficace pour objectifs nationaux ».

    Le département américain de la Défense reconnaît les principaux avantages associés au développement open source et fait confiance à Linux comme système d'exploitation. En fait, l'armée américaine est la plus grande base installée unique pour RedHat Linux et la flotte de sous-marins nucléaires de l'US Navy fonctionne sur Linux, y compris leurs systèmes de sonar. De plus, le ministère de la Défense a récemment recruté Red Hat, Inc., le plus grand fournisseur mondial de solutions open source, pour aider à améliorer les opérations de l'escadron et la formation au pilotage.

    Les défenseurs des logiciels propriétaires ont suscité un débat sur la pertinence d'utiliser Linux en matière de défense nationale. Ils estiment que la disponibilité du code source pour les applications open source et les origines inconnues du code peuvent conduire à placer délibérément du contenu subversif dans des codes critiques, mettant en danger la sécurité du pays tout entier.

    Cette argumentation ne prend pas en considération le fait que tout système choisi devrait être ajusté et retravaillé pour correspondre aux besoins informatiques uniques et critiques du gouvernement. Cependant, en supposant que le gouvernement se tourne vers Linux pour les applications de défense nationale, les défenseurs de l'open source estiment que la disponibilité du code source est exactement ce qui fait de Linux le choix évident. Linux et d'autres applications open source offrent la liberté de personnaliser des programmes pour répondre à des exigences spécifiques, une liberté qui n'existe pas vraiment au sein des systèmes propriétaires d'après eux. Si la sécurité fournie par une installation particulière est insuffisante, elle peut être modifiée pour garantir les niveaux de protection les plus élevés.

    De plus, le gouvernement des États-Unis, en particulier le ministère de la Défense, a des normes extrêmement élevées en matière de sécurité et de confidentialité. Par conséquent, tout code choisi pour les systèmes gouvernementaux ou militaires doit être certifié selon Common Criteria, FIPS 140-2 et Secure Technical Implementation Guidelines (STIG) et subir d'innombrables heures d'analyse et d'évaluation de la vulnérabilité avant même qu'il puisse être pris en compte pour les tests.

    Sources : Common Criteria, NSA (Documentation SELinux) , politique fédérale sur le code source, recrutement de Red Hat par le ministère de la Défense

    Et vous ?

    L'open source pour des infrastructures critiques du gouvernement, une bonne idée ?
    La France gagnerait-elle à s'en inspirer ?
    Que pensez-vous de l'utilisation de l'open source dans les services gouvernementaux ?
    Quelles leçons peut-on tirer des échecs précédents ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Expert éminent sénior
    La France s'en inspire déjà avec le vieux système de la gendarmerie, toujours fonctionnel, et qui répond à peu près au même cahier des charges. On peut avoir des vraies questions?
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  3. #3
    Membre éclairé
    L'open source pour des infrastructures critiques du gouvernement, une bonne idée ?
    Oui , bien sur !
    La France gagnerait-elle à s'en inspirer ?
    Oui et ne pas créer des cloud chimérique
    Que pensez-vous de l'utilisation de l'open source dans les services gouvernementaux ?
    Il faut le faire , l ' encourager
    Quelles leçons peut-on tirer des échecs précédents ?
    Évité autant que possible les environnements privateurs

  4. #4
    Membre extrêmement actif
    De nombreux systèmes militaires américains critiques pour la sécurité utilisent désormais Linux, un système d'exploitation qui répond au mieux aux exigences du gouvernement ?

    Noooooooooooon? Incroyable!

    L'armée américaine ne veut pas de l'OS Win10 spécialisé dans l'espionnage de ses utilisateurs?

    D'accord pour que le monde entier soit espionné via l'OS Win10 mais cela ne doit pas s'appliquer à l'armée américaine... On les comprend, c'est logique!

    Pensée émue pour tous les gouvernements du monde qui ont cru bon d'exiger de M$ un Win10 adapté qui ne les espionne pas. Apparemment, cette version adaptée n'est pas assez "sûre" pour les USA... Serait-ce une preuve que finalement Win10 espionne toujours les gouvernements "amis" mais... de manière plus discrète?

  5. #5
    Membre chevronné
    On peut mettre tous les systèmes que l'on veut, si on ne mets pas le budget qu'il faut (l'informatique est souvent le premier à subir des "coupes") dans la maintenance, l'administration (et et la formation des utilisateurs (puisque quasiment toutes les catastrophes arrivent par eux), ça deviendra une passoire dans le temps.

  6. #6
    Membre éclairé
    C'est surtout aussi que Windows c'est pas un os adapté pour des environnement embarqué,
    du windows pour la commercial chargé du recrutement des soldats oui pourquoi pas mais du windows dans un tank c'est une aberration, l'os consomme beaucoup de trop de ressource et c'est pas un un os temps réel.
    en France je suis sidéré de voir des bsod dans les écrans de la sncf en gare ou dans les distributeurs de billet... non pas que linux n'a pas de kernel panic mais juste pourquoi faire tourner ces dispositif sous windows ? pourquoi avoir du windows xp dans un distributeur de billet...

  7. #7
    Expert éminent
    Je suis largement en faveur de Linux, mais je pense que l'open source peut être une faiblesse importante.

    Quelque soient les règles de validation de code, la majeure partie du programme sera forcement décrite par la communauté, et validé par celle ci. Or nous voyons aujourd'hui sur les réseaux sociaux que des communautés fictives de plusieurs centaines de personnes sont mise en place patiemment pour gagner la confiance des gens, et leur distiller des informations spécifiques en temps voulu.

    Comment ne pas imaginer le même scénario impliquant quelques dizaines de développeurs de part le monde.
    Mon profil linked in

    Chez Adaptive, nous cherchons un dev python / Cloud sur Toulouse sud.
    Produit fun et belle refonte du code.

  8. #8
    Membre extrêmement actif
    Citation Envoyé par calvaire Voir le message

    en France je suis sidéré de voir des bsod dans les écrans de la sncf en gare ou dans les distributeurs de billet... non pas que linux n'a pas de kernel panic mais juste pourquoi faire tourner ces dispositif sous windows ? pourquoi avoir du windows xp dans un distributeur de billet...
    Il y a du Windows partout (même dans les distributeurs à billets des banques) pour la bonne et simple raison qu'il est plus facile de trouver du personnel connaissant Windows que Linux et consort...

  9. #9
    Expert confirmé
    Citation Envoyé par pmithrandir Voir le message
    Je suis largement en faveur de Linux, mais je pense que l'open source peut être une faiblesse importante.

    Quelque soient les règles de validation de code, la majeure partie du programme sera forcement décrite par la communauté, et validé par celle ci. Or nous voyons aujourd'hui sur les réseaux sociaux que des communautés fictives de plusieurs centaines de personnes sont mise en place patiemment pour gagner la confiance des gens, et leur distiller des informations spécifiques en temps voulu.

    Comment ne pas imaginer le même scénario impliquant quelques dizaines de développeurs de part le monde.
    Tu peux avoir le même scénario dans le proprio et là c'est limite pire car personne ne pourra relire le code.

    De plus, un type qui code pour l'open source n'est pas forcement moins ou plus compétent que pour faire du proprio. Perso, je fais les deux, ça me rend pas moins bon quand je fais de l'open source.

  10. #10
    Membre à l'essai
    et BSD pour de la sécu
    Bonjour tout le monde,

    pour tout ce qui est poste de travail Linux semble pour moi une bonne idée, mais pour tout ce qui est serveur + sécurité, on ne fait pas mieux que BSD non ?

  11. #11
    Expert éminent
    Citation Envoyé par Zefling Voir le message
    Tu peux avoir le même scénario dans le proprio et là c'est limite pire car personne ne pourra relire le code.

    De plus, un type qui code pour l'open source n'est pas forcement moins ou plus compétent que pour faire du proprio. Perso, je fais les deux, ça me rend pas moins bon quand je fais de l'open source.
    Attention, je ne dis pas que le proprio est innataquable... mais imagine une puissance étrangère qui essaye de placer assez de salariés au sein d'une société de sécurité... elle risque d'avoir du mal a éviter que certains collègues non soudoyés n'aille voir ce qu'il se passe. Et introduire plus de 2 personnes dans une équipe de 8 personnes, c'est quand même assez complexe je pense, rien que parce que la diversité des profil est une sorte de norme aujourd'hui.
    Ajoute a cela le fait que les personnes sont salariées, donc qu'elles ont un risque non négligeable sur leur futur.... la ou un dev open source peut agir de son pays sans risque.
    Mon profil linked in

    Chez Adaptive, nous cherchons un dev python / Cloud sur Toulouse sud.
    Produit fun et belle refonte du code.

  12. #12
    Expert confirmé
    Citation Envoyé par pmithrandir Voir le message
    la ou un dev open source peut agir de son pays sans risque.
    Sur un projet à forte visibilité, ça me semble improbable, car les merge/pull requests sont relues. Ou alors, il faut que le type soit dans l'équipe principale du projet et réussissent à ce jamais se faire faire relire son code. Ça me semble quand même compliqué. Je dis pas que c'est impossible, mais ça finira très probablement par se voir.

    Après sur un projet open source comme il en existe beaucoup, maintenu par une seule personne, là on peut imaginer tout et n'importe quoi.

  13. #13
    Expert éminent sénior
    il est plus difficille d'attaquer du propriétaire, mais la vraie faille, c'est que si on en trouve une, la probablitié de correction est super faible. Alors que sur un système connu de tous, il y a toujours des gens pour remonter les problèmes. Aucun système n'est sur à 100%, mais Linux(ou BSD, en effet) sont plus surs pour cette simple raison.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  14. #14
    Membre expert
    Pour trouver des failles encore faut-il les chercher. La sécurité de Linux ne vient-elle pas aussi du fait que Linux serait moins ciblé par les pirates que Windows ? La sécurité de Linux ne serait-elle pas avant tout une sécurité par l'ignorance (et le mépris) ?
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  15. #15
    Membre éclairé
    Citation Envoyé par air-dex Voir le message
    Pour trouver des failles encore faut-il les chercher. La sécurité de Linux ne vient-elle pas aussi du fait que Linux serait moins ciblé par les pirates que Windows ? La sécurité de Linux ne serait-elle pas avant tout une sécurité par l'ignorance (et le mépris) ?
    non
    La sécurité de Linux vient du faite que ceux qui l'utilisent connaisse un minimum l'informatique et évite les pieges bete et méchant, aucun OS ne peut protéger un utilisateur en admin qui ouvre un .exe

    Apres sous windows tu as souvent des failles avec des technos externe a l'os mais très utilisé a leurs époque (ActiveX, Applet java, adobe flash...) sous Linux personne n'utilise ces technos.
    Installer flash sous linux il me semble que c'est pas simple (adobe ne supporter pas cette plateforme, il faut faire 2-3 bidouille dans mes souvenir)

    Sous Linux aussi quand tu installe un programme tu installe que ce programme, tu n'a pas une case a décocher en bas de la fenetre popur pas installer BoostMyPc/SuperAntivirus/BonPlanAds/BarreMachin dans ton navigateur...etc pleins de programmes parasites qui s'installe sous windows si tu fait pas gaffe.
    L'installation de Flash sous windows propose d'ailleur d'installer google chrome/Mcaffee... le mec déja installe du caca (flash) mais en plus mets une petite couche de vomi dessus (mcafee/google chrome)
    ce sont des programmes gourmand en ressource qui servent a rien, sous linux t'a firefox qui tourne très bien et pas besoin d'antivirus.

  16. #16
    Membre éclairé
    Bonne réponse , mais dogmatique . GNU/Linux est " permissif " , je m ' explique , tu peu tout à fait utilisé chrome , mais celui-ci est conteneurisé via app armor qui limite un temps soit peu les risques , les app et les bibliothèques ont besoin d ' un admin qui gère aussi la maintenance système , ce n’est pas MacOs X ou un Microsoft Windows quelconque , si tu es parano , tu peux compiler les applications , mais l ' humain reste la faiblesse

  17. #17
    Membre régulier
    Ils ont eu besoin de près de deux décennies pour réaliser qu'un système de concept ouvert sera toujours plus sûr qu'un autre propriétaire.

  18. #18
    Membre habitué
    Open bar
    Dire que la défense nationale à signé cette cochonnerie avec M$ le ministère ferait mieux de faire un vrai calcul sur l'opportunité d'embaucher de véritables pros de la sécurité et une équipe de développement plutôt que de paumer un fric de dingue en sous-traitant à cette société.
    Je me souviens du militaire présenté comme "responsable" de la sécurité numérique parlant de "Black Door" je me demande encore à quelle point sa porte noire est large à cet abruti. Pourtant il en avait des galons ce mec.

  19. #19
    Expert éminent
    Citation Envoyé par Zefling Voir le message
    Sur un projet à forte visibilité, ça me semble improbable, car les merge/pull requests sont relues. Ou alors, il faut que le type soit dans l'équipe principale du projet et réussissent à ce jamais se faire faire relire son code. Ça me semble quand même compliqué. Je dis pas que c'est impossible, mais ça finira très probablement par se voir.

    Après sur un projet open source comme il en existe beaucoup, maintenu par une seule personne, là on peut imaginer tout et n'importe quoi.

    Je suis globalement d accord avec ça.
    Mais justement il me parait plus simple de fournir 10 pro ultra qualifié a une equipe open sourve qui sera bien content de les voir arriver... qui au boit de 2 ou 3 ans auront une grande partie des clefs de la place.

    Et qui faindrons la bonne fois si une des back door est Trouvée.

    Rappellez vous du bug massif sur le protocole ssl sur une verification de taille d input invalide. Il a fallu combien d année pour le trouver. Ce genre de code peut Je pense être ajouté de manière discrète et intéressée par ce genre d équipe.

    Après je ne reprend ici qu une chose que l.on voit dans les associations un peu politique. Quand tu as une armée de bénévoles qui se pointent.. tu es content. Mais tu regarde aussi si ce n est pas le parti politique du coin qui essaye de te phagocyter.
    Mon profil linked in

    Chez Adaptive, nous cherchons un dev python / Cloud sur Toulouse sud.
    Produit fun et belle refonte du code.

  20. #20
    Membre du Club
    Linux moins sensible au hack que Windows... je ne dirais pas cela !

    Par contre, qu'il y a moins de tentative de hack car moins de cible facile...

###raw>template_hook.ano_emploi###