La lutte continue pour la sécurité dès la conception

Lorsqu'il s'agit de problèmes de sécurité liés à des produits nouveaux et complexes, la réponse de la société est généralement la même : d'abord, blâmer l'utilisateur. Ce n’est que plus tard que vous devrez tenir le fabricant responsable des défauts de conception inhérents à ses produits. Nous l’avons vu avec les voitures, puis avec les ordinateurs. Mais tout comme l’automobile a changé, les attitudes dans le secteur informatique évoluent également.

Les premières voitures furent mises en vente aux États-Unis à la fin des années 1890. Après cela, une série de lois nationales sur la sécurité ont été adoptées. Le Connecticut a introduit la première limitation de vitesse en 1901. Puis sont venus les premiers feux de circulation. New York a adopté la première loi sur l'alcool au volant en 1910. Finalement (mais lentement), les États ont commencé à autoriser les conducteurs et même à les tester occasionnellement.

Punir l'utilisateur, épargner le vendeur

Ces mesures visant à régir le comportement des conducteurs étaient toutes importantes, mais personne n'a tenu les constructeurs automobiles pour responsables de la conception de la sécurité dans leurs produits, pour commencer. Ce n'est qu'en 1965, lorsque Ralph Nader a publié son livre d'exposé sur la sécurité des véhicules, Unsafe at Any Speed, que les consommateurs ont commencé à réfléchir à exiger des voitures plus sûres. Un an plus tard, le Congrès a adopté la loi nationale sur la sécurité de la circulation et des véhicules automobiles, créant le ministère des Transports et obligeant finalement les vendeurs d'automobiles à installer la ceinture de sécurité dans les véhicules.

Le Congrès a adopté cette loi sur la ceinture de sécurité 60 ans après que le premier Ford Model T soit sorti des chaînes de production. Il n'est donc peut-être pas surprenant que 42 ans après le lancement du PC par IBM, il y ait presque pas de lois tenir les fournisseurs de produits technologiques également responsables de la sécurité de leurs produits.

Les seules véritables lois régissant la sécurité informatique aujourd’hui sont là pour contrôler les utilisateurs. La loi CFAA (Computer Fraud and Abuse Act), conçue pour mettre fin aux intrusions en matière de cybersécurité, a été adoptée il y a près de 40 ans et n'a pas été mise à jour de manière significative depuis. Le Digital Millennium Copyright Act (DMCA) vise à empêcher les gens de contourner les contrôles de droits d'auteur numériques.

Prendre conscience de la sécurité dès la conception

Aujourd'hui, des efforts sont déployés pour amener les fabricants à faire le bon choix et à intégrer la sécurité dans leurs produits dès la phase de conception plutôt que comme module complémentaire après-vente. En avril 2023, la Cybersecurity and Infrastructure Security Agency (CISA) a publié ses lignes directrices sur la conception de produits sécurisés : Changer l'équilibre des risques de cybersécurité : principes et approches pour la sécurité dès la conception et par défaut.

La sécurité dès la conception intègre la sécurité dès la phase de conception plutôt que comme un ajout après coup ou après-vente. La sécurité par défaut garantit que la sécurité est activée pour protéger les utilisateurs dès le départ, sans frais supplémentaires.

Les principes du comité consultatif conjoint semblent évidents. Par exemple, il prévient que la charge de la sécurité ne doit pas incomber uniquement au client. Les éditeurs de logiciels devraient « s'approprier les résultats en matière de sécurité de l'achat de leurs clients ». C'était également un objectif stratégique du plan de mars 2023 de la Maison Blanche. Stratégie nationale de cybersécurité.

Une autre solution est la « transparence radicale », dans laquelle les éditeurs de logiciels devraient se targuer de créer des produits sécurisés, en démontrant comment ils le font.

Tout cela repose sur le troisième principe : construire une structure de leadership qui soutient ces objectifs. Les cadres supérieurs doivent être disposés à recueillir les commentaires des clients sur la sécurité des produits, puis à consacrer des ressources internes à la résolution de ces problèmes. Cette structure organisationnelle pourrait impliquer de consacrer une personne spécifique responsable de la sécurité des logiciels, ajoute le document.

Le problème de la responsabilité du fournisseur

La sécurité dès la conception semble être une proposition simple, mais ses partisans sont confrontés à plusieurs défis difficiles, dont beaucoup sont d’ordre monétaire.

Premièrement, accepter la responsabilité de la sécurité des logiciels représente un risque considérable pour les éditeurs de logiciels, dont les clients risquent chaque jour d’énormes pertes à cause des failles de leurs logiciels. Ce n’est que dans des cas très extrêmes que ces vendeurs souffrent financièrement. Par exemple, les assureurs de SolarWinds payé 26 millions de dollars aux clients dans le cadre d'un règlement après que son logiciel compromis a touché environ 18,000 2020 organisations en XNUMX.

Pour chaque fournisseur de technologie qui s'efforce de sécuriser ses produits de A à Z, nombreux sont ceux qui ne le font pas. La Maison Blanche s'est engagée à travailler avec le Congrès pour élaborer une législation établissant la responsabilité des fournisseurs en matière de sécurité des produits technologiques, mais alors que nous entrons dans une année électorale et que le Congrès parvient à peine à se mettre d'accord sur suffisamment de points pour maintenir le gouvernement en marche, les chances que cela se produise semblent minces.

Pour l'instant, il incombe peut-être au client de les contraindre à changer. La CISA recommande aux entreprises de privilégier les fournisseurs qui s'engagent à sécuriser leurs produits, tant dès leur conception que par défaut. La Maison-Blanche apporte son soutien : en juillet, elle a annoncé le lancement du US Trust Mark, un système d'évaluation de la cybersécurité destiné à aider les consommateurs à évaluer les objets connectés.

Il existe d’autres défis en matière de responsabilité du vendeur. Même si certains faux pas en matière de sécurité peuvent être imputables au fournisseur, il existe de nombreux cas dans lesquels le fournisseur pourrait reprocher au client une mauvaise utilisation ou une mauvaise configuration du logiciel.

Le profil d'autorisation du logiciel est un outil permettant d'éviter une telle utilisation abusive par les clients. Cette tactique de sécurité intégrée, mise en évidence par la CISA dans ses directives, recommande la manière dont les utilisateurs de certains types doivent utiliser le logiciel, notamment en décrivant les privilèges d'accès pour ces différents rôles. Cela empêche le superviseur de la salle de courrier d'accéder aux mêmes fonctions dans le système de planification des ressources de l'entreprise que le responsable des ventes, par exemple. Les fournisseurs de logiciels avisés peuvent alerter les utilisateurs s'ils tentent de s'écarter du profil.

Coût et complexité

La sécurité embarquée est complexe et coûteuse. Comme le souligne l'avis conjoint : « Le développement sécurisé dès la conception nécessite l'investissement de ressources importantes de la part des fabricants de logiciels à chaque couche du processus de conception et de développement du produit, qui ne peuvent pas être « renforcées » ultérieurement.

Cela est particulièrement problématique lorsqu’il s’agit de produits logiciels et matériels existants. De nombreux éditeurs de logiciels travaillent avec un code hérité monolithique développé au fil des années, fragile et difficile à mettre à jour. C'est plus difficile à mettre à jour qu'un logiciel modulaire, avec de nombreux composants indépendants et faiblement couplés.

Les entreprises peuvent rembourser cette dette technique progressivement à travers plusieurs itérations de produits, mais cela nécessite des ressources importantes pour ramener ce logiciel à ses fondations et restructurer la sécurité de fond en comble.

Conception sécurisée : une tâche ingrate

Cela nous amène au problème suivant : la visibilité, ou son absence.

Produisez une nouvelle fonctionnalité brillante et très visible comme l'IA générative, et vous inciterez les clients à acheter la prochaine version de votre produit ou à maintenir leur abonnement. A l’inverse, ajuster code sous le capot pour être plus sécurisé et bien organisé est louable mais ingrat ; ce n'est pas vraiment un argument de vente pour de nombreux clients. Un site Web indiquant « Maintenant sécurisé de l'intérieur vers l'extérieur » vous demandera probablement de répondre : « Quoi, vous voulez dire qu'il n'était pas si sécurisé au départ ? »

La sécurité a toujours été un peu comme l'assurance de biens ou l'assurance vie : il faut le faire, mais c'est difficile à vendre. Rendre vos propres produits non liés à la sécurité plus sécurisés ne génère pas de revenus directs. Cependant, la vente de produits de sécurité après-vente tels que des logiciels anti-malware et des pare-feu est lucrative.

Tactiques pour la sécurité dès la conception

Cela dit, les défis ne devraient pas nous empêcher de poursuivre la sécurité dès la conception. Les organisations peuvent adopter certaines tactiques qui contribueront à encourager la sécurité des logiciels dès le début. L’un d’entre eux, mis en évidence dans les directives CISA, est l’utilisation de langages sécurisés en mémoire.

Certains langages de programmation traditionnels de bas niveau, notamment C et C++, permettent aux programmeurs de manipuler des zones de mémoire qu'ils ne devraient pas manipuler. Ils peuvent lire la mémoire susceptible de contenir des informations sensibles ou du code inapproprié. Ils peuvent également modifier le fonctionnement d’autres programmes ou les mettre dans un état confus, les rendant ainsi vulnérables aux attaques.

Les fournisseurs de systèmes d'exploitation ont introduit des mesures de protection de la mémoire, mais CISA affirme que celles-ci sont insuffisantes. Au lieu de cela, il recommande d'utiliser des langages de programmation avec des protections de mémoire intégrées, comme C#, Go ou Rust.

Traiter ce problème dès le début pourrait apporter des améliorations significatives en matière de sécurité. En 2019, les ingénieurs Microsoft dit qu'environ sept vulnérabilités sur dix dans les produits Microsoft étaient dues à des problèmes de sécurité de la mémoire.

Qui est leader en matière de sécurité dès la conception

Plusieurs groupes gouvernementaux et industriels disposent déjà de principes et de cadres de conception sécurisés axés sur différents niveaux de la pile technologique. Du côté des logiciels, il s'agit notamment Cadre de développement de logiciels sécurisé du NIST et une initiative à l'échelle de l'industrie pour le développement de logiciels sécurisés appelée SafeCode. Des efforts sont également déployés pour renforcer la sécurité dans des domaines spécifiques, tels que la conception d'applications Web, via Principes de conception sécurisée de l'OWASP.

Du côté du matériel, les entreprises travaillent ensemble depuis des années sur des systèmes de modules de plate-forme de confiance (TPM) qui stockent physiquement les secrets dans du silicium inviolable sur la carte mère. À ce stade, vous ne pouvez pas installer Windows 11 sans un TPM version 2.0.

Une course vers le bas (de la pile)

L'insistance de Microsoft sur le matériel TPM est un exemple de la façon dont certains fournisseurs font de leur mieux pour aborder la sécurité dès la conception, en collaborant les uns avec les autres pour créer des chaînes de sécurité qui commencent dans le silicium et s'étendent jusqu'au système d'exploitation.

Un exemple est Secure Boot, une fonction de sécurité qui stocke les codes approuvés par le fabricant prouvant que divers composants du système, tels que le micrologiciel et le système d'exploitation, sont légitimes. Cela repose sur un TPM, ainsi que sur l'UEFI (Unified Extensible Firmware Interface), la version moderne du micrologiciel de l'ordinateur, celui qui exécute et démarre le reste de l'ordinateur lorsqu'il s'allume.

En vérifiant et en protégeant le code aux niveaux inférieurs du système, les fournisseurs de systèmes d'exploitation et les fabricants d'équipement d'origine visent à garantir un contrôle complet sur tout ce qui repose sur ce code. Cependant, ces protections sont soumises à leurs propres failles de sécurité, comme tout le reste. Dans le cas de Secure Boot, un code de vulnérabilité nommé Baton Drop a permis aux attaquants d'introduire un rootkit UEFI appelé BlackLotus qui a contourné ces protections, permettant aux attaquants de posséder le système pour leurs attaquants.

De telles attaques ne signifient pas que nous ne devons pas rechercher la sécurité dès la conception et par défaut. Introduire plus de sécurité dans le système dès le début fait pencher la balance en faveur des défenseurs et rend les attaques plus difficiles. Mais des attaques comme BlackLotus montrent que même la sécurité imposée lors de la phase de conception peut être contournée. La réponse consiste à concevoir plusieurs couches et facettes de protection dans les systèmes, en minimisant la surface d’attaque et en offrant de multiples obstacles aux attaquants à surmonter.

Règlementations

Les gouvernements prennent au sérieux la sécurité dès la conception, avec plusieurs mesures législatives ici ou en préparation. Aux États-Unis, la Californie et l’Oregon ont adopté des lois sur la sécurité de l’IoT. Celles-ci nécessitent que les appareils connectés individuels disposent de mots de passe uniques préprogrammés ou obligent les utilisateurs à générer un nouveau moyen d'authentification avant de pouvoir accéder à l'appareil pour la première fois.

Au Royaume-Uni, la loi sur la sécurité des produits et les télécommunications imposera des exigences de sécurité de base pour les produits connectés prêts à l'emploi. Ceux-ci incluent des mots de passe uniques, des informations sur le signalement des problèmes de sécurité avec un produit et la période de support minimale pour les mises à jour de sécurité.

Il s’agit d’un début, mais il manque encore certaines opportunités d’appliquer une sécurité robuste dès la conception aux produits essentiels. Par exemple, les ordinateurs de bureau, portables et les tablettes sont exclus de la loi britannique, tout comme les appareils médicaux, les compteurs intelligents et les smartphones. Au moins vos bouilloires connectées et vos caméras de sécurité Web sont couvertes.

Le problème de ces lois est de trouver l’équilibre entre efficacité et complexité. Les lois qui microgèrent l’application des principes de sécurité sont difficiles à contrôler et à mettre à jour. Néanmoins, rendre obligatoire l'application et la documentation d'un cycle de vie du développement de logiciels sécurisés aiderait à sécuriser de nombreux produits.

L’UE espère également résoudre le problème de sécurité inhérent au niveau du bloc. En septembre 2022, il a publié un projet de loi, bien plus strict que la loi britannique, qui renforcerait les règles de cybersécurité afin d'assurer une meilleure sécurité des produits. La loi sur la cyber-résilience obligerait les fabricants à améliorer la sécurité des produits tout au long de leur cycle de vie.

Apprendre de l’histoire

L'approche de l'industrie informatique en matière de sécurité dès la conception est actuellement celle de l'industrie automobile au milieu des années soixante. La cybersécurité est devenue une préoccupation publique largement répandue, et certaines organisations explorent volontairement des approches de sécurité intégrée pour se différencier et protéger leurs utilisateurs.

Aujourd’hui, les gouvernements s’attaquent progressivement au problème en légiférant. Il y a un long chemin à parcourir, en partie parce que la complexité des solutions informatiques et des chaînes d'approvisionnement numériques qui les soutiennent est d'un ordre de grandeur supérieur à celle du secteur automobile avant la numérisation.

Certaines choses restent les mêmes, notamment le manque de sensibilisation ou l'ambivalence des consommateurs. Lorsque les États-Unis ont rendu obligatoire l’installation des ceintures de sécurité dans les voitures, leur utilisation était volontaire. Lorsque les premiers États ont commencé à exiger le port de la ceinture de sécurité, près de deux décennies plus tard, moins d’une personne sur cinq l’utilisait. Il appartiendra aux gouvernements et aux fournisseurs d’appliquer une meilleure sécurité aux produits technologiques et de veiller à ce qu’ils soient activés par défaut pour les utilisateurs.