Partager via

Contrôles DevSecOps

  • Article

Cet article explique comment appliquer des contrôles de sécurité pour prendre en charge les pratiques de sécurité de SDL continue. Ces contrôles de sécurité font partie intégrante d’une stratégie DevSecOps qui couvre les personnes, les processus et la technologie. Cette documentation décrit chaque contrôle et montre comment appliquer ces contrôles à trois profils de sécurité. Ces profils répondent aux exigences de sécurité classiques pour les scénarios métier courants de la plupart des organisations :

Diagramme des contrôles de sécurité par rapport au temps et à l’impact.

Profils de contrôle de sécurité

Il existe trois niveaux de profils de contrôle référencés dans cet article.

Minimum temporaire – profil de sécurité abrégé pour unétat d’exception temporaire pour prendre en charge le prototypage rapide des charges de travail à faible risque. Ce profil doit être utilisé uniquement pour les exceptions temporaires qui doivent être publiées sur une chronologie accélérée pour répondre aux besoins critiques de l’entreprise. Les éléments utilisant ce profil doivent rapidement être présentés au profil standard.

Standard - Approche équilibrée pour la plupart des charges de travail, la plupart du temps.

Sécurité élevée – Sécurité rigoureuse pour les charges de travail ayant un impact potentiel élevé sur la sécurité des entreprises et des personnes.

Contrôles de sécurité DevSecOps

Cette section fournit une référence aux contrôles de sécurité recommandés pour chaque type de charge de travail. Cette référence peut être adoptée « en l’état », ou elle peut être adaptée à vos processus de développement de logiciels et de sécurité logicielle existants. La plupart des organisations ne peuvent pas implémenter tous ces contrôles immédiatement s’ils ne le font pas déjà. L’approche d’amélioration continue est souvent la meilleure approche : classer par ordre de priorité les contrôles, implémenter le premier contrôle, passer au contrôle suivant, l’implémenter, et ainsi de suite. La plupart des organisations doivent d’abord classer par ordre de priorité les bases critiques.

Pour en savoir plus, consultez le Parcours DevSecOps.

Ce diagramme récapitule les contrôles de sécurité et explique comment les appliquer à chaque profil de sécurité de charge de travail.

Les considérations clés en matière de planification sont les suivantes :

  • Décalage à gauche mais procédez à une double vérification sur ces points - Cette référence est conçue pour détecter et corriger les problèmes le plus tôt possible pour vous permettre de les résoudre lorsqu’il est plus facile et moins cher de résoudre les problèmes (parfois appelés décalage vers la gauche), mais également de supposer l’échec et d’inclure une double vérification ultérieurement dans le processus. Vérifiez toujours deux fois les contrôles de sécurité dans le processus CI/CD ; assurez-vous que les problèmes évitables ne passent pas aux systèmes de production. Ce concept suit les principes de « défense en profondeur » et « échec de sécurité ».
  • Intelligence artificielle (IA) – les deux principales implications de l’intelligence artificielle sont les suivantes :
    • Sécuriser tout le code qu’il soit écrit par l’IA humaine ou générative
    • Utiliser les deux pour la sécurité - Appliquer les contrôles classiques et IA comme disponibles pour augmenter la visibilité et le contexte des problèmes de sécurité (tels que les outils Code Analysis)

Contrôles de sécurité

Les contrôles sont regroupés en phases de développement auxquelles ils s’appliquent et aux contrôles communs (bases critiques) qui s’appliquent à l’ensemble des phases de développement et des profils de contrôle :

Chacun de ces éléments est défini dans les sections suivantes :

Établir des bases critiques

Ce contrôle prend en charge la pratique SDL continue 1 – Établir des normes de sécurité, des indicateurs et de la gouvernance, pratique 2 – Exiger l’utilisation des fonctionnalités de sécurité éprouvées, des langages et des cadres, et la pratique 10 – Fournir une formation de sécurité.

Standard - ces contrôles s’appliquent à toutes les phases de développement et aux profils de contrôle.

Fournir une formation sur la sécurité

Ce contrôle se concentre sur la fourniture à vos développeurs et équipes de sécurité d’une formation pour reconnaître et résoudre les problèmes de sécurité via le cycle de vie du développement. Sans formation en matière de sécurité, vos équipes pourraient manquer les faiblesses de sécurité principales qui entraînent une compromission pendant la durée de vie des applications.

Par conséquent, il est impératif que vous implémentez la formation de sécurité sur tous les rôles (y compris les utilisateurs, les développeurs, les responsables de gamme de produits, les testeurs, etc.). Chaque rôle doit avoir une éducation sur les risques de sécurité et leur rôle dans la sécurité des applications. Cette formation peut prendre la forme de : formation formelle ou à la demande, exercices de simulation, modélisation des menaces, mentorat/conseillers, champions de sécurité, équipes de support de sécurité des applications, activités d’équipe violette, podcasts, vidéos ou toute autre méthode d’apprentissage.

En fin de compte, chaque rôle doit comprendre :

  • Pourquoi il est important de résoudre les risques de sécurité
  • Ce qu’ils doivent faire pour la sécurité dans leur rôle
  • Comment faire en sorte que la sécurité fasse partie de leur rôle quotidien

Personnes qui comprennent la perspective de l’attaquant, ses objectifs et comment cela apparaît dans des incidents de sécurité réels deviennent rapidement des alliés de sécurité au lieu d’essayer d’éviter la sécurité.

La sécurité est un jeu sans fin où les menaces, la technologie et les ressources commerciales à protéger changent toujours et les acteurs des menaces n’abandonnent jamais. L’approche de formation en matière de sécurité doit être en cours et en continu. Une formation efficace s’aligne et renforce les stratégies de sécurité, les pratiques de cycle de vie du développement logiciel (SDL), les normes et les exigences de sécurité logicielle. Le matériel d’apprentissage doit provenir d’insights dérivés de données et de fonctionnalités techniques nouvellement disponibles.

Bien que la sécurité soit le travail de tout le monde, il est important de se rappeler que tout le monde n’a pas besoin d’être un expert en sécurité, ni de devenir un testeur compétent en matière d’intrusion. Il est essentiel de s’assurer que tout le monde comprend les principes de base de la sécurité et comment les appliquer à leur rôle de création de sécurité dans des logiciels et des services. Cette formation doit inclure l’utilisation sécurisée de stations de travail, d’applications, d’identités et de comptes.

En particulier, les développeurs et les ingénieurs qui construisent des systèmes ne sont généralement pas des experts en sécurité. La formation dans les aspects techniques et conceptuels de la modélisation des menaces est nécessaire pour qu’elles deviennent efficaces afin qu’elles puissent créer des systèmes sécurisés par conception. Cette formation est essentielle pour que le processus de modélisation des menaces fonctionne à grande échelle dans les organisations où les développeurs comptent de nombreux professionnels de la sécurité. La modélisation des menaces doit être considérée comme une compétence d’ingénierie fondamentale dans laquelle tous les développeurs et ingénieurs doivent avoir au moins une compétence de base. Par conséquent, les équipes de développement et d’ingénierie doivent être formées pour être compétentes en modélisation des menaces dans le cadre de l’intégration et avec des actualisations périodiques.

Inclure la sécurité dans les postmortems sans blâme

L’analyse postmortem sans blâme est une méthode extrêmement importante pour que les équipes apprennent des erreurs de manière efficace et efficiente sans déclencher la défensive des membres de l’équipe en recherchant quelqu’un à blâmer. Les apprentissages de sécurité doivent être explicitement inclus dans le processus postmortem sans blâme pour s’assurer que les équipes optimisent également les apprentissages de sécurité.

Établir des normes de sécurité, des indicateurs et une gouvernance

Les organisations doivent établir ces normes de sécurité, ces indicateurs et cette gouvernance, car elles sous-tendent la capacité d’innover. Ceci permet un programme de sécurité solide qui protège non seulement les ressources de l’organisation, mais qui s’aligne aussi sur ses objectifs métier. Les normes de sécurité sont les exigences de base et les meilleures pratiques pour assurer la sécurité des systèmes, des données et des processus d’une organisation.

Ces standards doivent être mesurés et régis, notamment la surveillance de la conformité et l’examen régulier et la mise à jour des menaces actuelles, des outils et d’autres facteurs. Ce processus doit couvrir l’intégralité du cycle de vie à partir de l’idée initiale jusqu’à la désaffectation de l’application et à tous les environnements de développement de prise en charge.

Les indicateurs sont des mesures utilisées pour voir l’efficacité des contrôles et des processus de sécurité. Une mesure clé est le temps moyen de correction (Mean Time To Remediate, MTTR) pour le suivi de la durée pendant laquelle une application reste vulnérable. Cette mesure nous permet d’investir stratégiquement dans l’émission de correctifs de sécurité plus rapidement.

Remarque

Ce concept diffère du MTTR dans les opérations de sécurité axées sur le temps pour supprimer l’accès des personnes mal intentionnées aux ressources de l’organisation.

La gouvernance de la sécurité agit comme un guide pour les équipes de sécurité et est souvent construite sur des cadres et processus que les organisations utilisent pour gérer et contrôler leur sécurité de l’information. Cette orientation inclut des Politiques, Procédures, Contrôles, et la Gestion des Risques. Les indicateurs de performance permettent de quantifier l’exposition aux risques. Sans ces indicateurs, l’organisation peut ne pas comprendre pleinement ses vulnérabilités et son impact potentiel.

Étant donné que les exigences de sécurité peuvent être nouvelles, vous avez la possibilité d’adopter une approche progressive qui accélère progressivement les normes de codage à l’état idéal. Cette approche permet aux équipes d’apprendre et d’automatiser la surveillance et les contrôles.

Exiger l’utilisation de fonctionnalités de sécurité éprouvées, de langages et de cadres

Définissez et publiez une liste d’outils approuvés et des contrôles de sécurité qui leur sont associés. L’utilisation de solutions de sécurité bien établies et éprouvées est importante pou éviter les erreurs courantes, car la création de solutions sécurisées est très difficile. La tentative de réinventer des solutions de sécurité se traduit presque toujours par une augmentation des risques de sécurité et par une perte de temps et d’efforts.

Assurez-vous que les développeurs et les ingénieurs bénéficient des nouvelles fonctionnalités et protections d’analyse de la sécurité. Ils doivent toujours utiliser le compilateur, l’éditeur de liens et les bibliothèques les plus récents, ainsi que les indicateurs de compilateur et d’éditeur de liens appropriés pour générer des exécutables sécurisés.

Les organisations doivent implémenter un processus d’examen et d’approbation pour valider la sécurité des composants intégrés. Elles doivent établir une stratégie pour utiliser uniquement les composants approuvés dans les processus de génération et de déploiement appliqués et surveillés.

Sécurité des identités fondamentales

Assurez-vous que l’utilisation et l’intégration de l’identité suivent les meilleures pratiques de sécurité bien établies. Les acteurs de la menace utilisent des techniques d’attaques d’identité qu’ils utilisent fréquemment sur les systèmes de production et les processus de développement. Selon un dicton populaire, « les attaquants n’entrent pas par effraction, ils se connectent tout simplement. »

La sécurité des identités prend deux formes pour le développement :

  • Sécurité de l’identité pour le processus de développement : assurez-vous que tous les participants au processus de développement utilisent des méthodes d'authentification forte pour leur travail quotidien et ne disposent que des privilèges nécessaires à l’exécution de leurs tâches. Pour plus d’informations, consultez Contrôles d’accès aux identités/applications.
  • Sécurité de l’identité pour les systèmes et les applications : assurez-vous que les systèmes qu’ils conçoivent et créent respectent les meilleures pratiques en matière de méthodes d’authentification et d’autorisation (et qu’ils ne créent pas leurs propres imitations médiocres de systèmes d’identité prouvés et gérés).

Appliquez la sécurité des identités pour les systèmes et les applications en suivant les instructions de ces ressources :

Standards de chiffrement

Appliquer des pratiques de chiffrement saines à toutes les utilisations du chiffrement. Suivez toutes les recommandations décrites dans la pratique SDL continue 4 : Définir et utiliser des standards de chiffrement.

Pour plus d’informations, consultez Recommandations de chiffrement Microsoft SDL.

Sécurisation de votre environnement de développement

Ce contrôle prend en charge la pratique SDL continue 6 : Sécurisation de votre environnement d’ingénierie.

Ce contrôle se concentre sur la sécurisation de votre environnement de développement à l’aide de stations de travail sécurisées et d’environnements de développement intégré (IDE). Ce contrôle met en évidence l’avantage d’utiliser une approche Confiance Zéro dans votre cycle de vie de développement logiciel.

Dans le paysage actuel, les attaquants étendent leurs opérations pour cibler les machines de vos développeurs et falsifier les processus de génération de version. Un exemple essentiel de cette attaque était celui connu par SolarWinds, où l’attaquant a inséré une DLL malveillante avant les dernières étapes de la version logicielle. Cette opération a effectivement dérobé l’application et a entraîné une attaque ciblée qui a été distribuée à des milliers de clients dans le monde entier via la chaîne d’approvisionnement. Pour plus d’informations sur l’attaque SolarWinds, consultez le blog Microsoft Analyse de Solorigate, le fichier DLL compromis qui a déclenché une cyberattaque sophistiquée, et comment Microsoft Defender aide à protéger les clients.

Il est essentiel de renforcer les stations de travail, de créer des environnements, des identités et d’autres systèmes de développement pour garantir l’intégrité des applications développées. Dans le cas contraire, les attaquants peuvent compromettre votre application via votre système de gestion du code source (SCM) ou votre station de travail de développeur.

Cette pratique est une base essentielle de votre cycle de vie de développement et doit être établie sur tous les profils.

Tout au long de cette pratique, vous devez adopter une approche Confiance Zéro. En son cœur, le modèle Confiance Zéro exige que chaque demande d’accès (utilisateur, service ou appareil) soit vérifiée comme s’il provient d’un réseau non approuvé, quel que soit l’emplacement de la requête ou la ressource qu’il accède. Basez cette stratégie « Toujours s’authentifier et autoriser » en fonction de tous les points de données disponibles. Vous devez limiter l’accès des utilisateurs, en particulier des utilisateurs privilégiés, au moyen de stratégies d’accès juste à temps et juste assez (JAT/JAA), et segmenter l’accès afin de réduire les dommages éventuels en cas de violation.

La sécurisation renforcée de votre environnement de développement peut être réalisé par différentes méthodes, mais un bon point de départ est de considérer la station de travail du développeur. En utilisant des technologies telles que GitHub Codespaces ou Microsoft DevBox, vous déplacez l’environnement de développement vers des applications SaaS, qui peuvent ensuite être gérées par le biais de paramètres de sécurité et de réseau ou par le biais de stratégies organisationnelles.

Pour verrouiller davantage les stations de travail des développeurs, vous pouvez leur attribuer des stations de travail à accès privilégié/des stations de travail à accès sécurisé (PAW/SAW). Ces stations de travail vous aident à réduire les vecteurs de menace et à garantir un appareil de développement standardisé et contrôlé.

Conception sécurisée

Modélisation des menaces (révision de la conception de la sécurité)

Ce contrôle prend en charge la pratique SDL continue 3 : effectuer une modélisation des menaces.

Ce contrôle identifie les faiblesses de sécurité dans la conception qui peuvent entraîner des incidents de sécurité et des dommages impactant l’entreprise. Les faiblesses de sécurité dans la conception peuvent être difficiles à atténuer après l’implémentation de la conception, c’est pourquoi il est essentiel de trouver et de supprimer ces faiblesses dès le début du cycle de vie.

La modélisation des menaces sert de processus de révision de la conception de la sécurité, qui intègre la sécurité à la conception d’un système ou d’une application.

La modélisation des menaces identifie, évalue, hiérarchise et atténue les risques de sécurité au sein d’un système logiciel. Cette approche structurée pour analyser la conception et l’architecture d’une application logicielle identifie les menaces et vulnérabilités potentielles au début du processus de développement.

L’objectif ultime est de comprendre le système et de déterminer les éventuels problèmes. La modélisation des menaces permet d’atteindre cet objectif en appliquant une compréhension approfondie du système lui-même et de la façon dont un attaquant potentiel l’affiche.

Ce processus prend généralement la forme d’ateliers de découverte des menaces où une équipe d’experts sur le système et les experts en sécurité collaborent pour découvrir et documenter les risques. Bien que ce processus commence de manière informelle, il doit rapidement évoluer en un processus structuré qui traite de chaque aspect du service créé, de la façon dont il est utilisé et des interfaces système.

Les étapes de la modélisation des menaces sont les suivantes :

  • Identifier les cas d’utilisation, les scénarios et les ressources : commencez par comprendre les fonctions associées à l’entreprise et les cas d’utilisation du système afin d’évaluer l’impact potentiel de toute compromission du système et d’informer les discussions à suivre.
  • Créer une vue d’ensemble architecturale : créez un résumé visuel de l’application (ou utilisez-en un existant) pour fournir une compréhension claire du système et de son fonctionnement. Cette vue d’ensemble doit inclure : une carte de processus d’entreprise, des composants et des sous-systèmes, des limites d’approbation, des mécanismes d’authentification et d’autorisation, des interfaces externes et internes et des flux de données entre les acteurs et les composants.
  • Identifier les menaces : utilisez une méthodologie courante pour énumérer les menaces de sécurité potentielles telles que la méthode STRIDE ou la modélisation des menaces OWASP.
  • Identifier et suivre les préventions : surveillez et suivez les failles de conception découvertes à l’aide de processus de développement et d’outils existants pour vous assurer que les correctifs sont implémentés et documentés. Ce processus devrait inclure la hiérarchisation des mesures d’atténuation à prendre en premier afin que les équipes consacrent d’abord leur temps aux efforts les plus importants. Ce processus est piloté par les risques et vous n’avez peut-être pas de ressources pour atténuer entièrement tous les risques dans le premier cycle. Examiner attentivement les mesures d’atténuation, y compris les mesures d’atténuation partielles, qui augmentent le coût pour un attaquant pour un coût et des ressources défensives moindres. L’objectif de la sécurité est l’échec des attaquants, ce qui peut prendre la forme d’un blocage complet d’une technique d’attaque, de leur détection pour permettre une réponse, de leur ralentissement pour donner le temps à la sécurité de réagir, de la limitation de l’étendue des dommages, et plus encore.

Un modèle de menace sert souvent de processus de formation pour toutes les personnes concernées et fournit un contexte important pour d’autres activités de planification, d’implémentation et de test de la sécurité.

Les applications qui incluent l’utilisation de composants d’intelligence artificielle (IA) doivent évaluer les types de risques spécifiques associés à l’IA, qui sont différents des applications classiques.

Créez et analysez des modèles de menace : en communiquant sur la conception de la sécurité de leurs systèmes, en analysant ces conceptions pour les problèmes de sécurité potentiels à l’aide d’une méthodologie éprouvée et en suggérant et gérant des atténuations pour les problèmes de sécurité.

Sécuriser le code

Analyse du code

Ce contrôle prend en charge la pratique SDL continue 7 : Effectuer des tests de sécurité.

Ce contrôle se concentre sur l’augmentation de la sécurité du code lorsque les développeurs écrivent/saisissent dans un environnement de développement intégré (IDE) ou qu’ils vérifient le code. Ce contrôle est la pierre angulaire des pratiques DevSecOps, car il traite directement les vulnérabilités que les attaquants exploitent régulièrement.

Sans ce contrôle, vous risquez de manquer des vulnérabilités qui sont codées directement dans votre application par vos développeurs. Vos développeurs ne sont pas malveillants, mais peuvent manquer de compétences nécessaires pour identifier la raison pour laquelle ce qu’ils ont codé est non sécurisé.

Ce contrôle est essentiel pour tirer parti de la productivité et de la sécurité d’une approche décalée vers la gauche en intégrant des outils directement dans l’IDE. Ce processus permet de découvrir rapidement les vulnérabilités et d’y remédier le plus tôt possible et de la manière la plus rentable. Ce processus peut être appliqué rétroactivement aux applications déjà développées en identifiant les faiblesses de sécurité et en les corrigeant ultérieurement (bien qu’à des frais et des difficultés plus importants).

Ce processus prend généralement la forme de modules IDE ou d’outils d’analyse dédiés qui analysent le code à l’aide d’ensembles d’outils SAST (Static Analysis Security Testing) et DAST (Dynamic Analysis Security Testing).

Les outils SAST analysent le codebase existant et ont un accès complet au code. Les outils SAST peuvent identifier les principales faiblesses du code lui-même. En revanche, DAST est exécuté sur l’application déployée. Par conséquent, il n’a pas accès au code et est exécuté pour simuler et identifier les faiblesses de sécurité lors de l’exécution.

Remarque

Les applications d’IA présentent différents types de vulnérabilités (comme les préjugés et les hallucinations) par rapport aux applications classiques et nécessitent des outils qui se concentrent sur celles-ci.

Il est important qu’un contrôle qualité soit effectué ! Pour utiliser ces outils, il est essentiel de s’assurer qu’ils sont réglés de manière à réduire le bruit et les efforts inutiles liés aux faux positifs. L’optimisation de ces outils nécessite généralement un professionnel de la sécurité ayant une formation de développeur qui comprend les processus de développement de votre organisation. Les mêmes professionnels peuvent également fournir des conseils de triage et une expertise sur les détections individuelles pour les développeurs. Ils peuvent aider à distinguer les vrais et faux positifs, les vrais problèmes et les fausses alarmes. Les processus permettant aux développeurs d’accéder à ces experts sont souvent étroitement liés à la Formation en matière de sécurité, comme par le biais de programmes de champions, d’équipes de support de sécurité des applications, etc.

Minimum temporaire : assurez-vous d’activer les fonctionnalités de sécurité d’IDE prédéfinies et d’implémenter un niveau minimal d’analyse SAST dans votre référentiel pour identifier les vulnérabilités dans l’application. Il doit y avoir un processus documenté pour corriger les erreurs découvertes dans un délai raisonnable, bien que le standard de « barre de bogues » concernant les failles à corriger soit limité jusqu’à ce que l’application atteigne les profils de sécurité équilibrés ou élevés standard.

Standard : veillez à analyser entièrement tous les composants à l’aide de tous les outils SAST/DAST applicables et identifiez les faiblesses. Assurez-vous d’une couverture de sécurité complète sur votre code d’application. Assurez-vous que vous suivez le processus documenté de correction et que vous disposez d’un standard de « barre de bogues » qui correspond à la tolérance au risque de votre organisation.

Haute sécurité : assurez-vous que toutes les applications pertinentes mettent en œuvre un processus détaillé et documenté concernant toutes les vulnérabilités en matière de sécurité. Appliquez des correctifs avant toutes les activités de version. Assurez-vous que vous suivez le processus documenté de correction et que vous disposez d’une « barre de bogues » très restrictive qui correspond à la tolérance au risque de votre organisation pour les charges de travail à haute sécurité critiques pour l’entreprise.

De nombreux outils sont disponibles pour l’analyse statique. Pour plus d’informations, consultez la liste sur Microsoft Security Development Lifecycle.

Sécuriser le pipeline CI/CD

Chaîne d’approvisionnement/gestion des dépendances

Ce contrôle prend en charge la pratique SDL continue 5 : Sécurisation de la chaîne d’approvisionnement logicielle.

Ce contrôle se concentre sur la sécurisation de votre chaîne d’approvisionnement de développement à l’aide d’outils et de cadres SCA (Software Composition Analysis) tels que le Secure Supply Chain Consumption Framework (S2C2F). Ces processus permettent de réduire le risque de compromission par un code non-Microsoft.

Dans le paysage actuel, la plupart des applications s’appuient sur sur des logiciels Open Source (OSS) avec peu de supervision ou de contrôle auprès des consommateurs de ces composants. Ce contrôle met en évidence les stratégies, techniques et technologies de base pour ingérer, consommer, utiliser et gérer l’OSS en toute sécurité. Il met également l’accent sur la sécurisation des dépendances internes, en garantissant un cycle de vie complet de bout en bout, quel que soit l’utilisateur qui a codé le logiciel.

L’échec du contrôle de votre chaîne d’approvisionnement logicielle vous expose à des vulnérabilités significatives introduites par le code que vous ne contrôlez pas. Un exemple connu est la vulnérabilité log4J/Log4Shell, qui a permis l’exécution de code à distance dans n’importe quel système ou application à l’aide de ce package. Ces vulnérabilités peuvent survenir accidentellement ou de façon malveillante.

La sécurisation de votre chaîne d’approvisionnement est un élément essentiel pour garantir un cycle de développement sécurisé et doit être envisagée à chaque étape du profil, bien que chaque étape doive suivre le même processus standardisé d’ingestion des dépendances.

Minimum temporaire : inventoriez toutes vos dépendances afin de comprendre l’impact d’une vulnérabilité OSS sur votre application. Cet inventaire peut être réalisé à l’aide de Dependabot ou d’autres outils d’analyse de composition logicielle (SCA). Ces outils peuvent également vous aider à générer une nomenclature logicielle (SBOM).

Standard : analysez toutes les vulnérabilités OSS et corrigez-les automatiquement avec les demandes de tirage (pull request) automatiques. Ce contrôle peut également être obtenu à l’aide de Dependabot et de la révision ou du graphe des dépendances GitHub.

Haute sécurité : bloquez activement tous les packages non sécurisés avec des vulnérabilités exploitables utilisées dans l’application.

Pour en savoir plus sur ce contrôle et mesurer votre maturité en matière de sécurité OSS, consultez le cadre de la chaîne d’approvisionnement OSS et la documentation sur les meilleures pratiques de GitHub concernant la sécurisation de votre cycle de vie de développement.

Révision du code de sécurité

Ce contrôle se concentre sur la présence d’un code d’examen d’experts en sécurité pour identifier les failles de sécurité potentielles. Cette opération permet de trouver des problèmes de sécurité difficiles à automatiser les détections.

Cette révision peut être effectuée par : un homologue de la même équipe avec une expertise en sécurité des applications, un champion de sécurité au sein de l’organisation, un expert en sécurité d’application de l’équipe centrale de sécurité des applications ou un tiers externe.

Cette révision doit toujours être effectuée par une personne distincte du développeur qui a écrit le code. Cette révision doit être effectuée en tant qu’activité distincte une fois l’analyse automatisée du code terminée.

Minimum temporaire : ce contrôle est recommandé pour ce profil.

Standard : ce contrôle est recommandé pour ce profil.

Haute sécurité : ce contrôle est requis pour toutes les applications de haute sécurité et implique souvent plusieurs experts individuels.

Analyse des identifiants et des secrets

Ce contrôle prend en charge la pratique SDL continue 7 : Effectuer des tests de sécurité.

Ce contrôle se concentre sur la réduction des risques liés aux clés d’authentification et à d’autres secrets exposés dans le code. Les acteurs des menaces ont une expertise et une automatisation pour rechercher et exploiter des secrets incorporés dans le code.

La meilleure approche consiste à utiliser des identités gérées et des protocoles d’authentification modernes au lieu de clés et de secrets lorsque cela est possible. Bien que l’utilisation des clés API et des secrets ait traditionnellement été une pratique de codage et de test, la méthode préférée doit toujours être l’authentification basée sur l’identité pour accéder aux ressources en raison des capacités accrues de sécurité et de gestion du cycle de vie. L’implémentation de ce contrôle prend la forme d’utilisation d’identités managées, comme Les identités managées pour les ressources Azure.

Si l’utilisation des secrets est nécessaire, vous devez les sécuriser tout au long de leur cycle de vie, y compris leur création, leur utilisation, leur rotation régulière et leur révocation. Évitez d’utiliser directement des secrets dans le code et stockez-les uniquement dans un système de stockage sécurisé de clé/secret, tel qu’Azure Key Vault ou un module de sécurité matérielle (HSM) si nécessaire. Dans aucun cas, les clés de texte brut et les secrets ne doivent jamais être stockés dans le code, même temporairement ! Les attaquants trouvent et exploitent ces secrets.

Important

Les référentiels de code source internes ne sont pas sécurisés !

Les référentiels internes doivent être soumis aux mêmes exigences que les référentiels accessibles publiquement, du fait que les acteurs des menaces repèrent fréquemment les secrets et les clés dans les référentiels après avoir obtenu l’accès à un environnement via le hameçonnage ou d’autres moyens. Cette approche est nécessaire pour une approche Confiance Zéro qui suppose une violation et conçoit les contrôles de sécurité en conséquence.

Standard : une bonne hygiène secrète est essentielle et est requise dans tous les profils.

Remarque

Comme ces secrets sont trouvés par vos équipes ou par des attaquants, vous devez vous assurer que la clé ne peut pas être utilisée pour accéder aux ressources (varie selon le type de ressource) en plus de modifier le mécanisme en une méthode d’accès plus sécurisée comme les identités managées.

Vous trouverez plus de détails et de ressources :

Remarque

Nous vous recommandons vivement d’utiliser les clés de charge de travail avec des solutions de stockage secrète comme Azure Key Vault.

Sécuriser un pipeline

Ce contrôle prend en charge la pratique SDL continue 5 : Sécurisation de la chaîne d’approvisionnement logicielle.

Ce contrôle se concentre sur la sécurisation du pipeline DevOps et de tous les artefacts créés pendant les processus de génération de votre application.

Les pipelines constituent un élément essentiel de l’automatisation des activités reproductibles principales dans le cycle de vie DevSecOps. Dans le cadre de la CI/CD, votre équipe fusionne tous les codes des développeurs dans un codebase central à intervalles réguliers et exécute automatiquement des processus de construction et de test standard, ce qui inclut les ensembles d’outils de sécurité.

L’utilisation de pipelines pour exécuter des scripts ou déployer du code dans des environnements de production peut présenter des défis de sécurité uniques. Assurez-vous que vos pipelines CI/CD ne deviennent pas des avenues pour exécuter du code malveillant, autoriser les informations d’identification à voler ou donner aux attaquants toute surface d’accès. Vous devez également vous assurer que seul le code que votre équipe a l’intention de publier est déployé. Ce processus inclut des artefacts de vos pipelines CI/CD, en particulier les artefacts partagés entre différentes tâches qui peuvent être utilisées dans le cadre d’une attaque.

La génération de nomenclature logicielle (SBOM) doit être automatisée dans le processus de version pour créer cet artefact de provenance de code critiquement important sans nécessiter d’actions manuelles pour les développeurs.

La sécurité du pipeline peut être assurée en garantissant un bon Access Control aux ressources utilisées dans le pipeline et en validant/mettant à jour régulièrement les dépendances/scripts principaux. Il est important de noter que les scripts utilisés dans les pipelines CI/CD sont également du code et doivent être traités de la même façon que vous traitez d’autres codes dans votre projet.

Remarque

La sécurité du pipeline dépend de la sécurité de l’infrastructure sous-jacente et des comptes/identités utilisés pour le processus. Pour plus d’informations, consultez la sécurisation de votre environnement de développement et les contrôles d’opérations sécurisées (Contrôles de l’identité et de l’accès aux applications, Contrôles de l’hôte et du conteneur, Contrôles de l’accès au réseau).

Standard : ce contrôle doit être évalué au niveau d’accès de chaque ressource du projet ; il s’agit d’un contrôle requis sur tous les niveaux de profil DevSecOps.

Pour en savoir plus sur la sécurité des pipelines, consultez Sécurisation d’Azure Pipelines.

Opérations sécurisées

Tests d’intrusion de site en live

Ce contrôle prend en charge la pratique SDL continue 7 : Effectuer des tests de sécurité.

Faites en sorte que les testeurs d’intrusion d’applications professionnelles tentent de compromettre une instance active de la charge de travail complète. Ce test vérifie que les contrôles de sécurité de la charge de travail sont efficaces et cohérents. Les tests d’intrusion permettent de trouver et de mettre en évidence le chemin de la moindre résistance qu’un attaquant pourrait utiliser pour exploiter votre application et compromettre l’entreprise. Les tests d’intrusion peuvent êtr extrêmement précieux lorsqu’ils sont effectués au bon moment. Utilisez-les après avoir atténué les vulnérabilités faciles et peu coûteuses à exploiter découvertes lors des précédentes analyses.

Nous vous recommandons de procéder à ce test à tous les niveaux des profils de sécurité DevSecOps.

Minimum temporaire : nous vous recommandons d’effectuer un test d’intrusion sur toutes les applications. En raison de contraintes de temps, vous pouvez uniquement identifier les méthodes plus faciles dans l’application qu’un attaquant peut exploiter. Prévoyez de faire rapidement évoluer cette valeur pour atteindre au minimum le niveau standard.

Standard : dans un profil standard, nous vous recommandons d’effectuer un test d’intrusion. Dans ce cas, vous pouvez découvrir des vulnérabilités plus complexes en raison des précautions supplémentaires prises au début du processus de développement.

Haute sécurité : pour les applications métier et les charges de travail critiques, il est nécessaire d’effectuer un test d’intrusion. Toute vulnérabilité dans ces applications doit être traitée avec une attention et un soin supplémentaires.

Intégrez les résultats et les commentaires de ces activités pour améliorer vos processus et outils de sécurité.

Accès et contrôles d’identité/de l’application

Ce contrôle prend en charge la pratique SDL continue 8 : Garantir la sécurité de la plateforme opérationnelle et la pratique 6 : Sécurisation de votre environnement d’ingénierie.

Assurez-vous que les meilleures pratiques de sécurité pour la gestion des identités et des accès, y compris la sécurisation de l’accès privilégié sont suivies pour tous les éléments techniques de l’environnement de développement, du pipeline CI/CD, de la charge de travail opérationnel et d’autres systèmes de développement. Les acteurs de la menace ont des méthodes sophistiquées et une automatisation pour les attaques d’identité qu’ils utilisent fréquemment sur les systèmes de production et les processus de développement. La gestion des identités et des accès est un pilier fondamental du modèle Confiance Zéro recommandé par Microsoft.

Assurez-vous que les meilleures pratiques de sécurité sont suivies pour tous les systèmes de développement et l’infrastructure qui les héberge (machines virtuelles, conteneurs, appareils réseau, etc.).

Minimum temporaire : assurez-vous que tout le monde utilise l’authentification multifacteur et ne peut accéder qu’aux systèmes requis pour effectuer leurs tâches quotidiennes.

Standard : assurez-vous que les composants de l’infrastructure hébergeant la charge de travail (tels que les machines virtuelles, les conteneurs, le réseau et les systèmes d’identité) satisfont aux meilleures pratiques de sécurité en matière de gestion des identités et des accès, notamment en ce qui concerne la sécurisation des accès privilégiés.

Haute sécurité : implémentez une stratégie Confiance Zéro complète qui intègre l’authentification multifacteur, la détection des menaces des identités et leur réponse et la gestion des droits d’utilisation de l’infrastructure cloud (CIEM). Effectuez un modèle de menace spécifique à la charge de travail des systèmes d’identité et des composants prenant en charge chaque charge de travail de sécurité élevée.

Les identités managées sont la méthode d’authentification la plus sécurisée et la préférée dans la mesure du possible. L’utilisation de jetons et de secrets est moins sécurisée en raison de la nécessité de les stocker et de les récupérer au niveau de la couche application. En outre, les identités managées sont automatiquement restaurées sans intervention manuelle.

Vous trouverez plus de détails et de ressources :

Contrôles hôte/conteneur/environnement

Ce contrôle prend en charge la pratique SDL continue 8 : Garantir la sécurité de la plateforme opérationnelle et la pratique 6 : Sécurisation de votre environnement d’ingénierie.

Assurez-vous que les meilleures pratiques de sécurité sont suivies pour toutes les ressources de calcul et les environnements d’hébergement pour tous les éléments techniques du cycle de vie du développement. Les acteurs des menaces ont des méthodes sophistiquées et une automatisation pour les attaques d’infrastructure et de point de terminaison d’utilisateur qu’ils utilisent fréquemment sur les systèmes de production et les processus de développement. La sécurité de l’infrastructure est un pilier fondamental du modèle Confiance Zéro recommandé par Microsoft.

Ce contrôle doit inclure tous les éléments du cycle de vie opérationnel et de développement, notamment :

  • Stations de travail et environnements informatiques/opérationnels généraux
  • Stations de travail et environnements de développement dédiés
  • Infrastructure de pipeline CI/CD
  • Environnements d’hébergement de la charge de travail
  • Tous les autres systèmes de développement.

Ce contrôle inclut n’importe quelle ressource qui peut exécuter n’importe quel code, y compris, sans s’y limiter :

  • Machines virtuels (VM) hôtes et VM
  • Conteneurs et infrastructure de conteneur
  • Plateformes d’hébergement d’applications, de script et de code
  • Abonnements/comptes cloud et inscriptions
  • Stations de travail de développement, d’utilisateur et d’administration informatique

Veillez à appliquer les meilleures pratiques de sécurité aux composants de l’infrastructure, notamment les correctifs de sécurité (mises à jour), les configurations de sécurité de référence, etc.

Minimum temporaire : appliquez des configurations d’entreprise standard pour les hôtes et les abonnements.

Standard : assurez-vous que l’infrastructure répond aux meilleures pratiques de sécurité décrites dans le point de référence de sécurité Microsoft Cloud (MCSB).

Sécurité élevée : appliquez rigoureusement les standards MCSB et effectuez un modèle de menace spécifique à la charge de travail de l’infrastructure prenant en charge chaque charge de travail haute sécurité.

Vous trouverez plus de détails et de ressources :

Contrôles d’accès réseau

Ce contrôle prend en charge la pratique SDL continue 8 : Garantir la sécurité de la plateforme opérationnelle et la pratique 6 : Sécurisation de votre environnement d’ingénierie.

Assurez-vous que les meilleures pratiques de sécurité pour la gestion de l’accès réseau sont suivies pour tous les éléments techniques de l’environnement de développement, du pipeline CI/CD, de l’environnement de charge de travail opérationnel et d’autres systèmes de développement. Les acteurs de la menace ont des méthodes sophistiquées et une automatisation pour les attaques d’identité qu’ils utilisent fréquemment sur les systèmes de production et les processus de développement. La sécurité réseau est un pilier fondamental du modèle Confiance Zéro recommandé par Microsoft.

La sécurité réseau doit inclure :

  • Protection réseau externe : isolation du trafic externe/Internet non sollicité et atténuation des types d’attaques connus. Cette isolation prend généralement la forme de pare-feu Internet, de Web Application Firewall (WAF) et de solutions de sécurité d’API.
  • Protection réseau interne : isolation du trafic interne non sollicité (à partir d’autres emplacements réseau d’entreprise). Cette isolation peut utiliser des contrôles similaires comme la protection réseau externe et peut être granulaire à la charge de travail ou à des composants individuels et des adresses IP spécifiques.
  • Atténuations des dénis de service : protections contre le déni de service distribué (DDoS) et autres attaques par déni de service.
  • Security Service Edge (SSE) : utilisation de microsegmentation côté client pour fournir un accès sécurisé directement aux ressources, notamment l’application de stratégies Confiance Zéro.

Assurez-vous que les meilleures pratiques de sécurité sont suivies pour tous les systèmes de développement et l’infrastructure qui les héberge (machines virtuelles, conteneurs, appareils réseau, etc.).

Minimum temporaire : appliquez des configurations d’entreprise standard pour la charge de travail.

Standard : assurez-vous que tous les systèmes disposent d’une protection réseau externe, d’une protection DDoS et d’un minimum de protection réseau interne par charge de travail.

Haute sécurité : toutes les protections standard ainsi que la granularité élevée des protections réseau internes, le tunneling forcé du trafic serveur sortant via des mécanismes de protection réseau externe et un modèle de menace spécifique à la charge de travail de l’infrastructure réseau prenant en charge chaque charge de travail de sécurité élevée.

Vous trouverez plus de détails et de ressources :

Surveillance, réponse et récupération

Ce contrôle prend en charge la pratique SDL continue 9 : Implémenter la surveillance et la réponse de sécurité.

Assurez-vous que les équipes d’opérations de sécurité (SecOps/SOC) ont une visibilité, une détection des menaces et des procédures de réponse pour les charges de travail (API et applications) ainsi que l’infrastructure qui les héberge. Assurez-vous que les processus et outils inter-équipes entre les équipes SecOps et Infrastructure/Charge de travail permettent une récupération rapide après une attaque.

Ce contrôle maintient la sécurité de la charge de travail une fois qu’elle est en production et s’exécute activement dans votre organisation. Ce processus doit être intégré à votre fonctionnalité d’opérations de sécurité existante qui détecte et répond aux incidents de sécurité.

La surveillance de la sécurité pour les charges de travail personnalisées combine des solutions de détection et réponse étendues (XDR) pour les composants courants en analysant les journaux et d’autres données d’application pour détecter et examiner les menaces de sécurité potentielles. Les données d’application personnalisées incluent souvent : informations sur les demandes utilisateur, l’activité de l’application, les codes d’erreur, le trafic réseau, d’autres détails pertinents de l’application, des bases de données, des points de terminaison réseau et d’autres composants système.

Ces données sont ensuite améliorées avec des insights provenant de la veille des menaces en temps réel pour identifier les modèles de comportement anormal qui pourraient indiquer des tentatives potentielles d’infiltrer le réseau. Une fois agrégée, corrélée et normalisée, la plateforme XDR et Gestion des informations et des événements de sécurité (SIEM) offre des actions de correction.

Minimum temporaire : déployez des fonctionnalités XDR dans votre environnement pour surveiller le trafic de vos appareils d’utilisateur final.

Standard : déployez des détections XDR et de Gestion des informations et des événements de sécurité personnalisées qui identifient un comportement anormal par rapport à l’environnement global. Ce profil peut inclure des détections personnalisées pour des charges de travail individuelles.

Haute sécurité : les contrôles standards ainsi que les détections personnalisées par charge de travail basées sur des insights provenant de la modélisation des menaces de la charge de travail. Combinez ce profil avec l’IA pour fournir une prise de conscience contextuelle aux recommandations de correction.

Étapes suivantes

Adoptez ces contrôles de sécurité et adaptez-les aux exigences de tolérance et de productivité de votre organisation. Vous devez utiliser une approche d’amélioration continue où vous créez continuellement une version vers l’état idéal.

Commencez par classer par ordre de priorité les contrôles et les niveaux cibles idéaux minimum. Assurez-vous d’abord de l’impact positif sur la sécurité et des changements à faible friction. Classez par ordre de priorité, implémentez et intégrez le premier contrôle, puis répétez le processus avec le contrôle suivant.

Vous devez d’abord classer par ordre de priorité les bases critiques en raison de leur impact positif étendu et de l’analyse des identifiants et des secrets en raison de son impact élevé et de son utilisation fréquente des attaquants.