Cycle de développement Microsoft Security Development Lifecycle (SDL)

La sécurité et la confidentialité ne doivent jamais être une considération après coup lors du développement de logiciels sécurisés. Un processus formel doit être en place pour s’assurer qu’ils sont pris en compte à tous les moments du cycle de vie du produit. Le cycle de vie du développement de la sécurité (SDL) de Microsoft intègre des exigences de sécurité complètes, des outils spécifiques à la technologie et des processus obligatoires dans le développement et l’exploitation de tous les produits logiciels. Toutes les équipes de développement de Microsoft doivent respecter les exigences et les processus SDL, ce qui permet d’obtenir des logiciels plus sécurisés avec moins de vulnérabilités graves et un coût de développement réduit.

Microsoft SDL se compose de sept composants, dont cinq phases principales et deux activités de sécurité de prise en charge. Les cinq phases principales sont les exigences, la conception, l’implémentation, la vérification et la mise en production. Chacune de ces phases contient des vérifications et des approbations obligatoires pour garantir que toutes les exigences et bonnes pratiques en matière de sécurité et de confidentialité sont correctement traitées. Les deux activités de sécurité de prise en charge, la formation et la réponse, sont effectuées respectivement avant et après les phases principales pour s’assurer qu’elles sont correctement implémentées et que les logiciels restent sécurisés après le déploiement.

Formation

Tous les employés de Microsoft doivent suivre une formation générale de sensibilisation à la sécurité et à la confidentialité, ainsi qu’une formation spécifique liée à leur rôle. Une formation initiale est fournie aux nouveaux employés lors de leur embauche et une formation annuelle de mise à jour est requise tout au long de leur emploi chez Microsoft.

Les développeurs et les ingénieurs doivent également participer à des formations spécifiques aux rôles pour les tenir informés des principes de base de la sécurité et des tendances récentes en matière de développement sécurisé. Tous les employés à temps plein, les stagiaires, le personnel conditionnel, les sous-traitants et les tiers sont également encouragés et ont la possibilité d’obtenir une formation avancée en matière de sécurité et de confidentialité.

Configuration requise

Chaque produit, service et fonctionnalité développé par Microsoft commence par des exigences de sécurité et de confidentialité clairement définies ; ils constituent la base des applications sécurisées et informent leur conception. Les équipes de développement définissent ces exigences en fonction de facteurs tels que le type de données que le produit va gérer, les menaces connues, les meilleures pratiques, les réglementations et les exigences du secteur, ainsi que les leçons tirées des incidents précédents. Une fois définies, les exigences sont clairement documentées et suivies.

Le développement de logiciels est un processus continu, ce qui signifie que les exigences de sécurité et de confidentialité associées changent tout au long du cycle de vie du produit pour refléter les changements dans les fonctionnalités et le paysage des menaces.

Conception

Une fois que les exigences de sécurité, de confidentialité et fonctionnelles ont été définies, la conception du logiciel peut commencer. Dans le cadre du processus de conception, des modèles de menace sont créés pour aider à identifier, classer et évaluer les menaces potentielles en fonction du risque. Les modèles de menace doivent être conservés et mis à jour tout au long du cycle de vie de chaque produit à mesure que des modifications sont apportées au logiciel.

Le processus de modélisation des menaces commence par définir les différents composants d’un produit et la façon dont ils interagissent entre eux dans des scénarios fonctionnels clés, tels que l’authentification. les diagrammes Data Flow (DFD) sont créés pour représenter visuellement les interactions, les types de données, les ports et les protocoles utilisés dans les flux de données clés. Les DFD sont utilisés pour identifier et hiérarchiser les menaces pour l’atténuation qui sont ajoutées aux exigences de sécurité du produit.

Les équipes de service utilisent les Threat Modeling Tool de Microsoft pour créer des modèles de menace, qui permettent à l’équipe d’effectuer les opérations suivantes :

• Communiquer sur la conception de la sécurité de leurs systèmes
• Analyser les conceptions de sécurité pour détecter les problèmes de sécurité potentiels à l’aide d’une méthodologie éprouvée
• Suggérer et gérer l’atténuation des problèmes de sécurité

Avant la publication d’un produit, tous les modèles de menace sont examinés pour en assurer l’exactitude et l’exhaustivité, y compris l’atténuation des risques inacceptables.

Implémentation

L’implémentation commence par les développeurs qui écrivent du code en fonction du plan qu’ils ont créé au cours des deux phases précédentes. Microsoft fournit aux développeurs une suite d’outils de développement sécurisés pour implémenter efficacement toutes les exigences de sécurité, de confidentialité et de fonction des logiciels qu’ils conçoivent. Ces outils incluent des compilateurs, des environnements de développement sécurisés et des vérifications de sécurité intégrées.

Vérification

Avant qu’un code écrit puisse être publié, plusieurs vérifications et approbations sont nécessaires pour vérifier que le code est conforme à SDL, qu’il répond aux exigences de conception et qu’il est exempt d’erreurs de codage. Les révisions manuelles sont effectuées par un réviseur distinct de l’ingénieur qui a développé le code. La séparation des tâches est un contrôle important dans cette étape pour réduire le risque d’écriture et de publication de code qui entraîne des dommages accidentels ou malveillants.

Diverses vérifications automatisées sont également requises et intégrées au pipeline pour analyser le code pendant case activée et lors de la compilation des builds. Les vérifications de sécurité utilisées chez Microsoft appartiennent aux catégories suivantes :

• Analyse statique du code : analyse le code source pour détecter les failles de sécurité potentielles, notamment la présence d’informations d’identification dans le code.
• Analyse binaire : évalue les vulnérabilités au niveau du code binaire pour confirmer que le code est prêt pour la production.
• Analyseur d’informations d’identification et de secrets : identifiez les instances possibles d’informations d’identification et d’exposition des secrets dans le code source et les fichiers de configuration.
• Analyse du chiffrement : valide les meilleures pratiques de chiffrement dans le code source et l’exécution du code.
• Test fuzz : utilisez des données incorrectes et inattendues pour exercer les API et les analyseurs afin de case activée des vulnérabilités et de valider la gestion des erreurs.
• Validation de la configuration : analyse la configuration des systèmes de production par rapport aux normes de sécurité et aux bonnes pratiques.
• Gouvernance des composants (CG) : détection et vérification des logiciels open source de la version, de la vulnérabilité et des obligations légales.

Si le réviseur manuel ou les outils automatisés rencontrent des problèmes avec le code, l’émetteur en est averti et il est tenu d’apporter les modifications nécessaires avant de le soumettre à nouveau pour révision.

En outre, des tests d’intrusion sont régulièrement effectués sur Microsoft services en ligne par des fournisseurs internes et externes. Les tests d’intrusion fournissent un autre moyen de détecter des failles de sécurité non détectées par d’autres méthodes. Pour en savoir plus sur les tests d’intrusion chez Microsoft, consultez Simulation d’attaque dans Microsoft 365.

Version

Après avoir passé tous les tests et révisions de sécurité requis, les builds ne sont pas immédiatement publiées pour tous les clients. Les builds sont systématiquement et progressivement publiées sur des groupes de plus en plus grands, appelés anneaux, dans ce que l’on appelle un processus de déploiement sécurisé (SDP). Les anneaux SDP peuvent généralement être définis comme suit :

• Ring 0 : l’équipe de développement responsable du service ou de la fonctionnalité
• Anneau 1 : tous les employés de Microsoft
• Sonnerie 2 : utilisateurs en dehors de Microsoft qui ont configuré leur organization ou des utilisateurs spécifiques pour qu’ils se trouvent sur le canal de publication ciblé
• Ring 3 : Version mondiale standard en sous-phases

Les builds restent dans chacun de ces anneaux pendant un nombre approprié de jours avec des périodes de charge élevées, à l’exception de l’anneau 3, car la stabilité de la build a été testée de manière appropriée dans les anneaux précédents.

Réponse

Tous les services Microsoft sont largement journalisés et surveillés après leur publication, identifiant les incidents de sécurité potentiels à l’aide d’un système de surveillance en quasi temps réel propriétaire centralisé. Pour en savoir plus sur la surveillance de la sécurité et la gestion des incidents de sécurité chez Microsoft, consultez Vue d’ensemble de la surveillance de la sécurité et Gestion des incidents de sécurité Microsoft.