En savoir plus sur la sécurité et la confidentialité dès la conception
Microsoft SDL souligne l’importance de la sécurité et de la confidentialité dès la conception. Les fonctionnalités de sécurité et de confidentialité ne doivent pas être des modules complémentaires, mais plutôt des composants centraux de nos produits et services. Nous assurons la sécurité de nos produits en définissant les exigences de sécurité dès le début du cycle de vie des fonctionnalités, en maintenant les modèles de menaces à jour pour tous les principaux composants et fonctionnalités de service et en exigeant une révision manuelle du code pour tout le code source.
Exigences de sécurité et de confidentialité
Les exigences de sécurité et de confidentialité doivent guider la conception de toutes les applications et tous les systèmes hautement sécurisés. Chez Microsoft, chaque produit, service et fonctionnalité que nous développons commence par des exigences de sécurité et de confidentialité clairement définies. Le développement de logiciels étant un processus continu, nous mettons continuellement à jour ces exigences tout au long du cycle de vie d’un produit afin de tenir compte des changements dans les fonctionnalités requises et le paysage des menaces. Les facteurs qui influencent les exigences de sécurité et de confidentialité comprennent la nature du logiciel en cours de développement, les menaces de sécurité connues, les enseignements tirés des incidents de sécurité, les exigences légales et du secteur, ainsi que les normes internes et les pratiques de codage.
Les étapes initiales de conception et de planification d’un produit ou d’une fonctionnalité sont le moment idéal pour définir les exigences de sécurité et de confidentialité. Cela permet aux équipes de développement d’intégrer des fonctionnalités de sécurité dans les fonctionnalités principales d’un produit. Par exemple, pendant la phase de conception de chaque produit, nous nous demandons si celui-ci traitera des informations sensibles, telles que les données client. Le SDL de Microsoft inclut des exigences de sécurité et de confidentialité pour aider les développeurs à mettre en œuvre les pratiques recommandées pour le traitement des données sensibles et garantir que notre logiciel collecte, traite et stocke les données sensibles en toute sécurité conformément aux exigences appropriées. Les exigences SDL pour la gestion des données sensibles incluent le chiffrement, la journalisation et la préparation de la réponse aux incidents pour protéger les données sensibles et fournir aux équipes de réponse de sécurité Microsoft les fonctionnalités d’audit nécessaires pour examiner et répondre aux incidents de sécurité potentiels.
Modèles de menace et diagrammes de flux de données (DFD)
Une fois que la conception d’un produit comprend des exigences de sécurité et de confidentialité clairement définies, les équipes de développement créent des modèles de menace pour visualiser les menaces de sécurité et de confidentialité qui seront les plus susceptibles d’affecter le produit. La modélisation des menaces permet d’identifier, de catégoriser et de classer les menaces potentielles en fonction du risque. Ainsi, les développeurs peuvent proposer et mettre en œuvre des atténuations appropriées. Le SDL exige que les équipes de développement de Microsoft tiennent à jour les modèles de menace et les diagrammes de flux de données (DFD) pour tous les principaux composants et fonctionnalités de service.
La modélisation des menaces commence par définir les composants d’un produit ou d’une fonctionnalité et schématiser leurs relations pour des scénarios fonctionnels essentiels, tels que l’authentification ou la gestion des données sensibles. Les diagrammes de modélisation des menaces incluent des flux de données, des fonctions et des processus pertinents qui permettent de visualiser les menaces pesant sur le service. Dans le cadre du processus de modélisation des menaces, les équipes de service créent et gèrent des DFD qui documentent tous les flux de données, les ports et les protocoles utilisés par un composant ou une fonctionnalité de service.
Les diagrammes terminés sont utilisés pour identifier les menaces pesant sur le système et hiérarchiser les menaces à atténuer. Les équipes de développement proposent et mettent en œuvre des mesures d’atténuation des risques révélés par leurs modèles de menace. De nouvelles atténuations sont ajoutées aux exigences de sécurité du produit, validées dans le code lors de la révision manuelle du code et des tests automatisés, et examinées dans le cadre du processus d’approbation précédant la publication.
Le développement de logiciels modernes utilisant Agile met l’accent sur la livraison rapide de fonctionnalités aux clients, c’est pourquoi la modélisation des menaces est un processus continu. Afin de garantir une cohérence entre les équipes de développement et de maintenir les modèles de menace à jour, Microsoft exige que ses développeurs utilisent l’outil de modélisation des menaces Microsoft pour tous les modèles de menaces. L’outil de modélisation des menaces permet aux développeurs ou aux architectes logiciel de Microsoft de :
- communiquer sur la conception de la sécurité de leurs systèmes.
- analyser les conceptions de sécurité afin de détecter d’éventuels problèmes de sécurité en utilisant une méthodologie éprouvée.
- suggérer et gérer les atténuations des problèmes de sécurité.
Lors de la révision de la sécurité précédant la publication, tous les modèles de menace sont examinés pour en vérifier l’exactitude et l’exhaustivité, y compris les atténuations des risques inacceptables. Ces examens maintiennent la responsabilité et encouragent la conception axée sur la sécurité.
Révision manuelle du code
Nos équipes de développement utilisent Azure DevOps Git pour le contrôle de version sur tous les nouveaux référentiels de code. Pour vérifier que tout le code développé chez Microsoft est conforme au SDL et aux exigences de conception, le SDL nécessite un examen manuel du code par un analyste indépendant avant que les modifications du code puissent être archivées dans une branche de publication. Les analystes de code vérifient les erreurs de codage et vérifient que les modifications de code répondent aux exigences SDL et de conception, réussissent les tests fonctionnels et de sécurité et fonctionnent de manière fiable. Ils examinent également la documentation, les configurations et les dépendances associées pour s’assurer que les modifications de code sont correctement documentées et ne provoqueront pas d’effets secondaires inattendus.
Si un analyste trouve des problèmes lors de la révision du code, il peut demander à l’auteur de soumettre à nouveau le code avec les modifications suggérées et des tests supplémentaires. Les analystes de code peuvent également décider de bloquer entièrement l’archivage du code qui ne répond pas aux exigences. Toutes les modifications du code soumis pour publication doivent être clairement imputables à un seul développeur et examinées par un analyste indépendant afin de maintenir la responsabilité. De plus, toutes les modifications du code doivent être enregistrées et conservées pendant au moins 18 mois pour fournir un enregistrement vérifiable de toutes les modifications de code, ainsi que leur auteur, la justification commerciale, les résultats des tests et l’analyste qui a approuvé la modification.