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

La sécurité et la confidentialité ne doivent jamais être une solution 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 points du cycle de vie du produit. Le SDL (Security Development Lifecycle) 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 exigences SDL, ce qui se traduit par des logiciels plus sécurisés avec des vulnérabilités moins nombreuses 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é prises 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 s’assurer que toutes les exigences en matière de sécurité et de confidentialité et les meilleures pratiques sont traitées correctement. Les deux activités de sécurité de prise en charge, la formation et la réponse, sont effectuées avant et après les phases principales respectivement pour garantir 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 une formation spécifique adaptée à leur rôle. Une formation initiale de sensibilisation à la sécurité est fournie aux nouveaux employés lors de l’embauche et une formation d’actualisation annuelle est requise tout au long de leur emploi chez Microsoft.

Les développeurs et les ingénieurs doivent également participer à une formation spécifique au rôle pour les tenir informés des principes de base de la sécurité et des tendances récentes dans le développement sécurisé. Tous les employés à temps plein, les stagiaires, le personnel contingent, les sous-traitants et les tiers sont également encouragés et ont la possibilité de demander une formation avancée sur la sécurité et la protection de la vie privée.

Conditions requises

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 d’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érera, 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 définies, 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 de fonctionnalités et le paysage des menaces.

Conception

Une fois les exigences de sécurité, de confidentialité et fonctionnelle définies, la conception du logiciel peut commencer. Dans le cadre du processus de conception, des modèles de menaces sont créés pour aider à identifier, classer et évaluer les menaces potentielles en fonction des risques. Les modèles de menace doivent être maintenus 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 comment ils interagissent entre eux dans des scénarios fonctionnels clés, tels que l’authentification. Data Flow diagrammes (DFD) sont créés 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. 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 développeurs doivent utiliser le Threat Modeling Tool de Microsoft pour tous les modèles de menace, ce qui permet à l’équipe de :

• 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 vérifier la précision et l’exhaustivité, y compris l’atténuation des risques inacceptables.

Implémentation

L’implémentation commence par l’écriture de code par les développeurs 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 du logiciel qu’ils conçoivent. Ces outils incluent les compilateurs, les environnements de développement sécurisés et les contrôles de sécurité intégrés.

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 au protocole SDL, répond aux exigences de conception et qu’il est exempt d’erreurs de codage. SDL exige que les examens manuels soient effectués par un réviseur distinct du personnel qui a élaboré le code. La séparation des tâches est un contrôle important dans cette étape pour s’assurer qu’aucun code ne peut être écrit et libéré par la même personne, ce qui peut entraîner des dommages accidentels ou malveillants potentiels.

Diverses vérifications automatisées sont également requises et sont intégrées au pipeline de validation pour analyser le code lors de l’archivage et de la compilation des builds. Les vérifications de sécurité utilisées chez Microsoft se répartissent dans les 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 vérifier que le code est prêt pour la production.
• Scanneur d’informations d’identification et de secrets : identifiez les instances possibles d’informations d’identification et d’exposition de 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 des API et des analyseurs afin de rechercher 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 meilleures pratiques.
• Gouvernance des composants ( CG) : détection et vérification de la version, des vulnérabilités et des obligations légales des logiciels open source.

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

En outre, les 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 les 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.

Débloquer

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 libérées vers des groupes plus grands et plus grands, appelés anneaux, dans ce qu’on appelle un processus de déploiement sécurisé (SDP). Les anneaux SDP sont définis comme suit :

• Anneau 0 : L’équipe de développement responsable du service
• Anneau 1 : Tous les employés de Microsoft
• Anneau 2 : Utilisateurs en dehors de Microsoft qui ont configuré leur organisation ou des utilisateurs spécifiques pour qu’ils se trouvent sur le canal de mise en production ciblé
• Anneau 3 : version standard mondiale 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 build a été correctement testée pour la stabilité dans les anneaux précédents.

Réponse

Tous les services Microsoft sont largement enregistrés et surveillés après la 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 la vue d’ensemble de la surveillance dela sécurité et la gestion des incidents de sécurité Microsoft.