Cycle de développement d'une sécurité informatique fiable

Paru le 01 mars 2005 | Derniére mise à jour le August 23, 2005
Par Steve Lipner, Michael Howard

Résumé : Cet article présente le cycle de développement d'une sécurité informatique fiable (ou SDL, Security Development Lifecycle), processus adopté par Microsoft pour le développement des logiciels qui doivent pouvoir résister à des attaques malveillantes. Ce processus comprend l'ajout d'une série d'activités et de documents centrés sur la sécurité à chacune de phases du processus de développement des logiciels Microsoft. Les activités et documents incluent le développement de modèles de menaces au cours de la conception des logiciels, l'utilisation d'outils d'analyse de code statique au cours de l'implémentation et la réalisation de la révision du code et de tests de sécurité au cours d'une « campagne de sécurité » ciblée. Avant que les logiciels soumis au SDL ne puissent être diffusés, ils doivent subir une révision finale de sécurité réalisée par une équipe indépendante du groupe de développement. Comparés aux logiciels qui n'ont pas été soumis au SDL, ceux qui l'ont subi ont montré un taux nettement plus faible de découvertes externes de failles de sécurité. Cet article présente le SDL et décrit une expérience d'implémentation avec des logiciels Microsoft. (19 pages imprimées)

Remarque : Cet article est une version mise à jour du « Trustworthy Computing Security Development Lifecycle » déjà présenté à l'occasion de la conférence annuelle consacrée aux applications de sécurité informatique co-parrainée par l'IEEE, qui s'est tenue à Tucson, en Arizona en décembre.

*
Sur cette page

1. Introduction
1.1 Le processus de base
1.2 Présentation du cycle de développement de la sécurité
2. Processus du cycle de développement de la sécurité
2.1 Phase de détermination des besoins
2.2 Phase de conception
2.3 Phase d'implémentation
2.4 Phase de vérification
2.5 Phase de diffusion
2.6 Phase de support et de dépannage
3.1 Application obligatoire du SDL
3.2 Formation obligatoire
3.3 Mesure pour les équipes produits
3.4 L'équipe de sécurité centrale
4. Résultats de l'implémentation du cycle de développement de la sécurité chez Microsoft
5. Observations concernant l'application du cycle de développement de la sécurité
5.1 Efficacité des éléments du SDL
5.2 Outils, tests et révision du code
5.3 Investissements
5.4 Résultats
6. Conclusions
7. Remerciements
8. Références
9. Avertissements

1. Introduction

Il est indispensable que tous les fournisseurs de logiciels traitent les menaces contre la sécurité. La sécurité est un impératif majeur pour les fournisseurs de logiciels, sous la pression du marché, du fait de la nécessité de protéger les infrastructures critiques, mais aussi d'induire et préserver une confiance générale dans l'informatique. L'un des grands défis que doivent relever tous les fournisseurs de logiciels est la création de logiciels plus sécurisés qui nécessitent moins de mises à jour par des correctifs et une gestion de la sécurité moins contraignante.

Pour l'industrie du logiciel, la clé pour satisfaire la demande actuelle d'amélioration de la sécurité consiste à implémenter des processus répétables qui fournissent en toute fiabilité une sécurité dont les améliorations sont mesurables. Ainsi, les fournisseurs de logiciels doivent s'orienter vers des processus de développement plus rigoureux, qui tiennent davantage compte de la sécurité. Ce type de processus a pour but de réduire le nombre de failles de sécurité encore existantes dans la conception, le codage et la documentation, de les détecter et de les supprimer le plus tôt possible dans le cycle de développement. La nécessité d'un tel processus est plus grande pour les logiciels d'entreprise et grand public susceptibles d'être utilisés pour traiter les données reçues d'Internet, pour contrôler les systèmes stratégiques risquant d'être attaqués ou pour traiter les informations d'identification personnelle.

La création de logiciels plus sécurisés comporte trois aspects : un processus répétable, la formation des ingénieurs, ainsi que des mesures et une évaluation. Ce document s'intéresse en premier lieu à l'aspect du processus répétable du SDL, bien qu'il présente également la formation des ingénieurs et fournisse un certain nombre de mesures globales pour montrer l'impact de l'application d'un sous-ensemble du SDL.

Si l'expérience de Microsoft peut servir de guide, l'adoption du SDL par d'autres organisations ne devrait pas alourdir excessivement le coût de développement des logiciels. Elle montre que les avantages liés à la fourniture de logiciels plus sécurisés (par exemple, avec moins de correctifs, des clients plus satisfaits) en compensent les coûts.

Le SDL suppose de modifier les processus de développement logiciel d'une organisation en intégrant des mesures qui conduisent à une meilleure sécurité logicielle. Ce document résume ces mesures et décrit la manière de les intégrer dans un cycle de développement logiciel classique. L'intention de ces modifications n'est pas de remanier totalement le processus, mais plutôt d'y ajouter des points de contrôle de sécurité bien définis et des documents de sécurité.

Ce document suppose qu'il existe un groupe central dans la société (ou une organisation de développement des logiciels) qui dirige le développement et l'évolution des recommandations en matière de sécurité et des améliorations de processus, sert de source d'expertise à l'organisation dans son ensemble, et effectue une révision finale de sécurité (FSR, Final Security Review) avant la diffusion des logiciels. L'expérience de Microsoft montre que l'existence d'une telle organisation est essentielle pour réussir l'implémentation du SDL et améliorer la sécurité des logiciels. D'autres organisations pourront envisager de déléguer le rôle d'« équipe centrale de sécurité » à un sous-traitant ou à un consultant. Cet article décrit l'intégration d'un ensemble d'étapes visant à améliorer la sécurité des logiciels dans le processus de développement généralement utilisé par les grandes organisations de développement de logiciels. Ces étapes ont été conçues et implémentées par Microsoft dans le cadre de son initiative Trustworthy Computing. L'objectif de l'amélioration de ces processus est de réduire la quantité et la gravité des failles de sécurité dans les logiciels utilisés par les clients. Dans ce document, le processus modifié développement des logiciels, en cours d'implémentation chez Microsoft, est nommé cycle de développement des logiciels informatiques fiables (ou plus simplement SDL).

L'expérience de Microsoft montre que l'équipe de sécurité doit être disponible pour les fréquentes interactions au cours de la conception et du développement des logiciels, et doit être de confiance relativement aux informations techniques et commerciales sensibles. C'est pourquoi la solution de prédilection consiste à créer une équipe de sécurité au sein de l'organisation de développement de logiciels (bien qu'il puisse être judicieux de faire appel à des consultants pour aider à créer et à former les membres de l'équipe).


1.1 Le processus de base

Le processus de développement des logiciels généralement accepté chez Microsoft respecte dans les grandes lignes le flux illustré par la figure 1. À un haut niveau, ce processus est classique dans les pratiques industrielles.

cliquez pour agrandir
Figure 1. Le processus de développement standard de Microsoft (cliquez sur l'image pour l'agrandir)

Bien que la figure 1 montre cinq étapes et semble suggérer un développement en « cascade », il s'agit en fait d'un processus en spirale. Les besoins et la conception font souvent l'objet de révisions lors de l'implémentation, en réponse aux changements des exigences du marché et aux réalités qui apparaissent au cours de l'implémentation des logiciels. De plus, le processus de développement met l'accent sur le besoin d'avoir du code en cours d'exécution à presque tous les points, de sorte que chaque étape majeure se décompose en fait en la fourniture d'une série de versions pouvant être testées et utilisées régulièrement de façon opérationnelle (par l'équipe de développement).


1.2 Présentation du cycle de développement de la sécurité

L'expérience en matière de sécurité des logiciels réels a conduit à un ensemble de principes de haut niveau pour la création de logiciels plus sécurisés. Microsoft a désigné ces principes SD3+C – Secure by Design (sécurisé par conception), Secure by Default (sécurisé par défaut), Secure in Deployment (sécurisé dans le déploiement) et Communications. Les définitions brèves de ces principes sont les suivantes :

  • Sécurisé par conception : l'architecture, la conception et l'implémentation des logiciels doivent protéger ces derniers et les informations qu'ils traitent, et résister aux attaques.

  • Sécurisé par défaut : dans la réalité, un logiciel ne peut prétendre à une sécurité parfaite, c'est pourquoi les concepteurs doivent prendre pour hypothèse que des failles de sécurité seront présentes. Pour réduire les dégâts possibles lorsque des pirates s'attaquent à ces failles résiduelles, l'état par défaut des logiciels doit insister sur la sécurité. Par exemple, un logiciel doit s'exécuter avec le privilège le moins élevé, et les services et fonctions qui ne sont pas strictement nécessaires doivent être désactivés par défaut ou être accessibles uniquement à une petite partie des utilisateurs.

  • Sécurisé dans le déploiement : les outils et une aide doivent accompagner les logiciels pour aider les utilisateurs finaux et/ou les administrateurs à les utiliser de façon sécurisée. En outre, les mises à jour doivent être simples à déployer.

  • Communications : les développeurs de logiciels doivent être préparés à la découverte des failles des produits et doivent communiquer de façon transparente et responsable avec les utilisateurs finaux et/ou les administrateurs pour les aider à prendre des mesures de protection (telles que la mise en œuvre de correctifs ou le déploiement de solutions).

Si chaque élément de SD3+C impose un certain nombre d'exigences sur le processus de développement, les deux premiers éléments—sécurisé par conception et sécurisé par défaut—sont ceux qui contribuent le plus à la sécurité. La règle « sécurisé par conception » impose des processus destinés à éviter l'introduction de failles en premier lieu, tandis que la règle « sécurisé par défaut » implique que l'exposition par défaut du logiciel, sa « surface d'attaque », soit réduite.

L'introduction des mesures de sécurité permettant d'intégrer le modèle SD3+C au processus de développement existant se traduit par l'organisation globale du processus illustrée dans la figure 2.

cliquez pour agrandir
Figure 2. Amélioration SDL du processus de développement de Microsoft (cliquez sur l'image pour l'agrandir)

La section 2 de ce document décrit les composants du SDL à haut niveau. La section 3 présente un bref résumé des spécificités de l'implémentation du SDL par Microsoft. La section 4 de ce document fournit un certain nombre de données explicatives qui montrent que l'application précoce du SDL au cours du développement de Microsoft Windows Server 2003 et d'autres logiciels s'est traduite par un nombre réduit des failles de sécurité et des niveaux moins élevés de gravité de ces failles, comparativement à des versions précédentes de ces logiciels. La section 5 fournit un certain nombre d'observations qualitatives sur des éléments du processus basées sur l'expérience de Microsoft dans l'application du SDL. Enfin, la section 6 présente des conclusions générales.


2. Processus du cycle de développement de la sécurité

Comme indiqué précédemment, la formation des ingénieurs n'entre pas dans le cadre de cet article. Mais il est important de noter qu'un programme de formation est essentiel dans le succès du SDL. Les nouveaux diplômés de l'enseignement supérieur en informatique et dans les disciplines associées n'ont généralement pas la formation nécessaire pour se joindre aux effectifs qui sont prêts et en mesure de concevoir, développer ou tester des logiciels sécurisés. Même ceux qui ont suivi un cursus consacré à la sécurité sont davantage susceptibles d'avoir rencontré des algorithmes de cryptographie ou des modèles de contrôle d'accès que des saturations de tampon ou des failles de canonisation. En général, les concepteurs, ingénieurs et testeurs de logiciels de l'industrie n'ont pas les compétences nécessaires en matière de sécurité.

Dans ces circonstances, une organisation cherchant à développer des logiciels sécurisés doit veiller à ce que ses ingénieurs soient correctement formés. Il existe différentes manières de relever ce défi selon la taille de l'organisation et les ressources disponibles. Une entreprise disposant d'un grand nombre d'ingénieurs sera probablement en mesure de créer un programme interne pour leur fournir une formation continue sur la sécurité, tandis qu'une organisation plus petite devra peut-être faire appel à une structure de formation extérieure. Chez Microsoft, tout le personnel impliqué dans le développement de logiciels doit suivre une formation annuelle d'actualisation des connaissances en matière de sécurité.


2.1 Phase de détermination des besoins

La nécessité de considérer la sécurité dès l'origine est un principe fondamental du développement de systèmes sécurisés. Si un grand nombre de projets de développement produisent des « versions suivantes » bâties sur les produits précédents, la phase de détermination des besoins et de planification initiale d'une nouvelle version offre la meilleure occasion de créer des logiciels sécurisés.

Au cours de la phase de détermination des besoins, l'équipe produit établit le contact avec l'équipe centrale de sécurité pour demander l'affectation d'un conseiller en sécurité (on l'appelle le « monsieur sécurité » dans le cadre de l'implémentation du SDL chez Microsoft) qui sert de point de contact, de ressource et de guide pendant la planification. Le conseiller en sécurité assiste l'équipe produit en révisant les plans, en faisant des recommandations et en veillant à ce que l'équipe de sécurité planifie les ressources appropriées pour tenir le calendrier de l'équipe produit. Le conseiller en sécurité conseille l'équipe produit sur les étapes relatives à la sécurité et sur les critères de sortie qui seront nécessaires selon la taille du projet, sa complexité et les risques encourus. Il reste le point de contact entre l'équipe produit et l'équipe de sécurité depuis le démarrage du projet jusqu'à la conclusion de la révision finale de sécurité et à la diffusion du logiciel. Le conseiller en sécurité sert également de contact entre l'équipe de sécurité et la direction de l'équipe produit, et indique à la direction de l'équipe si l'aspect sécurité du projet est en bonne voie afin d'éviter toute surprise liée à la sécurité survenant tardivement dans le processus.

La phase de détermination des besoins offre l'occasion à l'équipe produit d'envisager de quelle manière la sécurité sera intégrée au processus de développement, d'identifier les principaux objectifs de sécurité et d'optimiser la sécurité des logiciels tout en réduisant les perturbations dans les plannings et les prévisions. Dans le cadre de ce processus, l'équipe doit considérer comment les fonctions de sécurité et les mesures de garantie de son logiciel vont s'intégrer aux autres logiciels susceptibles d'être utilisés conjointement à celui-ci. (L'interfaçage avec d'autres logiciels est un aspect essentiel pour répondre aux besoins des utilisateurs d'intégrer des produits spécifiques dans des systèmes sécurisés.) La perspective globale de l'équipe produit concernant les objectifs, les problèmes et les plannings de sécurité doit se traduire par des documents de planification produits au cours de la phase de détermination des besoins. Si les plans sont susceptibles d'évoluer avec l'avancement du projet, la rédaction précoce de ces plans permet de s'assurer qu'aucun besoin n'a été oublié ni n'émerge à la dernière minute.

Chaque équipe produit doit envisager les besoins en termes de fonctions de sécurité au cours de cette phase. Si certains besoins de fonctions de sécurité peuvent être identifiés par la modélisation des menaces, d'autres seront liés à la demande des clients, et déterminés par l'expression des besoins des utilisateurs. Des besoins de fonctions de sécurité apparaissent également avec la nécessité de respecter les normes industrielles et les processus de certification tels que les « Common Criteria » aux États-Unis. L'équipe produit doit identifier et intégrer ces besoins dans le cadre de son processus normal de planification.


2.2 Phase de conception

La phase de conception identifie les besoins et la structure globale du logiciel. Du point de vue de la sécurité, les principaux éléments de la phase de conception sont les suivants :

  • Définir l'architecture de sécurité et les instructions de conception. Définissez la structure globale du logiciel dans une perspective de sécurité et identifiez les composants dont le fonctionnement correct est essentiel à la sécurité (la « base informatique de confiance »). Identifiez les techniques de conception, telles que la structuration en couches, l'utilisation d'un langage fortement typé, l'application du privilège minimum et la réduction de la surface d'attaque, qui s'appliquent au logiciel dans son ensemble. (La structuration en couches se réfère à l'organisation du logiciel en composants bien définis qui sont structurés de manière à éviter des dépendances circulaires entre composants ; les composants sont organisés en couches et une couche de niveau supérieur peut dépendre des services des couches inférieures, tandis que les couches de niveau inférieur ne peuvent dépendre des couches de niveau plus élevé.) Les particularités des éléments individuels de l'architecture seront abordés dans des spécifications de conception détaillées, mais l'architecture de sécurité considère la conception de la sécurité sous une perspective globale.

  • Documenter les éléments de la surface d'attaque du logiciel. Sachant qu'un logiciel ne peut prétendre à une sécurité parfaite, il est important que seules les fonctions qui seront utilisées par la grande majorité des utilisateurs soient exposées à tous les utilisateurs par défaut, et que celles-ci soient installées avec le niveau de privilège le moins élevé possible. La mesure des éléments de la surface d'attaque permet à l'équipe produit de disposer en permanence d'une évaluation de la sécurité par défaut et de détecter des cas dans lesquels le logiciel est plus vulnérable aux attaques. Si, dans certaines situations, une surface d'attaque accrue peut se justifier par des fonctions améliorées et une meilleure utilisation du produit, il est important de détecter chacune de ces instances et de s'interroger sur leur pertinence au cours de la conception et de l'implémentation afin de livrer le logiciel dans une configuration par défaut aussi sécurisée que possible.

  • Procéder à la modélisation des menaces. L'équipe produit procède à la modélisation des menaces composant par composant. En utilisant une méthodologie structurée, l'équipe en charge du composant identifie les actifs que le logiciel doit gérer et les interfaces par lesquelles ces actifs sont accessibles. Le processus de modélisation des menaces identifie celles qui peuvent nuire à chaque actif et la probabilité de nuisance (une estimation du risque). L'équipe en charge du composant identifie ensuite les dispositions qui atténuent le risque—que ce soit sous la forme de fonctions de sécurité telles que le cryptage ou par adapation du fonctionnement du logiciel afin de protéger les actifs contre ces nuisances. Ainsi, la modélisation des menaces aide l'équipe produit à identifier les besoins en matière de fonctions de sécurité ainsi que les domaines dans lesquels il est nécessaire de procéder à une révision du code et à des tests de sécurité particulièrement rigoureux. Le processus de modélisation des menaces doit être pris en charge par un outil qui capture les modèles de menaces sous une forme lisible par la machine à des fins de stockage et de mise à jour.

  • Définir des critères de livraison supplémentaires. Si les critères de livraison fondamentaux en matière de sécurité doivent être définis au niveau de l'organisation, il se peut que des critères spécifiques à certaines équipes produit ou certaines versions de logiciels doivent être satisfaits avant que les logiciels ne puissent être diffusés. Par exemple, une équipe produit qui développe la mise à jour d'un logiciel déjà livré aux clients et soumis à de nombreuses attaques peut décider que, pour que la nouvelle version puisse être considérée comme prête pour la diffusion, aucune faille ne devra être signalée par des personnes externes pendant une période déterminée. (Cela suppose que le processus de développement ait permis de trouver et supprimer les failles avant qu'elles n'aient été signalées plutôt que de les faire « corriger » par l'équipe produit a posteriori.)


2.3 Phase d'implémentation

Au cours de la phase d'implémentation, l'équipe produit code, teste et intègre le logiciel. Les mesures prises pour supprimer les failles de sécurité ou éviter leur insertion au cours de cette phase sont largement mises à profit—elles réduisent de façon significative la probabilité de retrouver des failles de sécurité dans la version finale du logiciel diffusé aux clients.

Les résultats de la modélisation des menaces donnent des orientations particulièrement importantes au cours de la phase d'implémentation. Les développeurs veillent particulièrement à ce que le code qui atténue les menaces de priorité élevée soit correctement écrit et les testeurs veillent à s'assurer que ces menaces sont effectivement bloquées ou atténuées.

Les éléments du SDL qui s'appliquent à la phase d'implémentation sont les suivants :

  • Application des normes de codage et de test. Les normes de codage aident les développeurs à éviter d'introduire des défauts pouvant se traduire par des failles de sécurité. Par exemple, l'utilisation de fonctions de gestion de chaînes et de gestion des tampons plus cohérentes et plus sûres évite d'introduire des failles de saturation de tampon. Les normes et les recommandations en matière de test permettent de s'assurer que les tests sont axés sur la détection des failles de sécurité potentielles et ne se limitent pas au bon fonctionnement du logiciel.

  • Application d'outils de test de la sécurité y compris des outils aléatoires. Ces outils aléatoires fournissent des entrées structurées mais invalides aux interfaces de programmation d'applications (API) et aux interfaces réseau afin de maximiser la probabilité de détecter des erreurs pouvant se traduire par des failles du logiciel.

  • Application d'outils d'analyse de code statique. Les outils peuvent détecter certains types de défauts qui se traduisent par des failles, tels que les saturations de tampon, les dépassements sur les entiers et les variables non initialisées. Microsoft a investi massivement majeur dans le développement de ces outils (lPREfix et PREfast sont les deux outils utilisés depuis le plus longtemps) et poursuit leur amélioration à mesure que l'on découvre de nouveaux défauts de codage et failles de logiciels.

  • Réalisation de révisions du code. Les révisions du code complètent les outils automatisés et les tests en dirigeant les efforts des développeurs formés vers la révision du code source, ainsi que la détection et la suppression des failles de sécurité potentielles. Elles constituent une étape essentielle du processus de suppression des failles de sécurité des logiciels au cours du processus de développement.


2.4 Phase de vérification

La phase de vérification est l'étape à laquelle le logiciel est fonctionnellement terminé et passe en bêta-test auprès des utilisateurs. Au cours de cette phase, lorsque le logiciel est en bêta-test, l'équipe produit mène une « campagne de sécurité » qui inclut des révisions du code vis-à-vis de la sécurité, qui vont au-delà de ceux réalisés au cours de la phase d'implémentation ainsi que des tests de sécurité ciblés.

Microsoft a introduit les campagnes de sécurité au cours de la phase de vérification de Windows Server 2003 et de plusieurs autres versions de logiciels au début de 2002. Cette introduction se fondait sur deux raisons :

  • Le cycle de vie du logiciel des versions en question avait atteint la phase de vérification et cette phase constituait une étape appropriée pour mener les révisions de code ciblées et les tests requis.

  • Le fait de réaliser la campagne de sécurité au cours de la phase de vérification garantissait que la révision du code et le test ciblaient la version finie du logiciel, et permettait de réviser à la fois le code développé ou mis à jour au cours de la phase d'implémentation et le « code hérité », non modifié.

La première de ces raisons tire ses racines d'un événement purement fortuit : la décision de lancer une campagne de sécurité a été prise initialement au cours de la phase de vérification. Mais Microsoft en a conclu que le fait de mener une campagne de sécurité au cours de la phase de vérification est en fait une méthode pertinente, à la fois pour vérifier que le logiciel final respecte les besoins et pour permettre la révision plus en profondeur du code hérité de versions précédentes.

Il est important de noter que les révisions et le test du code de haute priorité (le code faisant partie de la « surface d'attaque » du logiciel) sont essentiels dans plusieurs phases du SDL. Par exemple, ces révisions et des tests sont nécessaires dans la phase d'implémentation pour permettre la correction précoce de tout problème ainsi que l'identification et la correction de leur source. Ils sont également essentiels dans la phase de vérification, lorsque le produit est proche de son achèvement.


2.5 Phase de diffusion

Au cours de la phase de diffusion, le logiciel doit être soumis à une révision finale de sécurité (« FSR »). La FSR a pour objectif de répondre à une question. « Du point de vue de la sécurité, ce logiciel est-il prêt à être livré à des clients ? » La FSR est menée de deux à six mois avant l'achèvement du logiciel, selon son étendue. L'état du logiciel doit être stable avant d'entreprendre la FSR, quelques changements minimes non relatifs à la sécurité pouvant intervenir avant sa diffusion.

La FSR est une révision indépendante du logiciel conduite par l'équipe centrale de sécurité de l'entreprise. Le conseiller en sécurité de l'équipe de sécurité indique à l'équipe produit l'étendue de la FSR requise par le logiciel et fournit à l'équipe produit la liste des besoins en matière de ressources préalables à la FSR. L'équipe produit fournit à l'équipe de sécurité les ressources et les informations nécessaires pour mener la FSR. La FSR commence par le remplissage d'un questionnaire par l'équipe produit et par un entretien avec un membre de l'équipe de sécurité affecté à la FSR. Toute FSR nécessite la révision des bogues identifiés initialement comme des bogues de sécurité, mais dont une analyse ultérieure a montré qu'ils n'avaient aucun impact sur la sécurité, pour vérifier que l'analyse en question a été faite correctement. Une FSR inclut également un contrôle de la capacité du logiciel de résister à des failles récemment signalées qui ont touché des logiciels similaires. Une FSR menée sur une version majeure d'un logiciel nécessitera un test de pénétration et, éventuellement, le recours à des intervenants externes chargés du contrôle de sécurité pour compléter l'équipe de sécurité.

La FSR ne se limite pas à un exercice de type réussite ou échec, pas plus que l'objectif de la FSR n'est de détecter toutes les failles de sécurité qui resteraient dans le logiciel ; ceci sera sans conteste infaisable. La FSR donne plutôt à l'équipe produit et à la direction générale de l'organisation une image globale de l'état de la sécurité du logiciel et de la probabilité selon laquelle il pourra résister aux attaques lorsqu'il aura été diffusé auprès des clients. Si la FSR détecte un modèle de failles restantes, la réponse correcte ne consiste pas simplement à corriger les failles détectées, mais à reprendre les phases précédentes et de prendre d'autres mesures ciblées pour en corriger les causes (par exemple en améliorant la formation ou les outils).


2.6 Phase de support et de dépannage

Malgré l'application du SDL au cours du développement, les pratiques de développement avancées ne permettent pas encore de livrer des logiciels complètement exempts de failles, et l'on peut raisonnablement penser que cette situation est appelée à perdurer. Même si le processus de développement pouvait éliminer toutes les failles d'un logiciel tel qu'il est lors de la diffusion, de nouvelles attaques verraient le jour et ce logiciel qui avait été « sécurisé » deviendrait vulnérable. Aussi les équipes produit doivent-elles se préparer à répondre à des nouvelles failles dans les logiciels livrés aux clients.

Une partie du processus de réponse suppose de se préparer à évaluer des rapports de faille et à diffuser des conseils de sécurité et des mises à jour lorsque cela s'avère nécessaire. L'autre composante du processus de réponse consiste à pratiquer une analyse post-mortem des failles signalées et à prendre les éventuelles mesures nécessaires. Les mesures destinées à répondre à une faille vont de la diffusion d'une mise à jour en réponse à une erreur isolée à la mise à jour d'outils d'analyse de code et à la réalisation de révisions de code des principaux sous-systèmes. L'objectif lors de la phase de réponse est d'apprendre des erreurs et d'utiliser les informations des rapports sur les failles pour détecter et éliminer les failles ultérieures avant qu'elles ne soient découvertes sur site et ne mettent en péril les clients. Le processus de réponse aide également l'équipe produit et l'équipe de sécurité à adapter les processus afin que d'éviter des erreurs semblables à l'avenir.


3.1 Application obligatoire du SDL

Étant donné les avantages patents du SDL (voir Section 5), Microsoft a pris la décision de formaliser l'obligation d'appliquer le SDL sur une large gamme de logiciels. Au moment de la rédaction de ce document, le SDL devient obligatoire pour tout logiciel qui doit :

  • être utilisé pour traiter des informations personnelles ou sensibles ;

  • être utilisé dans une entreprise ou une autre organisation (université, administration, ou milieu associatif) ;

  • être connecté sur Internet ou utilisé dans un environnement réseau.

Les logiciels auxquels cette obligation ne s'applique pas incluent les applications autonomes qui ne correspondent pas aux critères ci-dessus (par exemple, les jeux pour les très jeunes enfants tels que la série « The Magic School Bus »). Le SDL interdit à ces logiciels d'interférer avec la sécurité de la plate-forme (système d'exploitation ou autre logiciel) sur laquelle ils fonctionnent.


3.2 Formation obligatoire

Un aspect capital des campagnes de sécurité du début de l'année 2002 a été la formation à l'échelle de l'équipe de tous les développeurs, testeurs, directeurs de programme et personnel de documentation. Microsoft a formalisé l'obligation d'une formation annuelle à la sécurité des ingénieurs dans les organisations dont les logiciels ont été soumis au SDL. La nécessité d'une remise à niveau annuelle repose sur le fait que la sécurité n'est pas un domaine statique : les menaces, les attaques et les défenses évoluent. Il en résulte que même des ingénieurs qui se sont montrés parfaitement compétents et qualifiés concernant la sécurité de leurs logiciels doivent suivre une formation supplémentaire à mesure que le paysage des menaces évolue. Par exemple, l'importance des failles de dépassement sur les entiers s'est considérablement accrue au cours des quatre dernières années, et il a été démontré récemment que certains algorithmes de cryptographie présentent des failles que l'on n'avait pas détectées auparavant.

Microsoft a développé une introduction et une mise à niveau sur la sécurité proposée aux ingénieurs sous forme de formation en salle et de support numérique. Ce cours a servi de base pour établir des formations spécialisées par technologie logicielle et par rôle d'ingénieur. Microsoft est en train de créer un programme de formation à la sécurité qui déclinera des spécialisations par technologie, rôle et niveau d'expérience des stagiaires.

Un grand nombre de partenaires et de clients Microsoft nous ont interrogés sur la disponibilité de la formation et des processus Microsoft relatifs à la sécurité. Microsoft Press a publié des ouvrages basés sur les pratiques internes de Microsoft en matière de conception sécurisée, de codage et de modélisation des menaces, et Microsoft Learning propose des cours basés sur les pratiques internes de Microsoft.


3.3 Mesure pour les équipes produits

Comme entreprise, Microsoft respecte l'adage « on ne peut gérer ce que l'on ne mesure pas ». S'il est très difficile d'identifier les paramètres permettant d'évaluer de façon fiable la sécurité des logiciels, il existe de toute évidence des éléments de mesure qui, « par procuration », permettent de rendre compte de cette sécurité. Ces mesures vont de l'analyse de la formation du personnel d'ingénierie (au début du cycle de développement) au taux de failles découvertes dans les logiciels diffusés aux clients.

Microsoft a identifié un ensemble de mesures de la sécurité utilisables par les équipes produit pour surveiller le succès de leur implémentation du SDL. Ces mesures concernent l'implémentation du SDL par l'équipe, de la modélisation des menaces jusqu'à la révision du code et aux tests de sécurité du logiciel présenté à la FSR. Avec l'implémentation de ces mesures, les équipes peuvent suivre leurs propres performances (amélioration, stabilité ou détérioration) ainsi que leurs performances comparativement aux autres équipes. Les mesures agrégées font l'objet de rapports réguliers à la direction de l'équipe produit et à la direction générale de Microsoft.


3.4 L'équipe de sécurité centrale

Bien avant les campagnes de sécurité de 2002, Microsoft avait établi l'équipe Secure Windows Initiative (« SWI ») chargée d'améliorer la sécurité des logiciels et de réduire les failles de Windows, mais aussi de fournir une assistance en matière de sécurité aux équipes des produits autres que Windows. L'équipe SWI a joué un rôle central dans l'organisation et la gestion de la campagne de sécurité de Windows Server 2003, et a fourni une assistance en formation et en conseil pour toutes les campagnes de sécurité menés à partir de 2002. L'équipe SWI a également été la première à conduire le processus de la FSR, pour Windows Server 2003.

Avec le lancement formel du SDL, l'équipe SWI a joué le rôle d'équipe centrale de sécurité pour Microsoft. Les responsabilités de l'équipe SWI sont les suivantes :

  • Développement, maintenance et amélioration du SDL, y compris la définition des aspects obligatoires du processus.

  • Développement, amélioration et fourniture de la formation d'ingénieur.

  • Mise à disposition de « conseillers en sécurité » qui guident les équipes produit dans le processus, conduisent des révisions pour les équipes produit et assurent que leurs questions reçoivent en temps voulu des réponses précises faisant autorité.

  • Servir d'experts du domaine concerné sur un grand nombre de sujets relatifs à la sécurité, en veillant à ce que les questions destinées aux conseillers en sécurité reçoivent en temps voulu des réponses précises.

  • Exécution des révisions finales de sécurité avant la diffusion du logiciel.

  • Investigation technique des failles signalées dans les logiciels diffusés auprès des clients, pour s'assurer que les causes ont été bien comprises et que le niveau de réponse approprié est engagé.

La disponibilité et l'efficacité de l'équipe SWI se sont révélées être des facteurs clés dans l'implémentation du SDL chez Microsoft. Microsoft s'est fixé pour objectif de mettre en place un processus évolutif pour développer des logiciels plus sécurisés, et cet objectif implique que les compétences en matière de sécurité soient largement réparties dans toutes les équipes produit. Toutefois, le fait de disposer d'une équipe centrale de sécurité hautement qualifiée est essentiel pour permettre aux équipes produit de l'entreprise d'atteindre le régime voulu et les soutenir dans leurs efforts pour créer des logiciels plus sécurisés. Elle permet également de garantir qu'une personne extérieure à l'équipe produit mène la FSR.


4. Résultats de l'implémentation du cycle de développement de la sécurité chez Microsoft

S'il est prématuré pour Microsoft de tirer la conclusion hâtive que le SDL améliore la sécurité de ses logiciels, les résultats obtenus à ce jour sont encourageants.

Windows Server 2003 a été la première version de système d'exploitation de Microsoft dans laquelle a été implémentée une grande partie du SDL. La figure 3 montre le nombre de bulletins de sécurité émis dans l'année qui a suivi la diffusion des deux systèmes d'exploitation serveur de Microsoft les plus récents : Windows 2000 et Windows Server 2003. (Lorsque Windows 2000 a été diffusé, Microsoft ne disposait pas de système d'évaluation formel de la gravité des bulletins de sécurité. Microsoft a évalué chaque bulletin de sécurité qui s'applique à Windows 2000 par rapport à son système d'évaluation actuel de la gravité.) Comme nous l'avons vu précédemment, Windows Server 2003 a été développé avec la plupart des processus SDL ( (mais pas tous) ; Windows 2000 n'a pas été développé avec ces processus.

Figure 3. Bulletins de sécurité critiques et importants de Windows avant et après le SDL
Figure 3. Bulletins de sécurité critiques et importants de Windows avant et après le SDL

Les classes de gravité sont définies à l'adresse http://www.microsoft.com/technet/security/bulletin/rating.mspx site en anglais

D'autres versions de logiciels Microsoft ont également bénéficié d'éléments du SDL. Les équipes produit SQL Server et Exchange Server ont mené chacune une campagne de sécurité (incluant la modélisation des menaces, les révisions de code, et les tests de sécurité) avant de diffuser un service pack—version de logiciel qui regroupe des correctifs pour contrer les failles de sécurité et résoudre d'autres problèmes. Les résultats de la campagne de sécurité SQL Server ont été intégrés à SQL Server 2000 Service Pack 3, et les résultats de la campagne de sécurité Exchange Server ont été intégrés à Exchange 2000 Server Service Pack 3. Les figures 4 et 5 montrent le nombre de bulletins de sécurité diffusés sur des périodes équivalentes avant et après la diffusion de chaque service pack (une période de 24 mois pour SQL Server 2000 et de 18 mois pour Exchange 2000 Server).

Figure 4. Bulletins de sécurité SQL Server 2000 avant et après le SDL
Figure 4. Bulletins de sécurité SQL Server 2000 avant et après le SDL

Figure 5. Bulletins de sécurité Exchange Server 2000 avant et après le SDL
Figure 5. Bulletins de sécurité Exchange Server 2000 avant et après le SDL

Un autre exemple encourageant est le composant Internet Information Server de Windows Server 2003 (IIS 6) ; dans les deux ans qui ont suivi sa diffusion, Microsoft a émis un bulletin de sécurité concernant le serveur Web, et il s'agissait d'un composant (WebDAV) qui n'est pas installé par défaut.

Si les échantillons de failles de sécurité sont encore de petite taille et si les périodes sont limitées, ces résultats mettent en évidence l'efficacité du SDL. Microsoft continuera de surveiller les taux de failles dans Windows Server 2003 et dans les service packs d'Exchange Server et de SQL Server pour vérifier si ces tendances initiales se confirment. Microsoft analysera également d'autres logiciels de la société à mesure que de nouvelles versions seront livrées après l'implémentation complète du CDVS afin de déterminer si le nombre et la gravité des failles continue de chuter.


5. Observations concernant l'application du cycle de développement de la sécurité

Les informations de la section précédente ont montré ce que le SDL est supposé accomplir (« quoi » . Cette section tente de répondre à certaines questions concernant le « comment » du fonctionnement du processus. Si la section précédente est basée sur des chiffres précis—Microsoft surveille rigoureusement les rapports des failles et les bulletins de sécurité—cette section est basée sur des données isolées sous la forme d'observations et d'opinions des membres de l'équipe SWI.


5.1 Efficacité des éléments du SDL

Le SDL se compose d'un grand nombre de sous-processus répartis dans l'ensemble du cycle de développement logiciel. Il a été demandé à l'équipe de hiérarchiser ces sous-processus en termes d'efficacité : ceux qui sont les plus efficaces, ce qui a été tenté et s'est avéré moins efficace.

Le consensus qui ressort au sein de l'équipe SWI est que la modélisation des menaces est le composant du SDL qui a la priorité la plus élevée. Bien entendu, elle n'est pas appliquée isolément : elle a une incidence sur la conception, la révision du code et les tests, et un processus qui aurait implémenté uniquement la modélisation des menaces sans prendre de mesures en réponse aux modèles (en n'ayant pas testé l'efficacité des corrections par exemple) n'aurait aucune efficacité. Des statistiques sous la forme de comptage de bogues tendent à sous-évaluer le rôle de la modélisation des menaces car une grande partie de ce rôle consiste à empêcher la création de bogue conduisant à des failles de sécurité. Toutefois, le rôle de la modélisation des menaces dans la focalisation du processus de développement de logiciels sécurisés est si essentiel qu'il se place clairement en tête de liste.

Le SDL demeure un processus relativement nouveau chez Microsoft, c'est pourquoi il n'existe pour l'instant pas de cas où un composant du processus a été supprimé. Cependant une conclusion s'imposera sans surprise aux chercheurs en sécurité sur le long terme : les tests de pénétration ne constituent pas la voie vers la sécurité. Les tests de pénétration sont un élément de la révision finale de sécurité (FSR) d'une version majeure d'un logiciel, mais les activités de l'équipe produit dans l'ensemble du cycle de vie se concentrent sur la modélisation des menaces, les révisions de code, l'utilisation d'outils automatisés, et les tests aléatoires plutôt que sur les tests de pénétration. Ces dernières mesures sont beaucoup plus complètes pour éviter ou supprimer des bogues de sécurité que les tests de pénétration ad hoc classiques. L'élément de test de pénétration de la FSR aide à déterminer si le logiciel est prêt pour la diffusion plutôt qu'il ne constitue un moyen de rechercher et de corriger les bogues de sécurité. Si le test de pénétration de la FSR révèle un grand nombre de bogues de sécurité, c'est que les phases antérieures n'ont pas été suffisamment efficaces et la réponse correcte consiste à reprendre les activités supposées terminées de ces phases plutôt que de se contenter de corriger les bogues du test de pénétration et de diffuser le logiciel.


5.2 Outils, tests et révision du code

Les outils d'analyse statique, des tests aléatoires et la révision du code sont complémentaires. Microsoft a fortement investi dans des outils d'analyse de code statique, et leur utilisation fait partie intégrante du SDL. Ces outils sont efficaces pour rechercher un grand nombre d'erreurs de codage pouvant se traduire par des failles de sécurité, en particulier les saturations de tampon. Toutefois, les outils avancés actuels ne détectent pas toutes les erreurs. Des révisions de code manuelles sont toujours requises par le SDL, que ce soit pour détecter les erreurs que les outils ne trouvent pas ou pour identifier des possibilités d'amélioration de ces outils. L'article Microsoft Developer Network (MSDN) de Michael Howard cité dans les références présente l'approche générale de la conduite des révisions de sécurité enseignée par Microsoft à ses ingénieurs.

L'accent mis sur les tests aléatoires est un ajout relativement récent au SDL, mais les résultats à ce jour sont très encourageants. Contrairement aux outils d'analyse de code statique, les outils de test aléatoire doivent être créés (ou au moins configurés) pour chaque format de fichier et/ou protocole réseau à tester ; de ce fait, ils peuvent souvent détecter des erreurs qui ont échappé aux outils d'analyse de code statique. Les modèles de menaces aident les équipes produit à hiérarchiser les interfaces et les formats pour les tests. Les résultats des tests aléatoires ne sont pas totalement déterministes (les outils sont exécutés pendant un nombre fini de cycles et ne garantissent pas de détecter tous les bogues) mais l'expérience a montré qu'un niveau raisonnable de tests aléatoires permet de détecter des bogues « intéressants » qui pourraient être utilisés comme des failles de sécurité.


5.3 Investissements

La formation obligatoire à la sécurité constitue un investissement significatif pour une entreprise qui compte un nombre d'ingénieurs comparable à celui de Microsoft. La formation est dispensée par une combinaison de cours en salle (par des formateurs) et de matériel en ligne. Le matériel en ligne est particulièrement intéressant comme vecteur de formation pour les petites équipes d'ingénierie se trouvant sur les sites distants du siège de Microsoft. La formation en salle s'est révélée particulièrement efficace lorsqu'elle était dispensée à l'échelle d'une équipe pour celles qui se préparent à des campagnes de sécurité ou à d'autres activités clé. Dans ce cas, l'expérience de Microsoft montre que la formation de l'équipe résulte non seulement de la formation en classe, mais également de la réalisation de la campagne de sécurité. La formation à la sécurité (généralement une demi-journée) est amplifiée par le fait que chacun dans le groupe de travail est orienté sur la sécurité.

L'équipe centrale de sécurité (équipe SWI) s'est développée de façon significative au cours des dernières années à mesure de Microsoft a mis l'accent sur la sécurité. De par sa conception, l'équipe est petite relativement au nombre total d'ingénieurs de Microsoft et met l'accent sur une approche échelonnée qui garantit que la responsabilité et les ressources permettant de produire des logiciels plus sécurisés restent entre les mains des équipes produit. D'un point de vue tactique, ce mode de fonctionnement se traduit par l'accent mis sur la formation et sur les outils, la mise à disposition de conseillers en sécurité qui aident l'équipe produit à résoudre ses propres problèmes (plutôt que de les résoudre à sa place) et le recours aux révisions (notamment la FSR) pour fournir à l'équipe produit des commentaires sur l'état de préparation du logiciel avant sa diffusion.


5.4 Résultats

L'épreuve finale pour le SDL est de savoir jusqu'à quel point il supprime et atténue les failles des logiciels Microsoft. L'expérience—résumée à la section 4—montre que le SDL réussit cette épreuve. Microsoft évalue également les failles signalées en externe en termes d'effet sur les versions des logiciels en développement. Une expérience récente a montré que, dans un nombre croissant de cas, les mesures de sécurité prévues ou implémentées dans de nouvelles versions bloquent les attaques qui s'étaient révélées efficaces contre des versions antérieures. La version récente de Windows XP Service Pack 2 a été révisée dans ce sens et il s'est avéré que des changements de sécurité qui avaient été prévus sans être encore implémentés ou discutés publiquement éliminaient un nombre significatif de failles signalées sur des versions précédentes de Windows par des chercheurs en sécurité externes à Microsoft.


6. Conclusions

L'expérience de Microsoft indique que le SDL est efficace pour réduire l'incidence des failles de sécurité. L'implémentation initiale du SDL (dans Windows Server 2003, SQL Server 2000 Service Pack 3, ainsi qu'Exchange 2000 Server Service Pack 3) s'est traduite par des améliorations significatives de la sécurité des logiciels et les versions ultérieures, intégrant les améliorations apportées au SDL, mettent en évidence de nouvelles améliorations en matière de sécurité des logiciels.

L'implémentation incrémentielle des éléments qui composent le SDL a entraîné des améliorations progressives, ce qui nous semble être le signe d'un processus efficace. Ce processus n'est pas parfait, il continue d'évoluer et il est peu probable qu'il atteigne la perfection ou cesse d'évoluer dans un avenir prévisible.

Le développement et l'implémentation du SDL représentent un investissement majeur pour Microsoft et un changement essentiel dans la manière dont les logiciels sont conçus, développés et testés. Compte tenu de l'importance croissance qu'occupent les logiciels dans notre société, il est indispensable pour Microsoft et l'industrie dans son ensemble de continuer à améliorer leur sécurité ; c'est pourquoi cet article consacré au SDL et des ouvrages consacrés à des techniques spécifiques (consultez les références) ont été publiés afin de partager l'expérience de Microsoft avec l'industrie du logiciel.


7. Remerciements

L'élaboration initiale de cet article remonte à la fin de 2002 ; il traduit l'effort conjoint des auteurs présents. Des ébauches ont été mises à jour à mesure de l'évolution du SDL et la version actuelle a été préparée au cours de l'été et de l'automne 2004. Les auteurs tiennent à remercier Matt Thomlinson, Matt Lyons, Jamil Villani et Eric Bidstrup (toute l'équipe Microsoft Secure Windows Initiative) pour leurs contributions dans la définition et l'amélioration du SDL. Outre les collaborateurs nommés, Scott Charney et Phil Reitinger de Microsoft, ainsi que Jeannette Wing de Carnegie Mellon University ont apporté des commentaires particulièrement utiles sur les projets d'article. Les auteurs tiennent à remercier Martin Abadi, Virgil Gligor, Dick Kemmerer, Chris Mitchell, Fred Schneider, Neeraj Suri, et James Whittaker pour leurs commentaires et leurs suggestions concernant cet article.


8. Références

Mundie, Craig, Trustworthy Computing White Paper

Howard, Michael, Attack Surface: Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users, MSDN Magazine, novembre 2004

Howard, Michael, Expert Tips for Finding Security Defects in Your Code, MSDN Magazine, novembre 2003

Howard, Michael et David LeBlanc, Writing Secure Code, seconde édition, Microsoft Press, Redmond, Washington, 2003

Swiderski, Frank et Window Snyder, Threat Modeling, Microsoft Press, Redmond Washington, 2004


9. Avertissements

Les informations contenues dans ce document représentent le point de vue actuel de Microsoft Corporation sur les questions traitées, à la date de publication. Dans la mesure où Microsoft doit s'adapter aux conditions fluctuantes du marché, ces informations ne doivent pas être considérées comme un engagement de la part de Microsoft ; pour sa part, Microsoft ne peut en garantir la validité après la date de publication.

Ce livre blanc est fourni à titre d'information uniquement. DANS CE DOCUMENT, MICROSOFT NE DONNE AUCUNE GARANTIE, EXPRESSE OU IMPLICITE.

L'utilisateur est tenu d'observer la réglementation relative aux droits d'auteur applicable dans son pays. Sans limitation des droits issus des droits d'auteur, aucune partie de ce manuel ne peut être reproduite, stockée ou incluse dans un système de récupération de données ou transmise à quelque fin ou par quelque moyen que ce soit (électronique, mécanique, photocopie, enregistrement ou autre) sans la permission expresse et écrite de Microsoft Corporation.

Microsoft peut détenir des brevets, avoir déposé des demandes d'enregistrement de brevets ou être titulaire de marques, droits d'auteur ou autres droits de propriété intellectuelle portant sur tout ou partie des éléments qui font l'objet du présent document. Sauf stipulation expresse contraire d'un contrat de licence écrit de Microsoft, la fourniture de ce document n'a pas pour effet de vous concéder une licence sur ces brevets, marques, droits d'auteur ou autres droits de propriété intellectuelle.

© 2005 Microsoft Corporation. Tous droits réservés. Certaines parties de ce livre blanc sont protégés par copyright par © 2004 Institute of Electrical and Electronics Engineers, Incorporated. Tous droits réservés.

Microsoft, MSDN, Windows et Windows Server sont des marques déposées ou des appellations commerciales de Microsoft Corporation aux États-Unis et/ou dans d'autres pays.


Afficher: