En tant que spécialiste des opérations dans une entreprise de sécurité cloud, j'ai une vision unique de la façon dont la sécurité et les opérations peuvent – ​​et devraient, idéalement – ​​collaborer. Un problème courant dans le secteur technologique actuel est que la sécurité est presque toujours intégrée trop tard dans le processus de développement.

On peut avoir l'impression que la sécurité est une discipline à part entière, et l'intégrer aux boucles de rétroaction DevOps peut sembler une tâche ardue. Mais je suis là pour vous dire que non seulement peut C'est faisable, mais ce n'est pas aussi difficile qu'il n'y paraît — et bien le faire fera une grande différence dans votre posture de sécurité globale tout en éliminant une foule de points faibles.

Plus précisément, le concept de « décalage vers la gauche » permet aux équipes d'intégrer plus tôt les processus de sécurité qu'elles traitaient auparavant beaucoup plus tard dans le processus de déploiement (voire pas du tout), afin de garantir que la sécurité soit intégrée dès la conception et non considérée comme une simple réflexion a posteriori. Dans cet article, j'expliquerai comment procéder.

Que signifie « Trop tard » ?

Tout d'abord, examinons rapidement comment la sécurité est intégrée aux processus DevOps aujourd'hui. Bien souvent, elle ne l'est tout simplement pas. Cela se traduit par des ingénieurs déployant le code dès qu'il est prêt, sans aucune prise en compte de la sécurité. Bien sûr, les développeurs qui agissent ainsi ne font que leur travail. Ils subissent la pression des équipes produit pour la mise en production des nouvelles fonctionnalités et font simplement le nécessaire pour déployer le code au plus vite.

Dans d'autres cas, les équipes de sécurité sont intégrées au processus et deviennent les garantes de la sécurité, exigeant une revue de sécurité avant la mise en production du code. Il est positif de voir les experts en sécurité impliqués et le code examiné afin de détecter les failles de sécurité. Cependant, attendre la dernière minute peut entraver les cycles de livraison continue, et dans le contexte actuel, où tout va très vite, ce n'est souvent pas envisageable. Sans compter que cela peut engendrer de réelles tensions entre ces équipes en les opposant les unes aux autres.

Comment commencer à passer à gauche

Ces dernières années, de plus en plus d'organisations optimisent leurs équipes DevOps pour gagner en rapidité et assurer une livraison continue de logiciels. Il est temps d'intégrer la sécurité à cette démarche ; voici donc mes conseils pour y parvenir.

Utilisez les mêmes outils

Il est essentiel que vos équipes de sécurité se familiarisent avec les mêmes outils d'intégration et de déploiement continus que vos équipes DevOps. C'est ainsi que les équipes Dev et Ops ont commencé à collaborer efficacement : en apprenant aux équipes Ops à coder et aux développeurs à utiliser des outils de gestion de configuration comme Chef. Il est temps d'appliquer cette méthode à la sécurité.

Jenkins C'est un excellent exemple. Si vos développeurs utilisent déjà Jenkins pour tester et déployer du code, pourquoi ne pas former votre équipe de sécurité à son utilisation ? S'ils utilisent le même outil pour les tests de sécurité, il sera beaucoup plus facile de les intégrer au processus dès le départ.

Un autre outil formidable s'appelle Gantelet J’ai certes quelques réserves quant au terme « DevOps robuste », mais l’idée derrière Gauntlt est intéressante. Extrait de leur site :

Gauntlt offre une intégration à divers outils de sécurité et les met à la disposition des équipes de sécurité, de développement et d'exploitation pour collaborer à la création de logiciels robustes. Il est conçu pour faciliter les tests et la communication entre les groupes et créer des tests exploitables qui peuvent être intégrés à vos processus de déploiement et de test.

L'idée d'intégrer la sécurité au cœur de vos processus opérationnels et de développement est fondamentalement judicieuse. Ainsi, la sécurité n'entrave pas la livraison et vous pouvez optimiser le cycle de retour d'information dès qu'un problème est détecté. Les équipes de sécurité peuvent écrire du code avec Gauntlt et le tester avant sa mise en production, ce qui favorise une livraison continue et réussie.

Essayez l'analyse statique

Une autre option consiste à essayer l'analyse statique à l'aide d'un outil comme Veracode Vos équipes de sécurité peuvent ainsi analyser le code avant le déploiement et tenter de déceler les problèmes potentiels. L'analyse statique consiste à analyser le logiciel sans exécuter le code. Les équipes de sécurité peuvent l'utiliser pour rechercher automatiquement les vulnérabilités potentielles, sans interrompre le cycle de livraison du logiciel.

Alignement des incitations

Historiquement, l'un des obstacles à la collaboration entre DevOps et sécurité réside dans leurs motivations contradictoires. DevOps privilégie la rapidité de déploiement du code, tandis que la sécurité n'est avantagée que par la mise en production de code sécurisé.

Les équipes DevOps et les équipes de sécurité collaborent plus efficacement lorsqu'elles utilisent des outils identiques ou compatibles, comme expliqué précédemment. Mais pour aller plus loin, il est également essentiel d'aligner les incitations entre ces équipes. Cela implique de récompenser les équipes DevOps pour la mise en production de code sécurisé et les équipes de sécurité pour leur rapidité d'exécution.

Fournir la propriété

Une erreur fréquente que nous constatons est celle des équipes où la sécurité n'a même pas accès à la production. Si la sécurité n'a pas de responsabilité directe sur le code, il est certain qu'elle ne sera pas étroitement intégrée aux cycles DevOps.

En revanche, lorsqu'on responsabilise les spécialistes de la sécurité et qu'on leur apprend à résoudre eux-mêmes les problèmes de code, ils deviennent un rouage essentiel d'une machine bien huilée plutôt qu'un service isolé. Par exemple, Pile de menaces Vous pouvez ainsi alerter votre équipe en cas de problème de sécurité. Si vous formez les équipes de sécurité à résoudre ces problèmes et leur donnez accès au code de gestion de la configuration, elles pourront intervenir directement et modifier le système.

De la même manière, Cuisinier a rendu open source un outil appelé InSpec InSpec est un framework d'audit et de test. Grâce à lui, les équipes de sécurité peuvent développer du code pour auditer les serveurs et garantir la conformité. Cela leur confère un contrôle bien plus direct sur le processus. Donnez aux équipes de sécurité les moyens de perfectionner leurs compétences DevOps, et vous constaterez les résultats.

Une autre approche (surtout si vous n'avez pas d'équipe de sécurité dédiée) consiste à confier la correction du code aux ingénieurs backend en cas de failles de sécurité. Lorsqu'ils sont directement responsables de la sécurité de leur code, ils sont bien plus enclins à le concevoir de manière sécurisée dès le départ. Chez Threat Stack, nous avons deux personnes en charge des opérations et dix ingénieurs backend d'astreinte. Ainsi, lorsqu'un problème survient avec le produit, ce sont généralement les équipes d'ingénierie backend qui ont écrit le code qui sont sollicitées pour le résoudre. Ce niveau de… propriété du code cela les incite à bien le construire dès le départ.

La voie à suivre est latérale.

Intégrer la sécurité en amont du processus de développement est bénéfique pour la santé globale de votre entreprise. Au lieu de se contenter de détecter les problèmes, d'ouvrir des tickets et d'attendre que les développeurs ou les équipes d'exploitation les résolvent, les équipes de sécurité sont habilitées à agir elles-mêmes. Cela permet non seulement de gagner du temps et des ressources humaines, mais aussi de garantir un déploiement continu et sécurisé du code. Il est essentiel que tous les acteurs impliqués se montrent plus proactifs et cherchent à comprendre le fonctionnement des autres équipes afin de mieux s'intégrer à leurs processus.

Les conseils ci-dessus devraient vous fournir un point de départ pour faire de la « sécurité intégrée dès la conception » une réalité au sein de votre organisation. N'oubliez pas que, comme pour de nombreux aspects de la sécurité, cela nécessite… changement culturel (Il ne s'agit pas simplement d'introduire de nouveaux outils.) Mais c'est possible avec la bonne mentalité, les bonnes incitations et des mécanismes de rétroaction adaptés.