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 vous concentrez spécifiquement sur le lancement 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 collaborent très rapidement et efficacement, ils confient ces fonctionnalités à la sécurité. Et la sécurité les confie à son tour, un peu comme le faisaient le développement et les opérations avant DevOps.

DevSecOps apporte au développement, aux opérations et à la sécurité ce que DevOps a apporté au développement et aux opérations : c'est une pratique culturelle, soutenue par la technologie, qui rationalise le travail de ces équipes afin qu'elles puissent collaborer. À l'instar de DevOps, la transformation culturelle DevSecOps consiste notamment à développer l'empathie mutuelle en comprenant les besoins spécifiques 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 (sauf si vous souhaitez apprendre à réaliser vos propres tests d'intrusion, entre autres, sans leur aide ni leurs conseils – ce que je déconseille). De la même manière, DevOps n'a pas supprimé la nécessité des opérations ; il a transformé la collaboration entre les équipes d'exploitation et de développement.

Le DevSecOps diffère légèrement du DevOps quant à son fonctionnement. Pour rappel, le modèle DevOps se présente ainsi :

Dans le workflow ci-dessus, vous pouvez constater que le développement et les opérations restent séparés, mais ne sont plus cloisonnés. Le modèle DevSecOps se présente ainsi :

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, on procède par « shifting left » (c'est-à-dire en intégrant la sécurité de plus en plus tôt dans le cycle, dès la phase de conception/construction). Différents tests et autres activités doivent être réalisés à chaque étape. Par exemple, lors de la phase de code, la sécurité devra participer aux revues de code et effectuer des tests tels que des tests statiques de sécurité des applications (SAST) et/ou des analyses de composition logicielle (SCA). Identifier les problèmes à ce stade signifie les corriger 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 sa correction est coûteuse en temps et en expertise.

Établir une empathie interfonctionnelle

De nombreux spécialistes de la sécurité manquent d'expérience en exploitation de services en production. De même, de nombreux développeurs et spécialistes des opérations manquent d'expérience en sécurité. Pour combler ces lacunes, il est important de se mettre à la place des autres.

Pour la sécurité, cela signifie être propriétaire d'un service en production. Il est important que l'équipe prenne en charge l'intégralité du cycle de vie de ce service ; il ne s'agit pas d'un simple déploiement. La sécurité doit collaborer avec les équipes de développement et d'exploitation pour déterminer le service le plus adapté, non seulement en fonction des besoins d'exploitation et de maintenance, mais aussi de la pertinence pour l'entreprise. Par exemple, s'il existe des services liés à la sécurité, il serait logique que la sécurité en prenne la responsabilité.

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 l'exploitation, ils doivent réaliser des exercices visant à améliorer leur sensibilisation et leur posture globales en matière de sécurité. Une façon d'y parvenir est de participer aux exercices de modélisation des menaces dès la phase de conception des différentes fonctionnalités et versions. La modélisation des menaces consiste à collaborer 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 d'ê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, aimant l'interaction et le dialogue. Nous sommes aussi une espèce fortement influencée par la négativité. Réfléchissons à ce que la combinaison de ces éléments peut apporter en termes d'apprentissage. En lisant cette phrase de ce paragraphe, prenez un moment pour penser à un contenu mémorable que vous avez lu, ou à une leçon particulièrement mémorable.

Qu'avez-vous retenu de cette expérience ? É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 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 il l'a été ?

Maintenant que vous êtes fin prêts, je vais réitérer un point que j'ai également inclus dans notre guide DevSecOps : chez PagerDuty, nous avons pour politique de ne jamais piéger nos employés. 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 ces 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 dangereuses. Mais si l'on considère la façon dont les humains apprennent, est-ce la leçon enseignée ?

L'objectif principal de la sécurité, en termes de formation, est de sensibiliser le personnel aux failles de sécurité potentielles. Un autre objectif est d'être présent pour remédier aux incidents qui surviennent ; pour cela, 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 susciter et de maintenir l'intérêt et la confiance. Proposer une formation personnalisée à la sécurité vous permet de motiver votre équipe à adapter le contenu aux points faibles de votre organisation et d'être plus général sur ses points forts. Cela vous permet également de véritablement interagir avec vos employés : faites quelque chose pour capter leur attention. Vous pouvez par exemple faire une démonstration d'une attaque par script intersite ou montrer comment crocheter une serrure, et intégrer ces derniers aux concepts que vous souhaitez transmettre lors de 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 la nôtre 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.

Consultez 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 Ops sont constamment mis à jour, et celui-ci ne fait pas exception. Si vous souhaitez contribuer, n'hésitez pas à nous contacter ou à soumettre une demande d'extraction sur GitHub. Pour discuter de DevSecOps, n'hésitez pas à publier sur notre site. Forums communautaires ou contactez-moi directement au Gazouillement , J'aimerais avoir de vos nouvelles !