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

La sécurité et la confidentialité ne doivent jamais faire l’objet d’une attention ultérieure lors du développement de logiciels sécurisés. Un processus formel doit être en place pour s’assurer que l’équipe de développement tient compte de la sécurité et de la confidentialité à 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 le fonctionnement de tous les produits logiciels. Toutes les équipes de développement de Microsoft doivent respecter les processus et les exigences SDL. Cette adhésion se traduit par des logiciels plus sécurisés avec moins de vulnérabilités et moins graves à 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. Les nouveaux employés reçoivent une formation initiale 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. Ces exigences 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 gère, 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éfini, l’équipe de développement documente et suit clairement les exigences.

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 vous avez défini les exigences de sécurité, de confidentialité et fonctionnelles, vous pouvez commencer à concevoir le logiciel. Dans le cadre du processus de conception, créez des modèles de menace pour identifier, catégoriser et évaluer les menaces potentielles en fonction des risques. Gérez et mettez à jour les modèles de menace tout au long du cycle de vie de chaque produit à mesure que vous apportez des modifications 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. Créez des diagrammes Data Flow (DFD) pour représenter visuellement les interactions de flux de données clés, les types de données, les ports et les protocoles utilisés. Utilisez des DFD pour identifier et hiérarchiser les menaces pour l’atténuation que vous ajoutez 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 de publier un produit, vérifiez l’exactitude et l’exhaustivité de tous les modèles de menace, 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 de publier du code écrit, vous devez effectuer plusieurs vérifications et approbations 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. Une révision manuelle est effectuée par un réviseur qui n’est pas 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.

Vous devez également exécuter diverses vérifications automatisées intégrées au pipeline pour analyser le code pendant case activée et quand les builds sont compilées. 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 : identifie 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 : utilise 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 trouvent des problèmes avec le code, ils en informent l’émetteur. L’émetteur doit apporter les modifications nécessaires avant de soumettre à nouveau le code pour révision.

En outre, les fournisseurs internes et externes effectuent régulièrement des tests d’intrusion sur Microsoft services en ligne. Les tests d’intrusion fournissent un autre moyen de détecter des failles de sécurité que d’autres méthodes n’ont pas détectées. Pour plus d’informations 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. Le processus de mise en production libère systématiquement et progressivement les builds vers 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 est correctement testée dans les anneaux précédents.

Réponse

Après leur publication, tous les services Microsoft sont largement journalisés et surveillés. Un système de surveillance en quasi temps réel propriétaire centralisé identifie les incidents de sécurité potentiels. Pour plus d’informations 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.