- PagerDuty /
- Blog /
- Communauté /
- La transformation culturelle de DevSecOps
Blog
La transformation culturelle de DevSecOps
Prenons un instant pour réfléchir à la sécurité dans votre organisation. La sécurité est souvent séparée des autres équipes d'ingénierie telles que le développement, les opérations, le réseau, l'informatique, etc. Si vous concentrez votre attention sur la publication de nouveaux logiciels ou de nouvelles fonctionnalités dans les logiciels existants, vous constaterez que même si le développement et les opérations travaillent ensemble très rapidement et efficacement, ils confient toujours ces fonctions et fonctionnalités à la sécurité. Et la sécurité les confie à la sécurité, un peu comme le faisaient le développement et les opérations avant DevOps.
DevSecOps fait pour le développement, les opérations et la sécurité ce que DevOps a fait pour le développement et les opérations : c'est une pratique culturelle, avec un support technologique, qui rationalise le travail de ces équipes afin qu'elles puissent travailler ensemble. Comme pour DevOps, une partie de la transformation culturelle de DevSecOps consiste à développer l'empathie les uns envers les autres en comprenant les différentes exigences de chaque équipe.
Le quoi et le comment de DevSecOps
DevSecOps ne supprime pas l’équipe de sécurité, ni la nécessité de la sécurité en tant que discipline (à moins que vous ne souhaitiez apprendre à réaliser vos propres tests de pénétration, entre autres, sans leur aide ou leurs conseils, ce que je ne recommande pas). De la même manière, DevOps n’a pas éliminé le besoin d’opérations, mais a changé la façon dont les équipes d’opérations et de développement travaillaient ensemble.
Le DevSecOps est un peu différent du DevOps quant à la manière dont cela se déroule. Pour rappel, le modèle DevOps ressemble à ceci :
Dans le flux de travail ci-dessus, vous pouvez voir que le développement et les opérations sont toujours séparés, mais ne sont plus cloisonnés. Le modèle DevSecOps ressemble à ceci :
Comme vous pouvez le constater, la sécurité est intégrée à chaque aspect du cycle DevOps. Elle n’est pas séparée comme le développement et les opérations.
Pour ce faire, il faut procéder à ce que l’on appelle le « shifting left » (c’est-à-dire intégrer la sécurité de plus en plus tôt dans le cycle, en commençant par la phase de conception/construction). Différents tests et autres activités doivent être effectués à chaque étape. Par exemple, si l’on considère la sécurité au stade du code, celle-ci devra participer aux revues de code, ainsi qu’à l’exécution de tests tels qu’un SAST (test de sécurité statique des applications) et/ou une SCA (analyse de la composition logicielle). La détection des problèmes à ce stade signifie qu’ils sont résolus ici, avant la construction, les tests, etc. Le même principe s’applique à chaque phase : plus une vulnérabilité de sécurité est détectée tôt, moins elle est coûteuse en termes de temps et d’expertise.
Établir une empathie interfonctionnelle
De nombreux spécialistes de la sécurité n’ont pas d’expérience dans l’exécution de services en production. De même, de nombreux développeurs et spécialistes des opérations n’ont pas d’expérience en matière de sécurité. Afin de combler ces lacunes, il est important de « se mettre à la place des autres ».
Pour la sécurité, cela signifie posséder un service en production. Notez qu'il est important que l'équipe s'approprie le cycle de vie complet de ce service, et non pas seulement un déploiement unique. La sécurité doit collaborer avec le développement et les opérations pour déterminer quel service est le plus adapté, non seulement en termes de ce qui est nécessaire pour l'exécuter et le maintenir, mais aussi de ce qui est logique pour l'entreprise. À titre d'exemple rapide, s'il existe des services liés à la sécurité, il serait logique que la sécurité s'approprie ce service.
Pour plus d'informations sur la façon de posséder un service, veuillez vous référer à notre Guide des opérations de propriété de service complet .
Pour le développement et les opérations, ils doivent effectuer des exercices qui améliorent leur sensibilisation et leur posture de sécurité globale. Une façon d'y parvenir est de participer aux exercices de modélisation des menaces lors de la phase de conception de diverses fonctionnalités et versions. La modélisation des menaces consiste à travailler ensemble pour déterminer les implications en matière de sécurité des logiciels, services ou environnements nouveaux ou modifiés. Par exemple, si une modification est apportée à la conception du réseau, cette nouvelle conception doit être modélisée en termes de menaces afin qu'elle puisse être correctement sécurisée.
Créer une culture de collaboration
Il est important de travailler avec l'esprit humain, et non contre lui. Nous sommes une espèce curieuse, et nous aimons être impliqués et interagir. Nous sommes également une espèce avec un fort biais de négativité. Examinons ce que le fait de réunir ces deux éléments peut signifier en termes d'apprentissage. En ce moment, pendant que vous lisez cette phrase de ce paragraphe, prenez un moment pour penser à certains des contenus les plus mémorables que vous ayez rencontrés, ou à une leçon particulièrement mémorable.
Qu'est-ce qui vous a marqué ? Était-ce une expérience positive ? Avez-vous pu appliquer ce que vous avez appris plus tard d'une manière qui vous a aidé ou qui a aidé les autres ? Était-ce simplement intéressant ? Ou peut-être s'agissait-il d'une critique. Lorsque vous pensez à cette critique, vous souvenez-vous plus précisément de ce qui a été communiqué ou de la manière dont cela a été communiqué ?
Maintenant que vous êtes prêt, je vais réitérer quelque chose que j'ai également inclus dans notre guide des opérations DevSecOps : ici, chez PagerDuty, nous avons pour politique de ne jamais tromper le personnel. Un exemple bien connu est celui des entreprises qui envoient des e-mails de phishing à leurs employés et exigent une formation en sécurité si les e-mails sont ouverts et/ou si l'on clique sur les liens qu'ils contiennent. L'objectif de cet exercice est généralement de démontrer que les véritables attaques de phishing peuvent être et seront à la fois bien conçues et nuisibles, mais si nous réfléchissons à la façon dont les humains apprennent, est-ce la leçon qui est enseignée ?
L’objectif principal de la sécurité, en termes de formation, est d’améliorer la sensibilisation générale du personnel aux différentes manières dont la sécurité peut être compromise. Un autre objectif est d’être présent pour remédier à tout incident qui se produit ; mais pour y parvenir, l’équipe doit gagner suffisamment de confiance pour que le personnel se sente suffisamment en sécurité psychologique pour signaler les incidents.
Pour adopter une approche différente, utilisez la formation à la sécurité comme une opportunité de créer et de maintenir l'intérêt et la confiance. Proposer une formation à la sécurité personnalisée vous permet de mobiliser votre équipe pour organiser le contenu autour des domaines dans lesquels votre organisation est plus faible et d'être plus général dans les domaines dans lesquels votre organisation est forte. Cela vous permet également de vraiment interagir avec le personnel, de faire quelque chose pour attirer son attention. Vous pouvez peut-être faire une démonstration d'une attaque de script intersite ou montrer comment crocheter une serrure, et lier cette dernière aux concepts que vous essayez de transmettre dans la formation.
Étant donné que la personnalisation complète de la formation à partir de zéro est une entreprise énorme, n'hésitez pas à utiliser les notres . Nos supports de formation sont open source sous licence Licence Apache , alors n'hésitez pas à l'utiliser et à le réutiliser pour l'adapter aux besoins de votre organisation.
Découvrez notre nouveau guide des opérations
Pour en savoir plus sur ce que j'ai écrit ici, veuillez consulter notre nouveau Guide DevSecOps ! Nos guides d'opérations sont continuellement mis à jour et ce guide ne fait pas exception. Donc, si vous souhaitez contribuer, n'hésitez pas à nous contacter ou à soumettre une demande d'extraction sur GitHub. Si vous souhaitez discuter de DevSecOps, n'hésitez pas à publier sur notre Forums communautaires ou contactez-moi directement sur Twitter , J'aimerais avoir de vos nouvelles !