Il ne suffit pas de se déplacer vers la gauche : pourquoi commencer à gauche est la clé de l'excellence en matière de sécurité logicielle

Dans un monde régi par le numérique, nous sommes exposés à un risque croissant de vol de données. Les grandes organisations agissant en tant que gardiennes de nos précieuses informations, nombreuses sont celles qui reconnaissent la nécessité de mettre en œuvre des normes de sécurité strictes.

La plupart des initiatives visant à « basculer vers la gauche », c'est-à-dire à introduire la sécurité bien plus tôt dans le processus de développement, ne vont tout simplement pas assez loin. Cela implique que nous entamons toujours le processus dans le mauvais sens, en finissant par faire marche arrière pour obtenir un logiciel plus sécurisé. Nous devons commencer à gauche, en adoptant un changement culturel qui engage de manière positive les équipes de développement et leur fournit les connaissances qui leur font actuellement défaut. Cependant, toutes les formations et tous les outils ne sont pas identiques.

Dans cet article, nous explorons les moyens par lesquels des leaders clés tels que la sensibilisation à la sécurité et les responsables du développement peuvent réellement responsabiliser leur cohorte de développeurs, en les transformant en première ligne défensive contre les cyberattaques coûteuses.

Décaler vers la gauche par rapport à partir à gauche : une distinction importante.

À l'ère des violations de données fréquentes affectant certaines des organisations les plus fiables au monde, les dirigeants d'entreprises se sont tournés vers le secteur de la sécurité pour fournir des conseils sur la manière d'éviter le désastre financier, de réputation et de réputation qu'est une attaque réussie.

Depuis un certain temps, les spécialistes de la sécurité des applications (y compris moi-même) nous disent qu'il faut effectivement « basculer vers la gauche ». Conformément aux meilleures pratiques DevOps et à de meilleurs résultats en matière de sécurité logicielle, beaucoup d'entre nous ont indiqué que la partie sécurité d'une conception logicielle devait intervenir plus tôt dans le cycle de vie du développement logiciel (SDLC). Il ne faut pas qu'il s'agisse de l'étape finale et coûteuse, mais plutôt de se rapprocher du début du processus, en impliquant les équipes AppSec dès que les projets logiciels prennent vie.

Ce n'est pas mauvais des conseils, et c'est certainement mieux que l'ancienne méthode de travail (qui, si l'on se fie à la quantité de données volées et à l'âge des vulnérabilités utilisées pour les cambrioler en sont une indication, ne fonctionne pas de toute façon). Cependant, si nous commencé à gauche, les résultats en matière de sécurité seraient bien plus positifs.

Décaler à gauche, partir à gauche... quelle est la différence ? La différence réside dans la manière dont vous impliquez votre équipe de développement. Ils constituent véritablement la clé pour fournir des logiciels plus sécurisés, bien moins chers que ceux que peuvent gérer les chaînes d'outils des cycles ultérieurs et la révision manuelle du code. Dans un monde idéal, chaque développeur qui écrit un logiciel aurait les connaissances et les outils nécessaires pour coder en toute sécurité dès le début. Ils détecteraient les défauts potentiels et les atténueraient avant qu'ils ne soient commis (et donc beaucoup plus coûteux à éliminer et à corriger). Il y aurait une réduction spectaculaire des bogues de sécurité que nous observons depuis des décennies, ceux qui sont encore chargé d'autoriser les attaquants à entrer par la porte arrière. Ces opportunités, sous forme d'injection SQL, de script intersite et d'authentification défaillante, seraient fermées.

Cependant, à l'heure actuelle, l'accent n'est tout simplement pas assez mis sur la sécurité au niveau professionnel, et la formation au codage sécurisé en cours d'emploi varie énormément. Par conséquent, les développeurs disposent rarement de ce dont ils ont besoin pour permettre à une organisation de repartir du bon pied. Il est temps pour les personnes occupant des postes de direction de travailler ensemble et de plaider en faveur d'une sensibilisation accrue à la sécurité, grâce à leurs connaissances directes et à leurs contacts avec les développeurs, essentiels à la réussite des programmes. Après tout, les responsables du développement étaient autrefois assis à leur place, face aux outils et à l'espace de sécurité difficiles à naviguer dans le meilleur des cas.

Les développeurs n'aiment pas (encore) la sécurité... mais vous pouvez changer la donne.

Vous savez comment cela fonctionne : si vous parlez de « sécurité » à votre développeur habituel, vous risquez d'être au mieux surpris ou, au pire, perplexe. En général, tout ce qui touche à la sécurité est considéré comme le problème de quelqu'un d'autre.

Un développeur a la responsabilité première de créer un logiciel fonctionnel, doté de fonctionnalités innovantes et livré dans un délai de projet serré. La sécurité est rarement une priorité au niveau du codage et peut même être considérée comme un obstacle fastidieux à la rapidité des livraisons et à la créativité. AppSec a pour mission de vérifier méticuleusement le code, de le tester puis de signaler les mauvaises nouvelles : la présence de failles de sécurité dans du code qui est souvent déjà validé, et qui fonctionne plutôt bien sinon. Il s'agit d'un processus coûteux dans un environnement souvent sollicité en termes de ressources et de temps, dont la configuration ne peut que provoquer une rupture entre deux équipes qui ont finalement le même objectif, mais parlent des langues complètement différentes.

Dans ce climat, l'accueil réservé à la formation obligatoire en matière de sécurité risque d'être plutôt froid. Mais le pouvoir de susciter chez chaque développeur un état d'esprit en matière de sécurité n'est pas une chimère. Grâce à la formation et à l'assistance appropriées, ils peuvent commencer à intégrer la sécurité à leurs logiciels et assumer la responsabilité des résultats de sécurité qu'ils sont en mesure de contrôler. Si les développeurs peuvent eux-mêmes s'occuper des bogues courants, cela libère des spécialistes coûteux pour résoudre les problèmes vraiment complexes. Et si vous êtes en position de gérer une équipe de développement, vous pouvez contribuer à combler cette lacune et à aider votre équipe à en tirer les avantages.

Toutes les formations ne se valent pas.

À quand remonte la dernière fois que vous avez eu vraiment envie d'apprendre quelque chose de nouveau ? À l'époque où vous l'avez fait, des mots comme « obligatoire », « conformité » ou « dix-sept heures de vidéo » ne vous viendraient probablement pas à l'esprit.

Les développeurs ne sont pas différents. Ils sont intelligents, créatifs et adorent résoudre les problèmes. Il est peu probable que le fait de regarder des vidéos interminables sur les failles de sécurité les intéresse, que le contenu reste mémorisable ou qu'il soit spécifique à leurs rôles et responsabilités quotidiens. En tant qu'instructeur SANS, il est devenu évident très tôt que la meilleure formation était la formation pratique, obligeant les participants à analyser et à relever des défis intellectuels, en utilisant des exemples concrets qui testent leur cerveau et s'appuient sur des apprentissages antérieurs. La gamification et la compétition amicale sont également des outils puissants pour faire participer tout le monde aux nouveaux concepts, tout en restant utiles et pratiques dans leur application.

Un autre facteur effrayant est qu'une grande partie de la formation en matière de sécurité n'est pas surveillée. Personne n'aime avoir l'impression que Big Brother regarde, mais à quoi bon consacrer du temps, de l'argent et des efforts à l'éducation si personne ne vérifie si c'est pertinent ?

La bonne solution peut rendre le codage sécurisé amusant, pertinent, engageant et mesurable. Mettez vos développeurs au défi, traitez-les bien et faites-en un événement spécial. L'entraînement gamifié met en lumière les centres de récompense du cerveau, et offrir une incitation à continuer à apprendre, à repousser les limites des connaissances et, tout simplement, à développer des logiciels de meilleure qualité est une solution gagnant-gagnant.

Bilan de santé de la culture de sécurité : le vôtre est-il sous assistance respiratoireT ?

Créer un logiciel sécurisé dans un environnement où la culture de la sécurité est médiocre, c'est comme essayer de gagner un marathon avec un rocher enchaîné à la cheville : pratiquement impossible et inutilement difficile.

Des formations ludiques, des tournois en tête-à-tête et l'engagement à aider les développeurs dans leur développement en matière de sécurité contribuent énormément à créer une culture de sécurité positive, les équipes de développement et AppSec ayant ainsi une meilleure connaissance du travail quotidien de chacun. De meilleures relations se développent et prospèrent, et le budget de sécurité (souvent limité) n'est pas dépensé pour corriger à maintes reprises un scénario du « jour de la marmotte » contenant les mêmes petits bugs ennuyeux.

Il existe également un autre sous-produit puissant : la découverte de champions de la sécurité dont vous ignoriez l'existence. Une formation appropriée qui implique tout le monde, tout en permettant une évaluation approfondie, peut permettre de découvrir ceux qui non seulement ont des aptitudes en matière de sécurité, mais qui manifestent activement une passion pour celle-ci. Ces champions jouent un rôle essentiel pour maintenir la dynamique et servir de point de contact entre les équipes, superviser les pairs et faire respecter les politiques relatives aux meilleures pratiques. La mise en œuvre d'un solide programme de champions, qui inclut la reconnaissance et le soutien de la direction, est un atout majeur pour l'organisation, en plus de figurer très impressionnant sur le CV de l'individu et de renforcer sa future carrière.

Lorsque vous vous engagez à adopter une culture de sécurité positive, les responsabilités sont partagées et vous pouvez atteindre un niveau supérieur d'excellence en matière de logiciels sécurisés. En fin de compte, chaque personne participant au cycle de vie du développement logiciel doit adhérer à un mantra simple : s'il ne s'agit pas d'un logiciel sécurisé, ce n'est pas un bon logiciel.

Faites passer le message.