Un élément que vous devriez probablement inclure lors de la création de vos prochains modèles de menaces

Nous travaillons actuellement sur nos modèles de menaces chez DisruptOps, j'ai donc décidé d'actualiser mes connaissances sur les différentes approches. Un point m'a rapidement frappé : presque aucun des outils ni des documents de modélisation des menaces que j'ai consultés ne couvre le pipeline CI/CD.

C'est. Un. Problème. Intégrez votre pipeline à vos modèles de menaces.

Ces dernières années, j'ai réalisé directement quelques dizaines d'évaluations de sécurité cloud, en plus de diverses missions de conseil. J'inclus systématiquement les pipelines de développement et de déploiement dans le périmètre, et c'est souvent là que je constate les problèmes de sécurité les plus importants. Votre environnement cloud ultra-sécurisé n'est qu'un château de cartes si quelqu'un peut modifier l'infrastructure fondamentale en changeant un modèle quelque part ou en compromettant des clés stockées.

La plupart des modèles de menaces commencent par un diagramme de flux de données ou une architecture, qui permet de parcourir votre application pour en modéliser les menaces (pour ma part, j'apprécie STRIDE, issu de Microsoft). Cela couvre les fonctionnalités de l'application, mais pas le pipeline.

Lorsque vous appliquez votre modèle de menaces *du jour* à votre pipeline, traitez vos développeurs et administrateurs comme des utilisateurs, et traitez également le pipeline lui-même comme un utilisateur s'il stocke des identifiants (en tenant compte de la façon dont il se connecte à votre environnement).

Par exemple, quelqu'un peut-il usurper un appel d'API vers Jenkins pour déclencher une modification de votre application en production ? (Probablement, compte tenu de la façon dont Jenkins est souvent configuré.) Et la répudiation des modifications de tâches par rapport aux modifications de code ? L'élévation de privilèges dans le pipeline ?

Les pipelines résistent rarement bien à un examen de sécurité approfondi ; nous les aborderons donc dans de prochains articles consacrés aux fondamentaux de la sécurité. Vous ne serez sans doute pas surpris d'apprendre que je recommande généralement des garde-fous à la fois sur les déploiements du pipeline et sur toute infrastructure connectée, afin de réduire le risque. Par exemple, votre serveur CI ne devrait jamais être exposé, ni exposable, publiquement. Vous pouvez recourir à des garde-fous complémentaires pour garantir qu'il se trouve sur un segment réseau dépourvu de passerelle Internet et que vos groupes de sécurité n'autorisent pas l'accès public (mieux encore, assurez-vous également que les serveurs CI se trouvent toujours derrière des équilibreurs de charge élastiques).

L'époque où la surface d'attaque d'une application se limitait à ses composants est révolue depuis longtemps. Dans le cloud, la plupart de nos applications sont alimentées par des pipelines, qui risquent fortement de constituer un point faible, en raison de leurs accès étendus et des identifiants qu'ils stockent.