Vue d’ensemble du développement et des opérations de sécurité
Comment Microsoft implémente-t-il des pratiques de développement sécurisé ?
Le cycle de développement de la sécurité de Microsoft (SDL) est un processus d’assurance en matière de sécurité axé sur le développement et le fonctionnement des logiciels sécurisés. SDL fournit des exigences de sécurité détaillées et mesurables pour les développeurs et ingénieurs de Microsoft afin de réduire le nombre et la gravité des vulnérabilités dans nos produits et services. Toutes les équipes de développement de logiciels Microsoft doivent respecter les exigences SDL et nous les mettez à jour en permanence pour refléter l’évolution du paysage des menaces, les meilleures pratiques du secteur et les normes réglementaires en matière de conformité.
Comment le SDL de Microsoft améliore-t-il la sécurité des applications ?
Le processus SDL chez Microsoft peut être conçu en cinq phases de développement : exigences, conception, implémentation, vérification et publication. Il commence par définir les exigences logicielles en gardant à l’esprit la sécurité. Pour atteindre cet objectif, nous posons des questions pertinentes en matière de sécurité sur ce que l’application doit accomplir. L’application doit-elle collecter des données sensibles ? L’application peut-elle effectuer des tâches sensibles ou importantes ? L’application doit-elle accepter les entrées provenant de sources non fiables ?
Une fois les impératifs de sécurité pertinents identifiés, nous concevons nos logiciels de façon à intégrer des fonctionnalités de sécurité répondant à ces exigences. Nos développeurs implémentent les exigences de SDL et de conception dans le code, que nous vérifions via la révision manuelle du code, l’automatisation automatisée des outils de sécurité et le test de pénétration. Enfin, avant la publication du code, les nouvelles fonctionnalités et modifications matérielles font l’objet d’une révision finale de la sécurité et de la confidentialité afin de s’assurer que toutes les conditions sont remplies.
Comment Microsoft teste-t-il le code source pour les vulnérabilités courantes ?
Pour aider nos développeurs à mettre en œuvre les exigences de sécurité pendant le développement du code et après sa publication, Microsoft leur propose une suite d’outils de développement sécurisés qui permettent de vérifier automatiquement le code source et de détecter les failles de sécurité. Microsoft définit et publie une liste d’outils approuvés que nos développeurs peuvent utiliser, tels que les compilateurs et les environnements de développement, ainsi que les vérifications de sécurité intégrées exécutées automatiquement dans les pipelines de build De Microsoft. Nos développeurs utilisent les dernières versions des outils approuvés pour profiter des nouvelles fonctionnalités de sécurité.
Avant que le code puisse être vérifié dans une branche de publication, le SDL nécessite une révision manuelle du code par un réviseur distinct. 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. Une fois que le code a été considéré comme satisfaisant par le réviseur, il fournit une approbation, qui est requise pour que le code puisse passer à la phase de déploiement suivante.
En plus des outils de développement sécurisés et de la révision manuelle du code, Microsoft applique les exigences SDL à l’aide d’outils de sécurité automatisés. La plupart de ces outils sont intégrés au pipeline de validation et analysent automatiquement le code pour les failles de sécurité lors de son analyse et au cours de la compilation des nouvelles builds. Les exemples incluent l’analyse de code statique pour les failles de sécurité courantes et les scanneurs d’informations d’identification qui analysent le code pour les secrets incorporés. Les problèmes découverts par les outils de sécurité automatisés doivent être résolus pour que les nouvelles builds passent l’examen de sécurité et soient approuvées pour publication.
Comment Microsoft gère-t-il les logiciels open source ?
Microsoft a adopté une stratégie de haut niveau pour la gestion de la sécurité open source, qui utilise des outils et des flux de travail conçus pour :
- Comprendre les composants Open source utilisés dans nos produits et services.
- Suivez l’emplacement et la façon dont ces composants sont utilisés.
- Déterminez si ces composants présentent des vulnérabilités.
- Répondre correctement lorsque des vulnérabilités sont découvertes et qui affectent ces composants.
Les équipes Microsoft Engineering sont responsables de la sécurité de tous les logiciels open source inclus dans un produit ou un service. Pour atteindre cette sécurité à grande échelle, Microsoft a intégré des fonctionnalités essentielles dans les systèmes d’ingénierie via la gouvernance des composants (CG), qui automatise la détection open source, les flux de travail de conditions légales et l’alerte pour les composants vulnérables. Les outils CG automatisés analysent les builds de Microsoft pour les composants open source et les vulnérabilités de sécurité associées ou les obligations légales. Les composants découverts sont enregistrés et envoyés aux équipes appropriées pour les avis d’entreprise et de sécurité. Ces examens sont conçus pour évaluer les obligations légales ou les vulnérabilités de sécurité associées aux composants Open source et les résoudre avant d’approuver les composants à des fins de déploiement.
Réglementations externes associées & certifications
Les services en ligne de Microsoft sont régulièrement audités pour assurer la conformité avec les réglementations et certifications externes. Reportez-vous au tableau suivant pour la validation des contrôles liés au développement et au fonctionnement de la sécurité.
Azure et Dynamics 365
| Audits externes | Section | Date de rapport la plus récente |
|---|---|---|
| ISO 27001/27002 Déclaration d’applicabilité Certification |
A.12.1.2 : Contrôles de gestion des changements A.14.2 : Sécurité dans les processus de développement et de support |
2 décembre 2020 |
| ISO 27017 Déclaration d’applicabilité Certification |
A.12.1.2 : Contrôles de gestion des changements A.14.2 : Sécurité dans les processus de développement et de support |
2 décembre 2020 |
| SOC 1 SOC 2 SOC 3 |
SDL-1 : méthodologie SDL (Security Development Lifecycle) SDL-2 : Exigences de contrôle de sécurité documentées dans les publication SDL-4 : répartition des environnements de test et de production SDL-6 : analyses de programmes malveillants sur les builds de code source SDL7 : révision du SDL semi-annuel |
31 mars 2021 |
Office 365
| Audits externes | Section | Date de rapport la plus récente |
|---|---|---|
| FedRAMP | SA-3 : Cycle de vie du développement système | 24 septembre 2020 |
| ISO 27001/27002/27017 Déclaration d’applicabilité Certification |
A.12.1.2 : Contrôles de gestion des changements A.14.2 : Sécurité dans les processus de développement et de support |
20 avril 2021 |
| SOC 1 SOC 2 |
CA-03 : Gestion des risques CA-18 : Gestion des changements CA-19 : Analyse des changements CA-21 : Test des changements CA-38 : Configurations de référence CA-46 : Révision de sécurité |
24 décembre 2020 |