Protection proactive : tirer parti de la stratégie nationale de cybersécurité pour une prévention avancée des menaces

Cet article a été initialement publié dans le cadre du Conseil technologique de Forbes. Il a été mis à jour et diffusé ici.

‍

Selon vous, combien d'enregistrements de données ont été compromis en 2022 ? Vous seriez sur la bonne voie si vous deviniez environ un demi-milliard. Sur la base des données relatives aux violations accessibles au public, environ 480 014 323 dossiers ont été volés l'année dernière seulement, mais ce chiffre est probablement bien plus élevé. Quoi qu'il en soit, c'est une statistique qui donne à réfléchir pour le citoyen moyen et qui est très préoccupante pour tout professionnel de la sécurité d'entreprise.

Nous avons atteint un point où la plupart des habitants des pays développés ont probablement vu au moins certaines de leurs données personnelles tomber entre les mains de criminels à la suite d'une cyberattaque réussie. Il est donc tout à fait naturel que les gouvernements du monde entier recherchent des solutions pour endiguer ce flux perturbateur d'activités criminelles en ligne. Le dernier versement provient de l'administration Biden sous la forme du Stratégie nationale de cybersécurité, et je les regarde avec grand intérêt. Cette stratégie comprend des directives concernant l'un de mes sujets préférés ces derniers temps : la responsabilité en matière de sécurité.

La stratégie, publiée à la suite d'une présentation séminale par Jen Easterly, directrice de la cybersécurité et de la sécurité des infrastructures de la CISA, a naturellement semé la division au sein de la communauté de la sécurité. Cependant, je pense que c'est la meilleure chance que nous ayons d'améliorer les normes logicielles à tous les niveaux et, enfin, d'inaugurer une nouvelle ère de développeurs compétents en matière de sécurité.

Les fournisseurs devraient avoir toujours a été tenu pour responsable de logiciels non sécurisés.

Cela fait des décennies qu'en termes de sécurité logicielle, la responsabilité est une question épineuse qu'aucune équipe ne cherche à jongler. Les dirigeants et les équipes ont tendance à être en désaccord avec véhémence sur la question de savoir qui est responsable en dernier ressort de la sécurité logicielle, un reportage de Venafi révèle que 97 % des cadres supérieurs informatiques estiment que les processus de création de logiciels ne sont pas suffisamment sécurisés, mais qu'il existe une divergence quant à la responsabilité ultime de la mise en œuvre des meilleures pratiques de sécurité. 61 % des dirigeants ont déclaré que les équipes de sécurité informatique devraient assumer la responsabilité de la sécurité des logiciels, tandis que 31 % ont déclaré que cette responsabilité devait revenir à l'équipe de développement. Et ce n'est qu'une partie de l'équation : le problème des composants commerciaux open source et tiers dans les versions logicielles est une extension constante de la surface d'attaque. Même entre les équipes AppSec et de sécurité, il est rare qu'il y ait un « propriétaire » évident malgré la nécessité d'une vigilance continue en matière de mise à jour, de surveillance et de tests.

Cette même enquête a également révélé que, malgré les conflits internes sur la question de savoir qui doit être responsable de la sécurité et de l'intégrité des logiciels, 94 % des dirigeants pensent que des sanctions devraient être prévues pour les éditeurs de logiciels qui ne protègent pas leurs pipelines de développement contre les acteurs malveillants et mettent en danger les clients et les utilisateurs finaux.

Avec le poursuites récentes contre le CISO d'Uber en ce qui concerne leur mauvaise gestion d'une cyberattaque dévastatrice en 2016, ainsi que des initiatives réglementaires telles que le RGPD, nous constatons lentement que les enjeux augmentent pour les fournisseurs qui jouent avec le feu en ne donnant pas la priorité à la sécurité. Cependant, cela ne suffit tout simplement pas. Nous sommes en train de perdre la bataille contre les cybercriminels et, bien que ce soit une pilule difficile à avaler, ce sont les pratiques laxistes des éditeurs de logiciels qui leur offrent des opportunités illimitées de prospérer.

La stratégie nationale de cybersécurité vise à tracer une ligne dans le sable et à mettre fin au jeu circulaire du blâme en attribuant l'entière responsabilité des logiciels non sécurisés au fournisseur.

Jetons un coup d'œil :

Objectif stratégique 3.3 — Transférer la responsabilité pour les produits et services logiciels non sécurisés :

»Trop de fournisseurs « ignorent les meilleures pratiques en matière de développement sécurisé, proposent des produits dont les configurations par défaut ne sont pas sécurisées ou présentent des vulnérabilités connues, et intègrent des logiciels tiers dont la provenance n'a pas été vérifiée ou inconnue.

Nous devons commencer à rejeter la responsabilité sur les entités qui ne prennent pas les précautions raisonnables pour sécuriser leurs logiciels, tout en reconnaissant que même les programmes de sécurité logicielle les plus avancés ne peuvent empêcher toutes les vulnérabilités.»

Cela a, naturellement, ébouriffé quelques plumes. Mais, comme c'est le cas à d'autres moments déterminants de l'élaboration de normes et de réglementations dans la plupart des secteurs, il est difficile de garantir de meilleurs résultats à long terme à moyen terme. En tant que fournisseur de logiciels, il est logique que ce soit à nous de payer la responsabilité en matière de sécurité. Il s'agit de notre pipeline de construction, de nos processus et de notre contrôle qualité, et si nous échouons, il est de notre responsabilité d'y remédier.

En outre, nous devrions chercher à créer des logiciels de la meilleure qualité possible, et le codage sécurisé doit faire partie des indicateurs qui définissent un résultat réussi. Atteindre cet objectif représente un défi de taille dans un monde qui mise sur la rapidité à tout prix, mais il appartient aux responsables de la sécurité qui orientent notre avenir de veiller à ce que tous les acteurs du processus de création de logiciels soient correctement formés pour appliquer les meilleures pratiques de sécurité dans le contexte de leur rôle, en particulier les développeurs.

Nous n'avons toujours pas de directives concernant les meilleures pratiques à long terme.

L'objectif stratégique 3.3 fait référence à des Cadre de développement logiciel sécurisé du NIST comme base de ses meilleures pratiques générales, et il s'agit de directives complètes et exhaustives. Ils précisent la nécessité de « s'assurer que le personnel, les processus et la technologie de l'organisation sont prêts à effectuer un développement logiciel sécurisé au niveau de l'organisation », mais ne sont pas particulièrement prescriptifs quant aux facteurs dont, par exemple, un responsable de la sensibilisation à la sécurité doit être conscient lorsqu'il choisit des solutions d'activation.

Pour que l'approche soit réellement transformatrice, les développeurs doivent être considérés comme faisant partie intégrante du programme de sécurité et avoir toutes les chances d'améliorer leurs compétences et de partager la responsabilité de la détection et de l'éradication des vulnérabilités. Ils ne peuvent y parvenir de manière mesurable sans un apprentissage et des outils contextuels hyperpertinents, ni si cela est considéré comme un exercice de conformité annuel au lieu d'un parcours de développement continu des compétences.

Les développeurs constituent une pièce maîtresse du puzzle lorsqu'il s'agit de résoudre l'énigme de sécurité, et une équipe de développeurs compétents en matière de sécurité est essentiellement l'ingrédient manquant dans la plupart des entreprises. Ils permettent une sécurité rapide, mais uniquement lorsque du temps et des ressources sont consacrés à la débloquer au sein de l'équipe. D'ici là, toutes les directives générales sur les meilleures pratiques du monde ne suffiront pas à faire bouger les choses.

Le long chemin qui mène au nirvana de la sécurité logicielle.

L'administration Biden a engagé 3 milliards de dollars de financement à la CISA, dans le but de parvenir à une résilience rapide des infrastructures critiques. Bien que le financement et le soutien des plus hauts niveaux de gouvernement soient essentiels, pour que nous puissions avoir une chance de contrecarrer les acteurs de la menace, il faudra un effort mondial pour réécrire l'histoire de la culture de sécurité.

Le chemin à parcourir est long, mais il faut que chaque éditeur de logiciels fasse le premier pas courageux vers la responsabilité en matière de sécurité au niveau de l'organisation.