IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

Sécurité Discussion :

Il est urgent de renforcer la sécurité de la mémoire dans les produits logiciels, selon la CISA


Sujet :

Sécurité

  1. #1
    Communiqués de presse

    Femme Profil pro
    Traductrice Technique
    Inscrit en
    Juin 2023
    Messages
    1 564
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France

    Informations professionnelles :
    Activité : Traductrice Technique

    Informations forums :
    Inscription : Juin 2023
    Messages : 1 564
    Points : 109 502
    Points
    109 502
    Par défaut Il est urgent de renforcer la sécurité de la mémoire dans les produits logiciels, selon la CISA
    Il est urgent de renforcer la sécurité de la mémoire dans les produits logiciels, selon la CISA, l'utilisation d'un langage de programmation à sécurité mémoire comme Rust serait une solution.

    Depuis plus d'un demi-siècle, les ingénieurs en logiciel savent que des acteurs malveillants peuvent exploiter une catégorie de défauts logiciels appelés "vulnérabilités de sécurité de la mémoire" pour compromettre des applications et des systèmes. Au cours de cette période, les experts ont à maintes reprises mis en garde contre les problèmes liés aux failles de sécurité de la mémoire. Un code à mémoire non sécurisée a même entraîné une panne majeure de l'internet en 1988.

    Quelle est l'ampleur du problème de l'insécurité de la mémoire ? Dans un billet de blog, Microsoft indique que "~70 % des vulnérabilités auxquelles Microsoft attribue chaque année un CVE [Common Vulnerability and Exposure] continuent d'être des problèmes de sécurité de la mémoire". De même, Google indique que "le projet Chromium constate qu'environ 70 % de nos bogues de sécurité graves sont des problèmes de sécurité de la mémoire". Mozilla signale que dans une analyse des vulnérabilités de sécurité, "sur les 34 bogues critiques/élevés, 32 étaient liés à la mémoire".

    Ces vulnérabilités ne sont pas théoriques. Les attaquants les utilisent pour commettre des attaques contre des personnes réelles. Par exemple, l'équipe Project Zero de Google a analysé les vulnérabilités qui ont été utilisées dans la nature par des attaquants avant d'être signalées aux fournisseurs de logiciels (également appelées "zero-day vulnerabilities"). Elle indique que "sur les 58 [vulnérabilités de ce type] de l'année, 39, soit 67 %, étaient des vulnérabilités liées à la corruption de la mémoire". Citizen Lab a découvert des logiciels espions utilisés contre des organisations de la société civile qui exploitaient des failles dans la sécurité de la mémoire.

    Dans quel autre secteur le marché tolérerait-il pendant des décennies des dangers aussi graves et bien compris pour les utilisateurs des produits ?


    Au fil des ans, les ingénieurs en logiciel ont inventé de nombreuses solutions intelligentes, mais finalement insuffisantes, pour atténuer cette catégorie de vulnérabilité, notamment des outils tels que la randomisation de la mémoire et les techniques de sandboxing qui réduisent l'impact, et des outils d'analyse statique et dynamique du code qui réduisent l'occurrence. En plus de ces outils, les organisations ont consacré beaucoup de temps et d'argent à la formation de leurs développeurs pour qu'ils évitent les opérations de mémoire dangereuses. Il existe également plusieurs efforts parallèles visant à améliorer la sécurité de la mémoire du code C/C++ existant. Malgré ces efforts (et les coûts associés en termes de complexité, de temps et d'argent), l'insécurité de la mémoire a été le type le plus courant de défaut de sécurité des logiciels pendant des décennies.

    Il existe cependant quelques domaines que tout éditeur de logiciels devrait étudier. Tout d'abord, il existe des mesures prometteuses d'atténuation de la sécurité de la mémoire au niveau du matériel. Le projet de recherche CHERI (Capability Hardware Enhanced RISC Instructions) utilise des processeurs modifiés pour donner aux langages à mémoire non sécurisée comme C et C++ une protection contre de nombreuses vulnérabilités largement exploitées. Une autre technologie assistée par le matériel se présente sous la forme d'extensions de marquage de la mémoire (MTE) disponibles dans certains systèmes. Bien que certaines de ces mesures d'atténuation basées sur le matériel soient encore en train de passer de la recherche à l'expédition de produits, de nombreux observateurs pensent qu'elles deviendront des éléments importants d'une stratégie globale visant à éliminer les vulnérabilités liées à la sécurité de la mémoire.

    Deuxièmement, les entreprises devraient se pencher sur les langages de programmation à sécurité mémoire. La plupart des langages de programmation modernes autres que C/C++ sont déjà sans danger pour la mémoire. Ces langages gèrent la mémoire de l'ordinateur de manière à ce que le programmeur ne puisse pas introduire de vulnérabilités en matière de sécurité de la mémoire. Contrairement à d'autres mesures d'atténuation disponibles qui nécessitent un entretien constant (sous la forme de développement de nouvelles défenses, d'analyse des vulnérabilités ou de travail humain) aucun travail ne doit être effectué une fois que le code est écrit dans un langage de programmation à mémoire sécurisée pour le maintenir à l'abri des failles de la mémoire.

    Ce qui manquait jusqu'à il y a quelques années, c'était un langage aussi rapide que le C/C++ avec des garanties intégrées de sécurité de la mémoire. En 2006, un ingénieur logiciel de Mozilla a commencé à travailler sur un nouveau langage de programmation appelé Rust. La version 1.0 de Rust a été officiellement annoncée en 2015. Depuis, plusieurs grands éditeurs de logiciels ont commencé à l'utiliser dans leurs systèmes, notamment Amazon, Facebook, Google, Microsoft, Mozilla et bien d'autres. Il est également pris en charge dans le développement du noyau Linux.

    Différents produits nécessiteront des stratégies d'investissement différentes pour atténuer les codes dangereux pour la mémoire. L'équilibre entre les mesures d'atténuation C/C++, les mesures d'atténuation matérielles et les langages de programmation sans risque pour la mémoire peut même varier entre les produits d'une même entreprise. Aucune approche ne résoudra tous les problèmes pour tous les produits. La seule chose que les fabricants de logiciels ne peuvent pas faire, c'est ignorer le problème. L'industrie du logiciel ne doit pas rester inactive pendant encore une décennie.

    Nom : 1.PNG
Affichages : 7762
Taille : 519,7 Ko

    Le livre blanc "Secure by Design" de la CISA présente trois principes fondamentaux pour les fabricants de logiciels : s'approprier les résultats en matière de sécurité des clients, adopter une transparence radicale et diriger les transformations en matière de sécurité depuis le sommet de l'organisation. Les solutions au problème de l'insécurité de la mémoire intégreront ces trois principes.

    La CISA invite les fabricants de logiciels à faire de la réduction et de l'élimination des vulnérabilités de la sécurité de la mémoire de leurs gammes de produits un objectif d'entreprise de premier plan. Pour démontrer cet engagement, les entreprises peuvent publier une "feuille de route sur la sécurité de la mémoire" qui comprend des informations sur la manière dont elles modifient leur cycle de développement logiciel (SDLC) pour atteindre cet objectif. Une feuille de route peut inclure des détails tels que la date à partir de laquelle elle construira de nouveaux produits ou composants dans un langage de programmation sans danger pour la mémoire et des plans pour soutenir les initiatives de sécurité de la mémoire des bibliothèques open source qui font partie de leur chaîne d'approvisionnement.

    L'insécurité de la mémoire est un fléau pour l'industrie du logiciel depuis des décennies et continuera d'être une source majeure de vulnérabilités et de dommages dans le monde réel jusqu'à ce que les principaux dirigeants des fabricants de logiciels fassent les investissements appropriés et s'approprient les résultats de leurs clients en matière de sécurité. À l'occasion de la semaine nationale du codage, nous espérons que les participants de l'ensemble de l'industrie du logiciel travailleront ensemble pour créer des logiciels plus sûrs dès leur conception, et la sécurité de la mémoire est la clé pour atteindre cet objectif.
    Source : CISA

    Et vous ?

    Quel est votre avis sur la sécurité de la mémoire dans nos logiciels actuels ?
    Pensez-vous que l'utilisation d'un langage comme Rust soit la solution ?

    Voir aussi :

    La NSA exhorte les organisations à passer à des langages de programmation sécurisés dans la gestion de la mémoire pour éliminer un vecteur d'attaque souvent exploité par les cybercriminels

    La NSA et la CISA des États-Unis publient un guide pour renforcer la sécurité des clusters Kubernetes, en vue d'aider les entreprises à rendre leurs infrastructures plus résilientes

    « Choisir Rust est opter pour une meilleure sécurisation des logiciels qu'avec le C, mais une efficacité énergétique et une performance d'exécution que seul le C offre », d'après l'équipe AWS

  2. #2
    Membre expert

    Profil pro
    activité : oui
    Inscrit en
    Janvier 2014
    Messages
    1 262
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : activité : oui

    Informations forums :
    Inscription : Janvier 2014
    Messages : 1 262
    Points : 3 409
    Points
    3 409
    Par défaut
    Quel est votre avis sur la sécurité de la mémoire dans nos logiciels actuels ?
    Si du côté des éditeurs, des résultats rapides pourront être observés, il en est tout autrement concernant les autres types d'entreprises où des internes ou "connaissances" pondent du script et petits programmes sans réel connaissance ou volonté pour traiter cet aspect de la sécurité.


    Pensez-vous que l'utilisation d'un langage comme Rust soit la solution ?
    LA solution : non.
    Une part de la solution : oui.
    Il est bon de rappeler que Rust n'est pas un langage qui sécurise la gestion de la mémoire simplement par l'usage du langage.
    Pour cela il faut s'assurer de rester dans un contexte de programmation précis. Dès lors que l'on en sort, il n'y a plus d'assurance que ces travers de sécurité (ou l'indéterminisme) soient circonscrits et inhibés.
    ...et je suppose que les paramètres de son compilateur a également son lot de facteurs quand au renforcement ou l'affaiblissement de cette gestion mémoire.

  3. #3
    Chroniqueur Actualités
    Avatar de Anthony
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    Novembre 2022
    Messages
    1 241
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Rédacteur technique

    Informations forums :
    Inscription : Novembre 2022
    Messages : 1 241
    Points : 20 497
    Points
    20 497
    Par défaut 80 % des organisations ne sont pas prêtes pour les règles CISA sur les pratiques de sécurité, selon Lineaje
    80 % des organisations ne sont pas prêtes pour les règles CISA sur les pratiques de sécurité, pire encore, 84 % des entreprises interrogées n'ont pas mis en place de nomenclatures logicielles, d'après Lineaje

    Les règles du formulaire d'attestation de développement de logiciels sécurisés de l'Agence américaine pour la cybersécurité et les infrastructures (CISA) entreront en vigueur le 11 juin 2024. Elles imposent aux producteurs de logiciels qui travaillent avec le gouvernement américain d'adhérer à des pratiques de sécurité essentielles et d'en confirmer le déploiement. Mais une nouvelle étude de Lineaje révèle que 80 % des entreprises ne sont pas prêtes.

    Le rapport indique également que 84 % des entreprises interrogées n'ont pas mis en place de nomenclatures logicielles (SBOM) dans leur processus de développement, malgré le décret 14028 qui rendra les SBOM obligatoires depuis mai 2021. Ces résultats montrent que, dans de nombreux cas, les efforts du gouvernement fédéral pour prévenir les cyberinfiltrations ne se sont pas encore traduits par des actions concrètes.


    Malgré les sanctions potentielles associées à la non-conformité, l'enquête de Lineaje révèle que 65 % des personnes interrogées n'ont jamais entendu parler du décret 14028, tandis que près de la moitié de celles qui le connaissent n'en connaissent pas les critères spécifiques.

    « Les efforts du gouvernement fédéral pour protéger notre chaîne d'approvisionnement en logiciels sont louables, mais il est clair que la sensibilisation n'a pas été suffisante », déclare Javed Hasan, PDG et cofondateur de Lineaje. « Si les entreprises ne peuvent pas construire sans logiciels libres, elles ne peuvent pas non plus survivre à long terme si ces mêmes logiciels libres sont truffés de failles de sécurité. Les éditeurs de logiciels et les professionnels de la cybersécurité doivent se former et prendre des mesures immédiates pour respecter les échéances à venir afin de protéger leurs organisations et de contribuer à l'amélioration de la position globale de la nation en matière de cybersécurité. »

    Entre autres résultats, près de 60 % des personnes interrogées déclarent que leurs entreprises utilisent des composants open-source dans leurs logiciels, mais seulement 16 % peuvent affirmer avec certitude que le logiciel open-source moyen est sécurisé. Alors qu'une légère majorité (56 %) affirme disposer des outils nécessaires pour identifier et atténuer ces composants, près d'un quart n'est pas sûr et près de 20 % n'ont pas d'outils. Par ailleurs, 66 % des entreprises interrogées ont investi dans des outils permettant de trouver et de corriger les vulnérabilités des logiciels développés en interne.

    À propos de Linearje
    Lineaje offre une plateforme de gouvernance robuste conçue pour la gestion de la sécurité de la chaîne d'approvisionnement des logiciels. Ciblant les entreprises impliquées dans l'approvisionnement, la construction, l'achat ou l'utilisation d'applications logicielles, Lineaje garantit des mesures de sécurité complètes tout au long de la chaîne d'approvisionnement. Grâce à ses solutions spécialisées, les entreprises peuvent protéger efficacement leur écosystème logiciel, en réduisant les risques et en améliorant la posture de sécurité globale.

    Source : Lineaje

    Et vous ?

    Quel est votre avis sur le sujet ?
    Trouvez-vous les conclusions de cette enquête de Lineaje crédibles ou pertinentes ?

    Voir aussi :

    Il est urgent de renforcer la sécurité de la mémoire dans les produits logiciels, selon la CISA, l'utilisation d'un langage de programmation à sécurité mémoire comme Rust serait une solution

    La NSA et la CISA des États-Unis publient un guide pour renforcer la sécurité des clusters Kubernetes en vue d'aider les entreprises à rendre leurs infrastructures plus résilientes

Discussions similaires

  1. Réponses: 0
    Dernier message: 03/05/2023, 23h17
  2. Réponses: 0
    Dernier message: 11/08/2018, 18h39
  3. Réponses: 7
    Dernier message: 06/11/2017, 13h25
  4. Réponses: 3
    Dernier message: 21/01/2017, 08h26
  5. Réponses: 0
    Dernier message: 10/11/2010, 12h58

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo