Sécurité dans DevOps (DevSecOps)

La sécurité est un élément clé de DevOps. Mais comment une équipe peut-elle savoir si un système est bien sécurisé ? Est-il vraiment possible de fournir un service entièrement sécurisé ?

Malheureusement, la réponse est non. DevSecOps est un effort continu qui requiert l’attention de chacun, à la fois dans le développement et les opérations informatiques. Bien que le travail ne soit jamais vraiment terminé, les pratiques que les équipes emploient pour prévenir et gérer les violations peuvent contribuer à produire des systèmes aussi sécurisés et résilients que possible.

« Fondamentalement, si quelqu’un veut entrer, il y parviendra... acceptez-le. Ce que nous disons aux clients, c’est : premièrement, vous êtes dans la bataille, que vous le vouliez ou non. Deuxièmement, vous avez presque certainement été infiltré ». -- Michael Hayden, ex directeur de la NSA et de la CIA

La conversation sur la sécurité

Les équipes n’ayant pas encore mis en place une stratégie DevSecOps formelle sont encouragées à commencer à planifier dès que possible. Au début, il peut y avoir de la résistance de la part des membres de l’équipe qui ne mesurent pas pleinement les menaces existantes. D’autres peuvent ne pas penser que l’équipe est équipée pour faire face au problème et que tout investissement spécial serait une distraction superflue des fonctionnalités de livraison. D’autres peuvent estimer que l’équipe n’est pas parée pour faire face au problème et que tout investissement spécifique serait une distraction inutile par rapport à la livraison de fonctionnalités.

Attendez-vous à ce que les sceptiques apportent quelques arguments communs comme :

• La menace est-elle vraiment réelle ? Souvent, les équipes ne voient pas la valeur potentielle des services et des données qu’elles sont chargées de protéger.
• Notre équipe est bonne, non ? Une discussion sur la sécurité peut être perçue comme une remise en question de la capacité de l’équipe à construire un système sécurisé.
• Je ne pense pas que ce soit possible. Il s’agit d’un argument commun des ingénieurs juniors. Ceux qui ont de l’expérience savent généralement mieux.
• Nous n’avons jamais connu de violation de la sécurité. Mais comment le savez-vous ? Comment pourriez-vous le savoir ?
• Débats sans fin sur la valeur. DevSecOps est un engagement sérieux qui peut être perçu comme quelque chose qui détourne du travail de fonctionnalité pur. L’investissement dans la sécurité doit certes être équilibré avec d’autres besoins, mais il ne peut pas être ignoré.

Le changement de mentalité

La culture DevSecOps nécessite un changement de mentalité important. Vous devez non seulement prévenir les failles, mais aussi assumer leur existence.

Composants de stratégie de sécurité

Il existe de nombreuses techniques qui peuvent être appliquées dans la quête de systèmes plus sécurisés.

Prévention des violations	Violations supposées
Modèles de menace	Exercices de jeu de guerre
Examens du code	Moniteurs de sécurité centraux
Tests de sécurité	Tests d’intrusion de site en direct
Security Development Lifecycle (SDL)

Chaque équipe devrait déjà avoir adopté au moins quelques pratiques pour prévenir les failles. L’écriture de code sécurisé est devenue plus qu’une valeur par défaut, et il existe de nombreux outils commerciaux gratuits pour faciliter l’analyse statique et d’autres fonctionnalités de test de sécurité.

Cependant, de nombreuses équipes ne disposent pas d’une stratégie prenant en compte le caractère inévitable des failles du système. Admettre que vous avez été infiltré peut être difficile, notamment lors de conversations compliquées avec la direction, mais cette hypothèse peut vous aider à répondre aux questions relatives à la sécurité à votre propre rythme. Il vaut mieux ne pas tout découvrir lors d’une véritable urgence de sécurité.

Voici quelques questions courantes auxquelles réfléchir :

• Comment détecterez-vous une attaque ?
• Comment réagirez-vous en cas d’attaque ou de pénétration ?
• Comment réagirez-vous en cas d’attaque ? Par exemple, quand des données ont-elles fuité ou ont-elles été altérées ?

Pratiques clés de DevSecOps

Il existe plusieurs pratiques courantes de DevSecOps qui s’appliquent à presque toutes les équipes.

Tout d’abord, concentrez-vous sur l’amélioration du temps moyen de détection (mean time to detection, MTTD) et du temps moyen de récupération (mean time to recovery, MTTR). Ces mesures indiquent respectivement le temps nécessaire pour détecter une violation et le temps nécessaire pour la récupération. Elles peuvent être suivies grâce à des tests en direct continus des plans de réponse à la sécurité. Lors de l’évaluation de politiques potentiellement applicables, l’amélioration de ces mesures devrait être une considération importante.

Pratiquez la défense en profondeur. Lorsqu’une violation se produit, les agresseurs peuvent accéder aux réseaux internes et à tout ce qu’ils contiennent. Bien qu’il soit idéal d’arrêter les agresseurs avant qu’ils n’atteignent ce stade, une politique qui considère les violations comme inévitables pousse les équipes à minimiser l’exposition à un agresseur qui s’est déjà infiltré.

Enfin, effectuez des évaluations périodiques après une violation de vos pratiques et de vos environnements. Après résolution d’une violation, votre équipe doit évaluer les performances des politiques, ainsi que leur propre conformité à celles-ci. Les politiques sont plus efficaces lorsque les équipes les suivent effectivement. Chaque violation, qu’elle soit réelle ou simulée, doit être considérée comme une opportunité d’amélioration.

Stratégies d’atténuation des menaces

Il existe trop de menaces pour toutes les citer. Certaines failles de sécurité sont dues à des problèmes liés aux dépendances, telles que les systèmes d’exploitation et les bibliothèques, de sorte que leur maintien à jour est essentiel. D’autres sont dues à des bogues dans le code système qui nécessitent la recherche et la correction d’une analyse minutieuse. La mauvaise gestion des secrets est la cause de nombreuses violations, comme l’ingénierie sociale. Il est bon de réfléchir aux différents types de failles de sécurité et à leur signification pour le système.

Vecteurs d’attaque

Considérez un scénario où un agresseur a obtenu l’accès aux identifiants d’un développeur. Que peut-il faire ?

Privilège	Trafic
Peut-il envoyer des e-mails ?	Hameçonner des collègues
Peut-il accéder à d’autres machines ?	Se connecter, attaques Mimikatz, recommencer
Peut-il modifier la source ?	Injecter du code
Peut-il modifier le processus de génération/mise en production ?	Injecter du code, exécuter des scripts
Peut-il accéder à un environnement de test ?	Si un environnement de production dépend de l’environnement de test, exploiter-cela
Peut-il accéder à l’environnement de production ?	Tant de possibilités...

Comment votre équipe peut-elle se défendre contre ces vecteurs ?

• Stockage des secrets dans des coffres protégés
• Suppression des comptes administrateurs locaux
• Restreindre SAMR
• Credential Guard
• Suppression des serveurs à double résidence
• Séparer les abonnements
• Authentification multifacteur
• Stations de travail à accès privilégié
• Détection avec ATP & Microsoft Defender for Cloud

Gestion des secrets

Tous les secrets doivent être stockés dans un coffre protégé. Les secrets comprennent :

• Mots de passe, clés et tokens
• Clés de compte de stockage
• Certificats
• Identifiants utilisés dans les environnements de non-production partagés.

Vous devez utiliser une hiérarchie de coffres pour éliminer la duplication des secrets. Pensez également à la manière et au moment où les secrets sont accédés. Certains sont utilisés lors du déploiement lors de la construction des configurations d’environnement, tandis que d’autres sont accessibles en temps réel. Les secrets de déploiement nécessitent généralement un nouveau déploiement pour prendre en compte de nouveaux paramètres, tandis que les secrets en temps réel sont accessibles au besoin et peuvent être mis à jour à tout moment.

Les plates-formes disposent de fonctionnalités de stockage sécurisé pour la gestion des secrets dans les pipelines CI/CD et les environnements cloud, comme Azure Key Vault et GitHub Actions.

Outils utiles

• Microsoft Defender for Cloud est idéal pour les alertes d’infrastructure générique, comme les programmes malveillants, les processus suspects, etc.
• Les Outils d’analyse du code source pour les tests de sécurité des applications statiques (SAST).
• GitHub advanced security pour l’analyse et la surveillance des référentiels.
• mimikatz extrait les mots de passe, les clés, les codes PIN, les tickets et bien plus encore de la mémoire de lsass.exe, le service sous-système de sécurité local de Windows. Il nécessite uniquement un accès administratif à la machine, ou un compte avec le privilège de débogage activé.
• BloodHound construit un graphique des relations au sein d’un environnement Active Directory. Il peut être utilisé par l’équipe rouge (d’attaque) pour identifier facilement les vecteurs d’attaque qui sont normalement difficiles à identifier rapidement.

Exercices de jeu de guerre

Une pratique courante chez Microsoft est de participer à des exercices de simulation de guerre. Il s’agit d’événements de test de sécurité où deux équipes sont chargées de tester la sécurité et les politiques d’un système.

L’équipe rouge joue le rôle d’un agresseur. Elle tente de modéliser des attaques du monde réel afin de trouver des failles en matière de sécurité. Si elle peut en exploiter, elle démontre également l’impact potentiel de ses violations.

L’équipe bleue joue le rôle de l’équipe DevOps. Elle teste sa capacité à détecter et à répondre aux attaques de l’équipe rouge. Cela aide à renforcer la connaissance de la situation, à mesurer la préparation et l’efficacité de la stratégie DevSecOps.

Évolution d’une stratégie de simulation de guerre

Les jeux de guerre sont efficaces pour renforcer la sécurité car ils encouragent l’équipe rouge à trouver et à exploiter des problèmes. Ce sera probablement beaucoup plus facile que prévu au début. Les équipes qui n’ont pas activement cherché à attaquer leurs propres systèmes sont généralement inconscientes de la gravité et de la quantité de failles de sécurité disponibles pour les agresseurs. L’équipe bleue peut être démoralisée au début car souvent dépassée. Heureusement, le système et les pratiques devraient évoluer avec le temps de telle sorte que l’équipe bleue l’emporte régulièrement.

Préparation aux jeux de guerre

Avant de commencer les jeux de guerre, l’équipe devrait résoudre tous les problèmes qu’elle peut trouver lors d’une vérification de sécurité. Il s’agit d’un excellent exercice avant de tenter une attaque car il fournira une expérience de référence pour tous afin de comparer après la première exploitation qui se produira plus tard. Commencez par identifier les vulnérabilités grâce à un examen manuel du code et à des outils d’analyse statique.

Organiser les équipes

Les équipes rouges et bleues doivent s’organiser par spécialité. L’objectif est de constituer les équipes les plus compétentes de chaque côté afin d’être aussi efficace que possible.

L’équipe rouge devrait compter des ingénieurs et des développeurs axés sur la sécurité, très familiers avec le code. Il est également utile de renforcer l’équipe avec un spécialiste en tests de pénétration, si possible. S’il n’y a pas de spécialistes en interne, de nombreuses entreprises proposent ce service ainsi que du mentorat.

L’équipe bleue doit être composée d’ingénieurs axés sur les opérations, ayant une compréhension approfondie des systèmes et des journaux disponibles. Ils ont de meilleures chances de détecter et de répondre aux comportements suspects.

Déroulement des premiers jeux de guerre

Attendez-vous à ce que l’équipe rouge soit efficace dès les premiers jeux de guerre. Elle devrait réussir grâce à des attaques relativement simples, telles que la découverte de secrets mal protégés, l’injection SQL et des campagnes de phishing réussies. Prenez suffisamment de temps entre les sessions pour apporter des correctifs et collecter du feedback sur les politiques. Cela variera d’une organisation à l’autre, mais il n’est pas bon de lancer la session suivante tant que tout le monde n’est pas convaincu qu’on a tiré le maximum de la session précédente.

Jeux de guerre suivants

Après quelques sessions, l’équipe rouge devra utiliser des techniques plus sophistiquées, telles que les attaques par injection de code côté client (XSS), des exploits de désérialisation et les vulnérabilités du système d’ingénierie. Faire appel à des experts en sécurité externes dans des domaines tels que Active Directory peut être utile pour attaquer des exploits plus obscurs. À ce stade, l’équipe bleue devrait non seulement disposer d’une plate-forme à la défense renforcée, mais également d’une journalisation centralisée complète pour les investigations après violation.

« Les défenseurs pensent en listes. Les attaquants pensent en graphiques. les attaquants gagnent tant que cela reste vrai » -- John Lambert (MSTIC)

Avec le temps, l’équipe rouge mettra beaucoup plus de temps à atteindre ses objectifs. Lorsqu’ils les atteindront, il aura souvent fallu détecter et associer plusieurs vulnérabilités pour obtenir un impact limité. Grâce à l’utilisation d’outils de surveillance en temps réel, l’équipe bleue devrait commencer à détecter les tentatives en temps réel.

Consignes

Les jeux de guerre ne doivent pas devenir une foire d’empoigne. Il est important de reconnaître que l’objectif est de produire un système plus efficace géré par une équipe plus efficace.

Code de conduite

Voici un exemple de code de conduite utilisé par Microsoft :

1. Les équipes rouges et bleues ne chercheront pas à faire du mal. Si les dommages potentiel sont significatifs, cela doit être documenté et traité.
2. L’équipe rouge ne prendra pas plus de risques que nécessaire pour capturer les actifs cibles.
3. Les règles de bon sens s’appliquent aux attaques physiques. Bien que l’équipe rouge soit encouragée à faire preuve de créativité avec des attaques non techniques, comme l’ingénierie sociale, elle ne doit pas imprimer de faux badges, harceler les gens, etc.
4. Si une attaque d’ingénierie sociale réussit, ne divulguez pas le nom de la personne compromise. La leçon peut être partagée sans aliéner ou embarrasser un membre de l’équipe avec lequel tout le monde doit continuer à travailler.

Règles d’engagement

Voici des règles d’engagement types utilisées par Microsoft :

1. Ne pas affecter la disponibilité d’un système.
2. Ne pas accéder aux données externes des clients.
3. Ne pas affaiblir de manière significative les protections de sécurité en place sur un service.
4. Ne pas effectuer intentionnellement des actions destructrices contre quelque ressource que ce soit.
5. Protéger les informations sensibles obtenues, telles que les identifiants, les vulnérabilités et autres informations critiques.

Livrables

Tous les risques liés à la sécurité ou les enseignements tirés doivent être documentés dans un backlog de correctifs. Les équipes doivent définir un accord de niveau de service (SLA) pour la rapidité avec laquelle les risques liés à la sécurité seront traités. Les risques graves doivent être traités dès que possible, tandis que les problèmes mineurs peuvent tolérer un délai de deux sprints.

Un rapport doit être présenté à toute l’organisation avec les enseignements tirés et les vulnérabilités découvertes. Il s’agit d’une opportunité d’apprentissage pour tous, alors profitez-en au maximum.

Leçons apprises chez Microsoft

Microsoft pratique régulièrement les jeux de guerre ce qui leur a permis de tirer beaucoup de leçons au fur et à mesure.

• Les jeux de guerre sont un moyen efficace de changer la culture DevSecOps et de maintenir la sécurité en haut de la liste des priorités.
• Les attaques de phishing sont très efficaces pour les attaquants et ne doivent pas être sous-estimées. L’impact peut être contenu en limitant l’accès à la production et en exigeant une authentification à deux facteurs.
• Le contrôle du système d’ingénierie conduit au contrôle de tout. Assurez-vous de mettre en place des mesures strictes pour réglementer l’accès aux agents de construction/de publication, aux files d’attente, aux ensembles de ressources et aux définitions, et surveillez attentivement qui peut y accéder.
• Pratiquez la défense en profondeur pour compliquer la tâche des attaquants. Chaque frontière qu’ils doivent franchir les ralentit et offre une autre opportunité de les coincer.
• Maintenez une frontière solide entre les domaines de confiance. La production ne doit jamais approuver quoi que ce soit en test.

Étapes suivantes

En savoir plus sur le cycle de développement sécurisé et DevSecOps sur Azure.