La sécurité d’abord ! Stratégies pour créer des logiciels plus sûrs

“Je pense honnêtement que la vie serait meilleure pour tout le monde si tous les professionnels de la sécurité étaient étranglés à la naissance”, m’a murmuré le responsable des logiciels alors que nous quittions une réunion particulièrement agitée avec l’équipe de sécurité.

C’était à la fin des années 1990 et nous venions d’investir six mois d’efforts dans le développement d’une nouvelle plate-forme d’interrogation de données en libre-service basée sur un navigateur. Si seulement nous pouvions l’adopter, cela permettrait à l’entreprise d’économiser énormément d’argent et de libérer du temps dans l’équipe d’information de gestion sous-financée, leur permettant de se concentrer sur un travail beaucoup plus intéressant et stratégique. Cependant, il s’appuyait sur une applet Java pour l’interface utilisateur client, ce qui signifiait bien sûr permettre à Java de s’exécuter dans le navigateur.

Nous avions déjà réalisé un projet pilote réussi depuis notre siège de Londres et cherchions à l’étendre au bureau de New York, mais l’équipe de sécurité a catégoriquement refusé car, selon eux, Java représentait un risque de sécurité trop important. Aucun d’entre nous n’expliquait le modèle de bac à sable intégré de Java, les mesures supplémentaires que nous avions mises en place en plus de cela ou nos plaidoiries pures et simples n’allaient les persuader du contraire.

L’implication de la sécurité dans les premières étapes d’un processus de développement logiciel a toujours eu du sens, car pour la correction de bogues, il est plus rapide et moins cher de résoudre les problèmes de sécurité dès le début. Mais, en particulier dans les grandes entreprises, cela se faisait rarement dans la pratique. De la même manière, les équipes de développement individuelles auraient tendance à ne pas investir dans la sécurité si elles y voyaient le rôle d’une équipe de sécurité dédiée et donc le problème de quelqu’un d’autre.

Cela a poussé la sécurité vers la droite, comme l’une des choses qui se sont produites entre le développement et le déploiement en production, où la sécurité devient plus difficile et souvent moins efficace.

Cela a également conduit à des frictions entre les équipes de développement et de sécurité, car les deux groupes avaient des objectifs contradictoires : les développeurs étaient sous pression pour livrer plus de fonctionnalités plus rapidement et considéraient la sécurité comme un gardien, ralentissant ou même arrêtant le développement pour laisser le temps d’enquêter sur les problèmes. . À l’extrême, les développeurs ont estimé que la situation idéale de la sécurité serait que rien ne serait déployé du tout en production – après tout, si rien ne fonctionne, alors rien ne peut être piraté.

À l’inverse, l’équipe de sécurité était incitée à assurer la sécurité des systèmes et des données et était sous pression pour maintenir les risques de sécurité à un minimum absolu. Ils se faisaient crier dessus par la haute direction, voire licenciés, si une infraction se produisait et se demandaient pourquoi nous, les développeurs de logiciels, étions des cow-boys si irresponsables.

Traditionnellement, la sécurité se concentrait sur un périmètre d’application bien compris, entourant généralement un seul centre de données. Les applications modernes, cependant, sont rarement monolithiques ; ils sont plutôt composés de microservices s’exécutant dans plusieurs environnements et communiquant sur plusieurs réseaux. Ils présentent une surface d’attaque complexe et large qui ne peut être défendue uniquement avec les bases de l’analyse de code et de bonnes pratiques de programmation, aussi importantes soient-elles.

L’entreprise doit donc exécuter un changement culturel intentionnel qui, comme c’est devenu un adage, fait de la sécurité une partie intégrante du travail de chacun. Mais qu’est-ce que cela signifie en pratique ?

Petit, Moyen ou Grand ?

Une chose à garder à l’esprit est que cela varie selon la taille de l’organisation. Il est peu probable que les petites startups soient en mesure de se permettre tous les spécialistes que vous souhaiteriez idéalement – administrateurs de bases de données, responsables de la sécurité, responsables de la convivialité, etc.

Dans cette situation, consultant en technologie et auteur O’Reilly Sam Newmann a déclaré à The New Stack: «Soit vous dites que vous ne vous en souciez pas, soit vous déchargez ce travail sur quelqu’un d’autre. C’est pourquoi les très petites boutiques devraient utiliser le cloud public, car vous achetez de l’expertise à ce stade. Même si vous utilisez des machines virtuelles gérées, le fournisseur de cloud fera un meilleur travail de correction de ces machines et de surveillance des actes criminels que vous ne le pouvez.

Les startups ont cependant l’avantage d’une table rase. Dans l’une d’entre elles où j’étais architecte principal, nous avons fait appel à une personne chargée de la sécurité avant la phase de conception, travaillant avec les développeurs, aidant à les éduquer, documentant les politiques de sécurité et les meilleures pratiques, et entraînant tout le monde à adopter un état d’esprit de sécurité. Il a également travaillé avec les analystes commerciaux pour, comme il l’a dit de manière mémorable, “les encourager tous à penser comme des belettes sournoises”.

Puis, alors que nous nous concentrions sur la construction du système, il a audité manuellement le code, ce qui a révélé un certain nombre de problèmes, tels que les mots de passe enregistrés en texte brut en mode débogage (ma faute, embarrassant), et a aidé à éduquer les développeurs sur les meilleurs les pratiques.

Cet accent mis sur les meilleures pratiques fonctionne bien pour les petites entreprises, Garde-chaînec’est Adrien Mouat nous a dit, et est maintenant pris en charge par certains des outils.

“Par exemple, si vous regardez quelque chose comme docker initqui est actuellement en version bêta, je peux l’utiliser et cela produira un nouveau projet Go, Python ou Node, et le fichier Docker qu’il crée contient déjà certaines des meilleures pratiques de sécurité », a-t-il déclaré.

L’introduction de scanners pour les images de conteneurs a également permis d’automatiser une partie de cet audit manuel, et avoir l’analyse plus tôt dans le processus est une bonne idée, a déclaré Mouat.

“Lorsque les scanners sont sortis pour la première fois, nous pensions mettre le scanner d’images juste avant le déploiement en production afin que tout ce qui présente des vulnérabilités ne soit pas déployé. Le problème est qu’il y a tellement de vulnérabilités que cela ne fonctionne pas vraiment. Il vaut mieux que les développeurs le fassent, car ils peuvent se rendre compte qu’ils ont ajouté cette vulnérabilité dans leur code, puis ils peuvent la corriger.

Les changements culturels nécessaires pour déplacer la sécurité vers la gauche signifient de nouvelles façons de travailler pour toutes les personnes impliquées, mais “ce que cela ne signifie pas, ce sont les développeurs qui font tout le travail”, a déclaré Sam Newman, consultant et auteur.

Des outils de sécurité destinés principalement aux développeurs, tels que Couler et Eclaireur Docker (actuellement en accès anticipé), peuvent être très utiles ici, car ils mettent non seulement en évidence les vulnérabilités, mais fournissent également des conseils sur la manière de les résoudre.

Bien sûr, en utilisant une image minimale à jour sans vulnérabilités connues, telles que Images de garde-chaîne est une bonne idée aussi. De nombreuses vulnérabilités se trouvent dans le « fouillis » superflu et inutile d’une image, et des choses comme la suppression d’un shell d’une image de base ferment les points d’accès potentiels pour les attaquants.

Virage à gauche dans les grandes organisations

Bien que ces outils soient utiles, dans les grandes organisations, ce sont les aspects culturels qui ont tendance à passer au premier plan, car de nombreux facteurs, des processus enracinés au budget en passant par la politique de l’entreprise, peuvent faire obstacle.

Pour cette raison, les changements culturels nécessaires pour déplacer la sécurité vers la gauche signifient de nouvelles façons de travailler pour toutes les personnes impliquées, mais “ce que cela ne signifie pas”, nous a dit Newman, “ce sont les développeurs qui font tout le travail”.

Mouat a accepté, déclarant à The New Stack : « Il y a beaucoup de connaissances en sécurité requises, même dans des choses assez basiques comme la configuration d’images de conteneurs et de fichiers Docker, et parce qu’il est assez facile de se tromper, avoir des gens de la sécurité intégrés dès le début. est un grand avantage.

En fin de compte, selon Newman, le professionnel de la sécurité doit se concentrer sur le oui : “Je vais faire de mon mieux pour déterminer comment nous pouvons faire ce que vous voulez faire de la manière la plus sûre possible.”

Cependant, cela ne se produit pas si vous n’êtes pas incité à le faire. “Donc”, a poursuivi Newman, “le déplacement vers la gauche consiste à impliquer les gens tôt, à avoir des objectifs alignés et des buts alignés, mais aussi à aligner les incitations dures et douces. Sans cela, je ne pense pas que cela fonctionne du tout.

SafeStack PDG Laura Bell a suggéré qu’il y a deux dysfonctionnements qui peuvent survenir avec les professionnels de la sécurité. Le premier est celui avec lequel nous avons commencé (le responsable de la sécurité dit non); l’autre est qu’une personne chargée de la sécurité, avec les meilleures intentions du monde, suggère un outil pour le pipeline CI/CD. Cependant, comme ils ne sont pas nécessairement développeurs, ou peut-être ne l’ont-ils pas été depuis un certain temps, l’outil est trop lourd et fait exploser le temps de construction, ou fournit d’énormes quantités d’informations que les développeurs ne savent tout simplement pas quoi faire. avec.

Newman a suggéré que l’atténuation ici pourrait consister à impliquer les développeurs dans un exercice de modélisation des menaces.

“Je sais qu’un modèle de menace est généralement une activité assez transactionnelle”, nous a-t-il dit, “mais dans le cadre de celui-ci, un expert en sécurité examinera quels sont nos actifs, menaces et risques. Il n’y a aucune raison pour que les développeurs ne puissent pas être impliqués dans ce processus, et à la suite de cela, ils auront une meilleure compréhension du genre de choses qui inquiètent les responsables de la sécurité. Désormais, lorsqu’un responsable de la sécurité dit que nous ne devrions pas faire x, y ou z, le développeur aura une meilleure compréhension de l’impact d’une erreur, et il pourrait également trouver d’autres moyens d’atténuer ces menaces qui correspondent mieux à ses façons de faire. fonctionnement.”

Bien sûr, même si vous avez déjà effectué un exercice de modélisation des menaces sur un système, il n’y a aucune raison de ne pas le répéter pour aider les développeurs et les professionnels de la sécurité à obtenir un contexte partagé. Cela a d’autres avantages. C’est un peu une généralisation, mais les développeurs ont tendance à se concentrer sur la nouvelle chose brillante, donc, a déclaré Bell, nous pourrions lire dans la presse des acteurs parrainés par l’État piratant des systèmes et commencerons à penser à nous protéger de ceux-ci. problèmes. Le problème ici est qu’en réalité, les incidents de sécurité sont généralement beaucoup plus prosaïques, et une évaluation des menaces peut vous aider à mieux comprendre cela.

Si votre équipe de développement et votre équipe de sécurité ont des motivations différentes, vous devez passer du temps à essayer d’atteindre un objectif et un ensemble de valeurs communs.

Selon Newman, un autre problème est que les développeurs ont tendance à ignorer quatre des cinq fonctions du cadre NIST, se concentrant uniquement sur la protection. C’est parce que les développeurs pensent que c’est la seule chose sur laquelle ils ont un réel contrôle. Mais en réalité, ils peuvent avoir un impact sur les cinq fonctions. Le conseil de Bell ici était de jouer un rôle sur un incident de sécurité avec à la fois des techniciens, y compris des développeurs, et des non-techniciens.

Newman a ajouté : « En tant que développeur dans cette salle, vous réalisez soudainement qu’il y a toutes ces autres choses qui doivent se produire, et nous n’avons pas les éléments nécessaires en place pour repérer ces choses en premier lieu.

En termes d’établissement de meilleures pratiques à grande échelle, une option est analogue au fonctionnement d’une équipe de plate-forme. Dans ce modèle, la sécurité devient un catalyseur de bonnes pratiques, fournissant un chemin doré et des garde-fous qui protègent les applications et l’infrastructure sans mettre d’obstacles à la livraison de l’ingénierie. Mais nous devons souligner que cela ne remplace pas des conversations significatives.

“Il doit y avoir une conversation continue sur ce que je devrais faire en tant qu’ingénieur, par rapport à ce que vous devriez faire en tant qu’expert. Il n’y a pas de bonne réponse à cela pour toutes les organisations, et la réponse variera d’une organisation à l’autre », a déclaré Newman.

En d’autres termes, si votre équipe de développement et votre équipe de sécurité ont des motivations différentes, vous devez passer du temps à essayer d’atteindre un objectif et un ensemble de valeurs communs. D’après mon expérience, cela revient généralement à être motivé par le désir de créer un bon produit.

Nous devons ajouter qu’il est déraisonnable de demander aux développeurs de prendre la sécurité au sérieux et de s’attendre simultanément à ce que le même rythme de livraison des fonctionnalités soit maintenu. Donc au niveau organisationnel, il faut être prêt à ralentir un peu pour se concentrer sur la qualité.

Enfin, il faut dire que, de la même manière qu’il n’existe pas de logiciel sans bug, il n’existe pas de logiciel sans faille de sécurité. Donc, une partie de cela doit être une discussion sur le nombre et les problèmes de sécurité acceptables, comme avec un budget d’erreur dans la pratique de l’ingénierie de la fiabilité du site.