Passer à gauche ne suffit pas : Pourquoi commencer à gauche est la clé de l'excellence en matière de sécurité des logiciels

Dans un monde dominé par le numérique, nous sommes de plus en plus exposés au risque de vol de données. Les grandes organisations étant les gardiennes de nos précieuses informations, nombre d'entre elles reconnaissent la nécessité de mettre en œuvre des normes de sécurité rigoureuses.

La plupart des initiatives visant à "passer à gauche", c'est-à-dire à introduire la sécurité beaucoup plus tôt dans le processus de développement, ne font tout simplement pas avancer l'aiguille assez loin. Cela implique que nous commençons toujours le processus de la mauvaise manière, en faisant finalement marche arrière pour atteindre le résultat d'un logiciel plus sûr. Nous devons commencer à gauche, en mettant en œuvre un changement culturel qui engage positivement les équipes de développement et les arme avec les connaissances qui leur manquent actuellement. Cependant, toutes les formations et tous les outils ne sont pas égaux.

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

Déplacement vers la gauche ou départ vers la gauche : Une distinction importante.

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

Depuis un certain temps, les spécialistes de l'AppSec (dont je fais partie) conseillent de "passer à gauche". En accord avec les meilleures pratiques DevOps, ainsi qu'avec les meilleurs résultats en matière de sécurité des logiciels, beaucoup d'entre nous ont conseillé que la partie sécurité d'un logiciel soit intégrée plus tôt dans le cycle de vie du développement logiciel (SDLC). Elle ne devrait pas être l'étape finale et coûteuse, mais plutôt se rapprocher du début du processus, avec des équipes AppSec impliquées dès que les projets logiciels prennent vie.

Ce n'est pas un mauvais conseil, et c'est certainement mieux que l'ancienne façon de faire (qui, si l'on en croit la quantité de données volées et l'âge des vulnérabilités utilisées pour les voler, ne fonctionne de toute façon pas). Cependant, si nous commencions à partir de la gauche, les résultats en matière de sécurité seraient bien plus positifs.

Passer à gauche, commencer à gauche... quelle est la différence ? La différence réside dans la manière dont vous engagez votre équipe de développement. En effet, ils sont la clé pour fournir des logiciels plus sûrs, à un coût bien inférieur à celui des chaînes d'outils de cycle ultérieur et de l'examen manuel du code. Dans un monde idéal, chaque développeur qui écrit un logiciel aurait les connaissances et les outils nécessaires pour coder de manière sécurisée dès le début. Ils repéreraient les failles potentielles et les atténueraient avant qu'elles ne soient validées (et donc beaucoup plus coûteuses à éliminer et à corriger). Il y aurait une réduction spectaculaire des bogues de sécurité que nous voyons depuis des décennies - ceux qui sont encore responsables de permettre aux attaquants d'entrer par la porte de derrière. Ces fenêtres d'opportunité sous forme d'injection SQL, de scripts intersites et d'authentification défectueuse se refermeraient.

Cependant, à l'heure actuelle, la sécurité n'est tout simplement pas suffisamment mise en avant au niveau professionnel, et la formation au codage sécurisé sur le lieu de travail varie considérablement. En conséquence, les développeurs disposent rarement de ce dont ils ont besoin pour permettre à une organisation de partir à gauche. Il est temps que les responsables travaillent ensemble et plaident en faveur d'une plus grande sensibilisation à la sécurité, leur connaissance directe et leur contact avec les développeurs étant essentiels pour mettre en place des programmes qui fonctionnent. Après tout, les responsables du développement étaient autrefois dans leur position, avec des outils et un espace de sécurité difficile à naviguer dans le meilleur des cas.

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

Vous savez ce qu'il en est : si vous parlez de "sécurité" à un développeur typique, vous risquez d'obtenir au mieux un haussement d'épaules, au pire de la perplexité. En général, la sécurité est considérée comme le problème de quelqu'un d'autre.

Un développeur a pour principale responsabilité de créer des logiciels fonctionnels, dotés de fonctionnalités innovantes et livrés dans des délais serrés. La sécurité est rarement une priorité au niveau du codage, et peut même être considérée comme un obstacle fastidieux à une livraison rapide et à la créativité. L'AppSec a pour tâche de vérifier méticuleusement le code, de procéder à des tests d'intrusion, puis de signaler les mauvaises nouvelles : la présence de vulnérabilités de sécurité dans un code qui a souvent déjà été validé et qui fonctionne très bien par ailleurs. Il s'agit d'un processus coûteux dans un environnement souvent à court de ressources et de temps, dont la mise en place est susceptible de provoquer un clivage entre deux équipes qui ont en fin de compte le même objectif, mais qui parlent des langues complètement différentes.

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

Toutes les formations ne sont pas égales.

À quand remonte la dernière fois où vous avez été vraiment enthousiaste à l'idée d'apprendre quelque chose de nouveau ? Si c'est le cas, des mots comme "obligatoire", "conformité" ou "dix-sept heures de vidéo" ne vous sont probablement pas venus à l'esprit.

Les développeurs ne sont pas différents. Ils sont intelligents, créatifs et aiment résoudre des problèmes. Il est peu probable que le fait de regarder d'interminables vidéos sur les vulnérabilités en matière de sécurité les intéresse, que le contenu reste mémorable ou qu'il soit spécifique à leur rôle et à leurs responsabilités au quotidien. En tant qu'instructeur SANS, il m'est apparu très tôt que la meilleure formation est pratique, obligeant les participants à analyser et à être défiés intellectuellement, en utilisant des exemples du monde réel qui mettent leur cerveau à l'épreuve et s'appuient sur leurs connaissances antérieures. La gamification et la compétition amicale sont également des outils puissants pour faire adhérer tout le monde à de nouveaux concepts, tout en restant utiles et pratiques dans l'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 l'observe, mais à quoi bon consacrer du temps, de l'argent et des efforts à la formation si personne n'en vérifie la pertinence ?

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. La formation gamifiée stimule les centres de récompense du cerveau et offre une incitation à continuer à apprendre, à repousser les limites de la connaissance et, tout simplement, à construire un logiciel de meilleure qualité, c'est une situation gagnant-gagnant.

Bilan de santé de la culture de la sécurité : La vôtre est-elle sous respirateur artificiel?

Créer des logiciels sûrs dans un environnement où la culture de la sécurité est médiocre revient à essayer de gagner un marathon avec un rocher enchaîné à la cheville : c'est pratiquement impossible et inutilement difficile.

La formation par le jeu, les confrontations directes sur tournaments 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 d'AppSec et de développement ayant 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 épuisé par la correction des mêmes petits bogues gênants, comme dans un "jour de la marmotte".

Il existe également un autre sous-produit puissant : la découverte des champions de la sécurité dont vous ne soupçonniez pas l'existence. Une formation appropriée qui implique tout le monde, tout en permettant un examen approfondi du site assessment, peut permettre de découvrir ceux qui ont non seulement des aptitudes en matière de sécurité, mais qui en sont également passionnés. Ces champions sont essentiels pour maintenir l'élan et servir de point de contact entre les équipes, superviser les pairs et faire respecter les politiques de 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 pour l'organisation, mais aussi pour le CV de la personne concernée et pour sa future carrière.

Lorsque vous vous engagez dans une culture de sécurité positive, la responsabilité est partagée et un niveau plus élevé d'excellence en matière de logiciels sécurisés peut être atteint. En fin de compte, chaque personne intervenant dans le cycle de développement des logiciels doit adhérer à un mantra simple : s'il ne s'agit pas d'un logiciel sécurisé, il ne s'agit pas d'un bon logiciel.

Faites passer le message.