Depuis des décennies, les vulnérabilités en matière de sécurité de la mémoire sont au centre de divers incidents de sécurité dans l'industrie, érodant la confiance dans la technologie et coûtant des milliards. Les approches traditionnelles, telles que l'audit de code, le fuzzing et l'atténuation des exploits, bien qu'utiles, n'ont pas suffi à endiguer le problème, tout en entraînant des coûts de plus en plus élevés.
Dans cet article de blog, nous appelons à un changement fondamental : un engagement collectif pour enfin éliminer cette catégorie de vulnérabilités, ancré sur des pratiques de conception sécurisée - non seulement pour nous-mêmes, mais aussi pour les générations à venir.
Le changement que nous appelons de nos vœux est renforcé par un récent article de l'ACM appelant à normaliser la sécurité des mémoires, que nous avons contribué à publier avec des partenaires universitaires et industriels. Il s'agit de reconnaître que l'absence de sécurité de la mémoire n'est plus un problème technique de niche, mais un problème de société, qui a des répercussions sur tout, de la sécurité nationale à la protection de la vie privée.
L'opportunité de la normalisation
Au cours de la dernière décennie, une confluence d'avancées en matière de sécurité de conception a mûri au point de permettre un déploiement pratique et généralisé. Il s'agit notamment de langages à mémoire sécurisée, y compris des langages à haute performance tels que Rust, ainsi que des sous-ensembles de langages plus sûrs tels que Safe Buffers pour C++.
Ces outils s'avèrent déjà efficaces. Dans Android, par exemple, l'adoption croissante de langages à mémoire sécurisée comme Kotlin et Rust dans le nouveau code a entraîné une réduction significative des vulnérabilités.
Pour ce qui est de l'avenir, nous assistons également à des développements passionnants et prometteurs dans le domaine du matériel. Des technologies telles que l'extension matérielle MTE (Memory Tagging Extension) d'ARM et l'architecture CHERI (Capability Hardware Enhanced RISC Instructions) offrent une défense complémentaire, en particulier pour le code existant.
Bien que ces progrès soient encourageants, la sécurité de la mémoire dans l'ensemble de l'industrie du logiciel exige plus que des progrès technologiques individuels : nous devons créer l'environnement et la responsabilité nécessaires à leur adoption généralisée. La normalisation est essentielle à cet égard.
Pour faciliter la normalisation, nous suggérons d'établir un cadre commun pour spécifier et évaluer objectivement les garanties de sécurité de la mémoire ; ce faisant, nous jetterons les bases de la création d'un marché dans lequel les fournisseurs seront incités à investir dans la sécurité de la mémoire. Les clients auront la possibilité de reconnaître, d'exiger et de récompenser la sécurité. Ce cadre fournira aux gouvernements et aux entreprises la clarté nécessaire pour spécifier les exigences en matière de sécurité de la mémoire, ce qui favorisera l'acquisition de systèmes plus sûrs.
Le cadre que nous proposons compléterait les efforts existants en définissant des critères spécifiques et mesurables pour atteindre différents niveaux d'assurance de la sécurité de la mémoire dans l'ensemble de l'industrie. De cette manière, les décideurs politiques disposeront de la base technique nécessaire pour élaborer des initiatives politiques et des mesures incitatives efficaces en faveur de la sécurité de la mémoire.
Un plan d'action pour un avenir sans danger pour la mémoire
Nous savons qu'il existe plusieurs façons de résoudre ce problème et nous investissons dans plusieurs d'entre elles. Il est important de noter que notre vision de la sécurité de la mémoire par la normalisation se concentre sur la définition des résultats souhaités plutôt que sur l'adoption de technologies spécifiques.
Pour traduire cette vision en une norme efficace, nous avons besoin d'un cadre qui permette de :
Favoriser l'innovation et soutenir diverses approches : La norme devrait se concentrer sur les propriétés de sécurité que nous voulons atteindre (par exemple, l'absence de violations de la sécurité spatiale et temporelle) plutôt que d'imposer des détails de mise en œuvre spécifiques. Le cadre doit donc être neutre sur le plan technologique et permettre aux fournisseurs de choisir la meilleure approche pour leurs produits et leurs exigences. Cela encourage l'innovation et permet aux fabricants de logiciels et de matériel d'adopter les meilleures solutions au fur et à mesure qu'elles apparaissent.
Adapter les exigences de sécurité de la mémoire en fonction des besoins : Le cadre devrait établir différents niveaux d'assurance de la sécurité, semblables aux niveaux SLSA, en reconnaissant que des applications différentes ont des besoins de sécurité et des contraintes de coût différents. De même, nous avons probablement besoin d'orientations distinctes pour le développement de nouveaux systèmes et l'amélioration des bases de code existantes. Par exemple, nous n'avons probablement pas besoin que chaque morceau de code soit formellement prouvé. Cela permet d'adapter la sécurité, en garantissant des niveaux appropriés de sécurité de la mémoire pour différents contextes.
Permettre une évaluation objective : Le cadre devrait définir des critères clairs et éventuellement des mesures pour évaluer la sécurité de la mémoire et le respect d'un niveau d'assurance donné. L'objectif serait de comparer objectivement l'assurance de la sécurité de la mémoire de différents composants logiciels ou systèmes, de la même manière que nous évaluons aujourd'hui l'efficacité énergétique. Cela nous permettra de dépasser les affirmations subjectives et d'obtenir des propriétés de sécurité objectives et comparables d'un produit à l'autre.
Être pratique et réalisable : Parallèlement au cadre neutre sur le plan technologique, nous avons besoin de meilleures pratiques pour les technologies existantes. Le cadre devrait fournir des orientations sur la manière d'exploiter efficacement des technologies spécifiques pour respecter les normes. Il s'agit notamment de répondre à des questions telles que : quand et dans quelle mesure un code non sûr est acceptable au sein de systèmes logiciels plus vastes, et des lignes directrices sur la structuration de ces dépendances non sûres pour soutenir le raisonnement compositionnel sur la sécurité.
L'engagement de Google
Chez Google, nous ne nous contentons pas de plaider en faveur de la normalisation et d'un avenir sans danger pour la mémoire, nous travaillons activement à sa construction.
Nous collaborons avec des partenaires industriels et universitaires pour élaborer des normes potentielles, et notre participation à la rédaction du récent appel à l'action de la CACM marque une première étape importante dans ce processus. En outre, comme indiqué dans notre livre blanc « Secure by Design » et dans notre stratégie de sécurité de la mémoire, nous sommes profondément engagés à intégrer la sécurité dans les fondements de nos produits et services.
Cet engagement se reflète également dans nos efforts internes. Nous donnons la priorité aux langages à mémoire sécurisée et avons déjà constaté des réductions significatives des vulnérabilités en adoptant des langages tels que Rust en combinaison avec l'utilisation existante et largement répandue de Java, Kotlin et Go lorsque les contraintes de performance le permettent. Nous reconnaissons qu'une transition complète vers ces langages prendra du temps. C'est pourquoi nous investissons également dans des techniques visant à améliorer la sécurité de notre base de code C++ existante, comme le déploiement de libc++ renforcé.
Construisons ensemble un avenir sans danger pour la mémoire
Il ne s'agit pas de désigner des gagnants ou de dicter des solutions. Il s'agit de créer des conditions équitables, de permettre une prise de décision éclairée et d'instaurer un cycle vertueux d'amélioration de la sécurité. Il s'agit d'ouvrir la voie à un avenir où :
- Les développeurs et les fournisseurs peuvent en toute confiance créer des systèmes plus sûrs, sachant que leurs efforts peuvent être évalués de manière objective.
- Les entreprises peuvent acheter des produits à mémoire sécurisée avec assurance, réduisant ainsi les risques et protégeant leurs clients.
- Les gouvernements peuvent protéger efficacement les infrastructures critiques et encourager l'adoption de pratiques sécurisées dès la conception.
- Les consommateurs peuvent prendre des décisions sur les services dont ils dépendent et les appareils qu'ils utilisent en toute confiance, sachant que la sécurité de chaque option a été évaluée par rapport à un cadre commun.
Le chemin vers la sécurité de la mémoire exige un engagement collectif en faveur de la normalisation. Nous devons construire un avenir où la sécurité de la mémoire n'est pas une réflexion après coup mais un principe fondamental, un avenir où la prochaine génération héritera d'un monde numérique sécurisé dès sa conception.
Google appelle à des normes mesurables de sécurité de la mémoire pour les logiciels
Envoyé par Google
Quel est votre avis sur le sujet ?
Répondre avec citation
Partager