L'évolution de la sécurité dans DevOps implique un changement des mentalités

Il y a très longtemps, lorsque j’étais un jeune administrateur système UNIX idiot (je ne suis plus qu’une de ces choses maintenant), j’ai commis une erreur de sécurité assez grave sur l’un des serveurs qui exécutaient nos systèmes de sauvegarde. Je n’entrerai pas dans les détails, mais cela avait à voir avec la commande sudo, un éditeur de texte et l’ignorance.

Heureusement, l’un des administrateurs système les plus expérimentés (et franchement, les plus intelligents) m’a soutenu. Ils avaient remarqué ma nouvelle procédure, l’avaient étudiée… et m’avaient ensuite poliment pris à part pour m’expliquer mon erreur. Ils ont ensuite passé du temps à m’aider à trouver une solution qui offrirait toujours aux gens la fonctionnalité de libre-service dont ils avaient besoin, mais avec moins de risques de catastrophe. Dans ma mémoire auto-éditée et peu fiable, j'étais reconnaissant des améliorations, à la fois pour moi et pour ma configuration.

Ce comportement de partage, de collaboration et de résolution de problèmes sans reproche m’est resté au fil des années et j’espère avoir parfois pu aider quelqu’un à résoudre ses problèmes de sécurité.  

Dans cet esprit, il n’est pas surprenant, à la lecture du rapport Puppet State of DevOps, de constater que lorsque vous intégrez la sécurité plus tôt dans le cycle de vie de livraison des logiciels, le résultat est – attendez – une meilleure sécurité.

En examinant le rapport, il apparaît clairement que les avantages du transfert de la sécurité vers le cycle de vie du logiciel reposent autant, sinon plus, sur le transfert de ces principes de comportement DevOps vers les équipes de sécurité que sur le transfert des outils de sécurité vers les pipelines.

Alors que les pratiques opérationnelles de sécurité plus traditionnelles se concentrent sur les tests et les contrôles (la plupart des équipes d’application auront déjà reçu un rapport de sécurité généré par un outil indiquant plusieurs problèmes à résoudre), une approche basée sur les principes DevOps encourage la collaboration précoce, le partage et la responsabilité conjointe.

En examinant la section « Améliorer la posture de sécurité » du rapport (à partir de la page 31), il est important d’apprécier à quel point il est important d’intégrer sans heurts la réflexion sur la sécurité dans la conception et la construction des logiciels et de l’infrastructure, plutôt que de simplement mettre en place les bons contrôles et la bonne technologie.

Si les bénéfices reposent sur le partage et l’intégration des compétences et de l’état d’esprit des professionnels de la sécurité au cœur du pipeline de livraison de logiciels, alors certains des changements les plus significatifs seront comportementaux.

Immerger une équipe de sécurité dès le début du cycle de développement logiciel nécessitera certainement qu’elle s’adapte, mais ces changements devront aller dans les deux sens. Alors que les professionnels de la sécurité devront adopter de nouvelles méthodes de travail (et probablement apprendre à parler plus « dev » qu’ils ne le font actuellement), l’équipe de développement devra peut-être adopter le Tao du cordon Andon .

Si vous n’avez pas encore étudié le cordon Andon et sa place dans le processus de fabrication de contrôle qualité mis au point par Toyota, cela vaut la peine d’y consacrer du temps. Il existe des articles, des articles universitaires, des livres entiers et même des cours d’enseignement supérieur traitant du sujet. Mais avant d'abandonner votre carrière technologique pour poursuivre ce MBA que vous vous êtes toujours promis, terminez cet article, car je pense que le fait le plus significatif concernant le cordon Andon est à la fois le plus simple et le plus difficile à réaliser.

Lorsqu'un ouvrier sur une chaîne de production tire sur son cordon Andon pour arrêter la production en raison d'un défaut, la première chose que font ses collègues et l'équipe de direction est de se précipiter vers lui et de le remercier. Et ils doivent le penser. Tirer sur le cordon Andon est considéré comme une bonne chose, car c'est un pas vers l'amélioration de la qualité. Les dirigeants et les collègues sont reconnaissants que la chaîne de production soit arrêtée en raison d’un problème, car c’est une opportunité de s’améliorer.

Votre équipe de développement peut-elle accepter que l’équipe de sécurité trouve des défauts et tire le cordon (virtuel) avec gratitude ? Une équipe DevOps peut-elle apprendre à valoriser les builds ou les déploiements qui échouent aux tests de sécurité autant que ceux qui réussissent ?

Les futurs propriétaires d’entreprise peuvent-ils apprendre que, pour créer d’excellents logiciels, nous devons rechercher des échecs de test plus fréquents à mesure que nous créons des tests de plus en plus performants qui identifient les problèmes avant qu’ils ne deviennent apparents lors d’un déploiement ?

Cela peut être une adaptation mentale difficile.

Bien que je sois reconnaissant pour les inévitables corrections d'édition qui auront été appliquées à cet article au moment où vous le lirez, il n'est pas toujours facile de voir ce que vous avez créé disséqué par d'autres. Votre cerveau rationnel sait qu'il fournit un meilleur produit, mais votre chimpanzé intérieur veut juste balancer ses bras dans tous les sens.

Ainsi, même si cet état d’esprit peut être difficile à adopter, il est essentiel pour réussir à intégrer la sécurité dès le début du cycle de vie du logiciel, et bien meilleur que les examens a posteriori et les corrections hâtives.

Changer les attitudes est un tout autre domaine d’étude, mais les dirigeants et les praticiens de l’informatique doivent devenir compétents, surtout en cette période de révolution des méthodes de travail. C’est souvent (beaucoup) plus difficile que de simplement adopter une nouvelle technologie. Si vous voulez réussir à « virer à gauche » en matière de sécurité — et les données de ce rapport indiquent que vous devriez le faire — alors consacrez autant de temps aux éléments humains qu’aux éléments techniques.