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 Forbes Technology Council. Il a été mis à jour et syndiqué ici.

‍

Combien de données pensez-vous avoir été compromises en 2022 ? Si vous avez estimé ce chiffre à environ un demi-milliard, vous êtes dans le vrai. D'après les données publiques sur les violations, environ 480 014 323 enregistrements ont été volés rien que l'année dernière, mais le nombre réel 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 profondément préoccupante pour tout professionnel de la sécurité en entreprise.

Nous avons atteint un point où la plupart des habitants du monde développé ont probablement vu une partie de leurs données personnelles tomber entre les mains de criminels suite à une cyberattaque réussie. Il est donc naturel que les gouvernements mondiaux cherchent des solutions pour endiguer ce flux perturbateur d'activités criminelles en ligne. La dernière initiative en date provient de l'administration Biden sous la forme de la Stratégie nationale de cybersécurité, que j'observe avec un vif intérêt. Cette stratégie inclut des directives sur l'un de mes sujets favoris ces derniers temps : la responsabilité en matière de sécurité.

La stratégie, publiée après une présentation fondatrice de Jen Easterly, directrice de la CISA, a suscité, comme on pouvait s'y attendre, quelques divisions au sein de la communauté de la sécurité. Cependant, je pense qu'elle représente notre meilleure chance d'élever 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 auraient toujours dû être tenus responsables des logiciels non sécurisés.

Depuis des décennies, en matière de sécurité logicielle, la responsabilité est une patate chaude qu'aucune équipe ne souhaite manipuler. Les dirigeants et les équipes ont tendance à être en désaccord total sur qui est ultimement responsable de la sécurité des logiciels. Un rapport de Venafi révèle que 97 % des cadres supérieurs en informatique s'accordent à dire que les processus de création de logiciels ne sont pas assez sécurisés, mais il existe une divergence sur la responsabilité de la mise en œuvre des meilleures pratiques de sécurité. 61 % des cadres estiment que les équipes de sécurité informatique devraient assumer cette responsabilité, tandis que 31 % pensent que cela devrait incomber aux équipes de développement. Et ce n'est qu'une partie de l'équation : la question des composants open-source et commerciaux tiers dans les builds logiciels constitue une extension constante de la surface d'attaque. Même entre les équipes AppSec et sécurité, il existe rarement un « propriétaire » évident, malgré le besoin de vigilance continue en matière de mise à jour, de surveillance et de test.

Cette même enquête a également mis en lumière que, malgré les conflits internes sur la responsabilité de la sécurité et de l'intégrité des logiciels, 94 % des cadres estiment qu'il devrait y avoir des sanctions pour les fournisseurs de logiciels qui ne protègent pas leurs pipelines de build contre les acteurs malveillants et qui mettent en danger les clients et les utilisateurs finaux.

Avec la récente condamnation du RSSI d'Uber en lien avec leur mauvaise gestion d'une cyberattaque dévastatrice en 2016, ainsi que des initiatives réglementaires comme le RGPD, nous voyons lentement les enjeux augmenter pour les fournisseurs qui jouent avec le feu en reléguant la sécurité au second plan. Cependant, cela ne suffit tout simplement pas. Nous perdons la bataille contre les cybercriminels et, bien que ce soit difficile à admettre, ce sont les pratiques laxistes des fournisseurs de logiciels qui leur offrent des opportunités illimitées de prospérer.

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

Examinons cela :

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

« Trop de fournisseurs ignorent les meilleures pratiques de développement sécurisé, livrent des produits avec des configurations par défaut non sécurisées ou des vulnérabilités connues, et intègrent des logiciels tiers de provenance non vérifiée ou inconnue.

Nous devons commencer à transférer 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 prévenir toutes les vulnérabilités. »

Cela a, comme on pouvait s'y attendre, fait grincer des dents. Mais, comme pour d'autres moments décisifs dans l'élaboration de normes et de réglementations dans la plupart des secteurs, il s'agit d'une douleur à moyen terme pour garantir un meilleur résultat à long terme. En tant que fournisseur de logiciels moi-même, il est logique que la responsabilité finale nous incombe en matière de sécurité. C'est notre pipeline de build, nos processus et notre contrôle qualité ; si nous commettons une erreur, il est de notre responsabilité de la corriger.

De plus, nous devrions chercher à créer des logiciels de la plus haute qualité possible, et le codage sécurisé doit faire partie des indicateurs qui définissent un résultat réussi. Y parvenir est une tâche ardue dans un monde axé sur la vitesse à tout prix, mais il appartient aux leaders de la sécurité qui guident notre avenir de s'assurer que chaque acteur du processus de création logicielle est adéquatement formé pour appliquer les meilleures pratiques de sécurité dans le cadre de son rôle, en particulier les développeurs.

Nous manquons encore de directives sur les meilleures pratiques à long terme.

L'objectif stratégique 3.3 fait référence au cadre de développement logiciel sécurisé du NIST comme base de ses meilleures pratiques générales, et ce sont des directives complètes et exhaustives. Elles précisent la nécessité de « s'assurer que les personnes, 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 prescriptives sur les facteurs dont, par exemple, un responsable de la sensibilisation à la sécurité devrait être conscient lors du choix de solutions d'habilitation.

Pour que l'approche soit véritablement transformatrice, les développeurs doivent être considérés comme faisant partie intégrante du programme de sécurité et avoir toutes les opportunités 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 hyper-pertinents et contextuels, ni si cela est considéré comme un exercice de conformité annuel plutôt que comme un parcours de développement des compétences continu.

Les développeurs sont une pièce maîtresse du puzzle pour résoudre l'énigme de la sécurité, et une équipe de développeurs compétents en sécurité est essentiellement l'ingrédient manquant dans la plupart des organisations. Ils rendent la sécurité rapide possible, mais seulement lorsque du temps et des ressources sont consacrés à libérer ce potentiel dans l'équipe. D'ici là, toutes les directives de meilleures pratiques générales du monde ne suffiront pas à faire bouger les choses.

Le long chemin vers le nirvana de la sécurité logicielle.

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

Le chemin est long, mais il commence par chaque fournisseur de logiciels faisant le premier pas courageux vers la responsabilité en matière de sécurité au niveau organisationnel.