Sécurité dans DevOps (DevSecOps)

La sécurité est une partie clé de DevOps. Mais comment une équipe sait-elle si un système est sécurisé ? Est-il vraiment possible de fournir un service complètement sécurisé ?

Malheureusement, la réponse n’est pas. DevSecOps est un effort continu et continu qui nécessite l’attention de tout le monde dans le développement et les opérations informatiques. Bien que le travail ne soit jamais vraiment effectué, les pratiques que les équipes utilisent pour prévenir et gérer les violations peuvent aider à produire des systèmes aussi sécurisés et résilients que possible.

Fondamentalement, si quelqu’un veut entrer, il y arrivera... il faut l'accepter. Ce que nous disons aux clients est : numéro un, vous êtes dans le combat, que vous le pensiez ou non. Deuxièmement, il est presque certain que vous avez été infiltré." -- Michael Hayden, ancien directeur de la NSA et de la CIA

Conversation de sécurité

Les équipes qui n’ont pas de stratégie DevSecOps formelle sont encouragées à commencer la planification dès que possible. Au début, il peut y avoir une résistance des membres de l’équipe qui n’apprécient pas pleinement les menaces qui existent. D’autres n’ont peut-être pas l’impression que l’équipe est équipée pour faire face au problème et que tout investissement spécial serait une distraction inutile des fonctionnalités d’expédition. Toutefois, il est nécessaire de commencer la conversation pour générer un consensus quant à la nature des risques, à la façon dont l’équipe peut les atténuer et si l’équipe a besoin de ressources qu’elle n’a pas actuellement.

Attendez-vous que les sceptiques apportent quelques arguments courants, tels que :

• Quelle est la réalité de la menace ? Les équipes n’apprécient souvent pas la valeur potentielle des services et des données dont ils ont la charge de protéger.
• Notre équipe est bonne, non ? Une discussion sur la sécurité peut être perçue comme un doute dans la capacité de l’équipe à créer un système sécurisé.
• Je ne pense pas que c’est possible. C’est un argument commun des ingénieurs juniors. Ceux qui ont de l’expérience connaissent généralement mieux.
• Nous n’avons jamais été violés. Mais comment savez-vous ? Comment savez-vous ?
• Débats sans fin sur la valeur. DevSecOps est un engagement sérieux qui peut être perçu comme une distraction du travail principal des fonctionnalités. Bien que l’investissement de sécurité soit équilibré avec d’autres besoins, il ne peut pas être ignoré.

Le changement d’état d’esprit

La culture DevSecOps nécessite un changement important d’esprit. Non seulement avez-vous besoin d’empêcher les violations, mais de les supposer également.

Composants de stratégie de sécurité

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

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

Toutefois, de nombreuses équipes n’ont pas de stratégie qui suppose que les violations du système sont inévitables. En supposant que vous avez été compromis, cela peut être difficile à admettre, en particulier lorsque vous avez des conversations difficiles avec la direction, mais cette hypothèse peut vous aider à répondre à des questions de sécurité à votre convenance. Vous ne voulez pas tout comprendre lors d’une véritable urgence de sécurité.

Les questions courantes à prendre en compte sont les suivantes :

• Comment détecterez-vous une attaque ?
• Comment réagirez-vous en cas d’attaque ou de pénétration ?
• Comment récupérerez-vous d’une attaque, par exemple quand des données ont été divulguées ou falsifiées ?

Principales pratiques DevSecOps

Il existe plusieurs pratiques DevSecOps courantes qui s’appliquent à pratiquement n’importe quelle équipe.

Tout d’abord, concentrez-vous sur l’amélioration du temps moyen de détection et du temps moyen de récupération. Ces métriques indiquent le temps nécessaire pour détecter une violation et le temps nécessaire à la récupération, respectivement. Ils peuvent être suivis par le biais de tests continus de site en direct des plans de réponse de sécurité. Lors de l’évaluation des stratégies potentielles, l’amélioration de ces métriques doit être une considération importante.

Pratiquez la défense en profondeur. Lorsqu’une violation se produit, les attaquants peuvent accéder aux réseaux internes et à tout ce qui les entoure. Bien qu’il soit idéal d’arrêter les attaquants avant qu’il ne soit aussi loin, une stratégie d’hypothèse de violations conduit les équipes à réduire l’exposition d’un attaquant qui est déjà entré.

Enfin, effectuez des évaluations post-violation périodiques de vos pratiques et environnements. Une fois qu’une violation a été résolue, votre équipe doit évaluer les performances des stratégies, ainsi que leur propre adhésion. Les stratégies sont les plus efficaces lorsque les équipes les suivent réellement. Chaque violation, qu’elle soit réelle ou pratiquée, devrait être considérée comme une occasion d’améliorer.

Stratégies d’atténuation des menaces

Il y a trop de menaces pour les énumérer. 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 conservation up-to-date est essentielle. D’autres sont dus à des bogues dans le code système qui nécessitent une analyse minutieuse pour rechercher et corriger. La mauvaise gestion des secrets est la cause de nombreuses violations, comme c’est l’ingénierie sociale. Il est recommandé de réfléchir aux différents types de trous de sécurité et à ce qu’ils signifient pour le système.

Vecteurs d’attaque

Envisagez un scénario dans lequel un attaquant a obtenu l’accès aux informations d’identification d’un développeur. Qu’est-ce qu’ils peuvent faire ?

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

• Stocker des secrets dans des coffres protégés
• Supprimer des comptes d’administrateur local
• Restreindre SAMR
• Protection des informations d’identification
• Supprimer des serveurs à double connexion réseau
• Abonnements distincts
• Authentification multifacteur
• Stations de travail d’accès privilégié
• Détecter avec ATP & Microsoft Defender pour cloud

Gestion des secrets

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

• Mots de passe, clés et jetons
• Clés de compte de stockage
• Certificats
• Informations d’identification utilisées dans des environnements hors production partagés, également

Vous devez utiliser une hiérarchie de coffres-forts pour éviter la redondance des secrets. Réfléchissez également à la façon et au moment où les secrets sont accessibles. Certains sont utilisés au moment du déploiement lors de la création de configurations d’environnement, tandis que d’autres sont accessibles au moment de l’exécution. Les secrets au moment du déploiement nécessitent généralement un nouveau déploiement pour récupérer de nouveaux paramètres, tandis que les secrets au moment de l’exécution sont accessibles lorsque nécessaire et peuvent être mis à jour à tout moment.

Les plateformes disposent de fonctionnalités de stockage sécurisées pour gérer les secrets dans les pipelines CI/CD et les environnements cloud, tels qu’Azure Key Vault et GitHub Actions.

Outils utiles

• Microsoft Defender pour Cloud est idéal pour les alertes d’infrastructure générique, telles que les programmes malveillants, les processus suspects, etc.
• Outils d’analyse du code source pour les tests de sécurité des applications statiques (SAST).
• Sécurité avancée gitHub pour l’analyse et la surveillance des dépôts.
• mimikatz extrait les mots de passe, les clés, les codes PIN, les tickets, etc. à partir de la mémoire du service sous-système d'Autorité de sécurité locale sur Windows. Il nécessite uniquement l’accès administratif à l’ordinateur ou un compte avec le privilège de débogage activé.
• BloodHound crée un graphique des relations dans un environnement Active Directory. Il peut être utilisé par l’équipe rouge pour identifier facilement les vecteurs d’attaque difficiles à identifier rapidement.

Exercices de jeu de guerre

Une pratique courante chez Microsoft est de s’engager dans des exercices de jeu 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 stratégies d’un système.

L’équipe rouge prend le rôle d’un attaquant. Ils tentent de modéliser des attaques réelles afin de trouver des lacunes dans la sécurité. S’ils peuvent les exploiter, ils démontrent également l’impact potentiel de leurs violations.

L’équipe bleue prend le rôle de l’équipe DevOps. Ils testent leur capacité à détecter et à répondre aux attaques de l’équipe rouge. Cela permet d’améliorer la sensibilisation à la situation et de mesurer la préparation et l’efficacité de la stratégie DevSecOps.

Faire évoluer une stratégie de jeux de guerre

Les jeux de guerre sont efficaces pour renforcer la sécurité parce qu’ils motivent l’équipe rouge à trouver et exploiter des problèmes. Il sera probablement beaucoup plus facile que prévu tôt. Les équipes qui n’ont pas activement essayé d’attaquer leurs propres systèmes ignorent généralement la taille et la quantité de trous de sécurité disponibles pour les attaquants. L'équipe bleue risque d'être démoralisée au début car elle sera dépassée à plusieurs reprises. Heureusement, le système et les pratiques doivent évoluer au fil du temps afin que l’équipe bleue gagne constamment.

Préparer les jeux de guerre

Avant de commencer des jeux de guerre, l’équipe doit prendre en charge tous les problèmes qu’elle peut trouver par le biais d’une passe de sécurité. Il s’agit d’un excellent exercice à effectuer avant de tenter une attaque, car il fournira une expérience de base à tous les utilisateurs à comparer après la première attaque. Commencez par identifier les vulnérabilités par le biais d’une révision manuelle du code et d’outils d’analyse statique.

Organiser les équipes

Les équipes rouges et bleues doivent être organisées par spécialité. L’objectif est de créer les équipes les plus capables pour chaque côté afin de s’exécuter aussi efficacement que possible.

L’équipe rouge doit inclure certains ingénieurs et développeurs de sécurité profondément familiarisés avec le code. Il est également utile d’augmenter l’équipe avec un spécialiste des tests de pénétration, si possible. S’il n’y a pas de spécialistes en interne, de nombreuses entreprises fournissent ce service avec le mentorat.

L'équipe bleue doit être composée d'ingénieurs spécialisés dans les opérations qui ont une compréhension approfondie des systèmes disponibles et des fonctionnalités de journalisation. Ils ont la meilleure chance de détecter et de traiter le comportement suspect.

Exécuter des jeux de guerre précoces

Attendez-vous que l’équipe rouge soit efficace dans les premiers jeux de guerre. Ils doivent être en mesure de réussir grâce à des attaques assez simples, telles que la recherche de secrets mal protégés, l’injection SQL et les campagnes d’hameçonnage réussies. Prenez beaucoup de temps entre les cycles pour appliquer des correctifs et des commentaires sur les stratégies. Cela peut varier selon les organisations, mais vous ne souhaitez pas commencer le prochain tour tant que tout le monde n’est pas sûr que le tour précédent a été exploité jusqu'à son maximum.

Jeux de guerre en cours

Après quelques rondes, l’équipe rouge devra s’appuyer sur des techniques plus sophistiquées, telles que l’écriture de scripts intersites (XSS), les attaques de désérialisation et les vulnérabilités du système d’ingénierie. L’intégration d’experts de sécurité externes dans des domaines comme Active Directory peut être utile afin d’attaquer des exploits plus obscurs. À ce stade, l’équipe bleue devrait non seulement avoir une plateforme renforcée à défendre, mais également utiliser la journalisation centralisée complète pour les enquêtes judiciaires après violation.

Les défenseurs pensent en termes de listes. Les attaquants pensent en graphiques. Tant que cela est vrai, les attaquants gagnent." -- John Lambert (MSTIC)

Au fil du temps, l’équipe rouge prendra beaucoup plus de temps pour atteindre les objectifs. Lorsqu'ils le font, il faudra souvent découvrir et enchaîner plusieurs vulnérabilités, ce qui ne produira qu'un impact limité. Grâce à l’utilisation d’outils de surveillance en temps réel, l’équipe bleue doit commencer à intercepter les tentatives en temps réel.

Guidelines

Les jeux de guerre ne devraient pas être gratuits. Il est important de reconnaître que l’objectif est de produire un système plus efficace exécuté 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 feront aucun mal. Si le risque de causer des dommages est important, il doit être documenté et traité.
2. L’équipe rouge ne doit pas compromettre plus que nécessaire pour capturer les ressources cibles.
3. Les règles de bon sens s’appliquent aux attaques physiques. Bien que l’équipe rouge soit encouragée à être créative avec des attaques non techniques, comme l’ingénierie sociale, ils ne devraient 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 qui a été compromise. La leçon peut être partagée sans aliénér ou embarrasser un membre de l’équipe dont tout le monde a besoin pour continuer à travailler.

Règles d’engagement

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

1. N’impactez pas la disponibilité d’un système.
2. N’accédez pas aux données client externes.
3. N’affaiblissez pas considérablement les protections de sécurité sur n’importe quel service.
4. N’effectuez pas intentionnellement d’actions destructrices sur des ressources.
5. Protégez les informations d’identification, les vulnérabilités et d’autres informations critiques obtenues.

Livrables

Tous les risques de sécurité ou leçons apprises doivent être documentés dans un backlog d’éléments de réparation. Teams doit définir un contrat de niveau de service (SLA) pour déterminer la rapidité avec laquelle les risques de sécurité seront résolus. Les risques sévères doivent être résolus dès que possible, tandis que des problèmes mineurs peuvent avoir une échéance de deux sprints.

Un rapport doit être présenté à l’ensemble de l’organisation avec les leçons apprises et les vulnérabilités trouvées. C’est une opportunité d’apprentissage pour tout le monde.

Leçons apprises chez Microsoft

Microsoft pratique régulièrement des jeux de guerre et a appris beaucoup de leçons le long de la route.

• Les jeux de guerre constituent un moyen efficace de changer la culture DevSecOps et de garder la sécurité à l’esprit.
• Les attaques par hameçonnage 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 en production et en nécessitant une authentification à deux facteurs.
• Le contrôle du système d’ingénierie conduit au contrôle de tout. Veillez à contrôler strictement l’accès à l’agent de build/release, à la file d’attente, au pool et à la définition.
• Pratiquez la défense en profondeur pour rendre plus difficile pour les attaquants. Chaque limite qu’ils doivent violer les ralentit et offre une autre occasion de les intercepter.
• Ne traversez jamais les sphères de confiance. La production ne doit jamais faire confiance à ce qui est en test.

Étapes suivantes

En savoir plus sur le cycle de vie du développement de la sécurité et DevSecOps sur Azure.