Informatique de Confiance : Cycle de Développement Sécurisé (SDL)
Résumé :
Cet article traite du cycle de développement sécurisé de l'Informatique de Confiance (ou SDL pour « Trustworthy Computing Security Development Lifecycle »), processus adopté par Microsoft dans le cadre du développement de logiciels susceptibles de subir des attaques malveillantes. Ce processus consiste à ajouter une série d'activités et de tâches relatives à la sécurité à chacune des phases du processus de développement des logiciels Microsoft. Ces activités et tâches comprennent l'élaboration de modèles de menace au cours de la conception des logiciels, l'utilisation d'outils d'analyse statique de code lors de leur implémentation et l'exécution de révisions de code et de tests de sécurité pendant une période dédiée à la sécurité. Avant que les logiciels sujets au SDL puissent être diffusés, ils doivent subir un examen de sécurité final effectué par une équipe indépendante de son groupe de développement. Pour les logiciels soumis au SDL, beaucoup moins de vulnérabilités sont découvertes de façon externe à Microsoft que pour ceux qui n'y ont pas été soumis. Cet article décrit le SDL et analyse son implémentation sur les logiciels Microsoft. (19 pages)
Remarque:
Cet article est une mise à jour de l'article « Informatique de Confiance : Cycle de Développement Sécurisé » initialement présenté en décembre 2004 lors de la conférence annuelle sur les applications de sécurité informatique (Annual Computer Security Applications Conference) soutenue par l'IEEE qui s'est tenue à Tucson en Arizona.
Sur cette page
1. Introduction
Les éditeurs de logiciels doivent impérativement se préoccuper des menaces de sécurité. La sécurité est une condition requise essentielle pour les éditeurs de logiciels, définie par les tendances du marché, la nécessité de protéger les infrastructures critiques et le besoin d'établir et de préserver une confiance largement répandue dans l'informatique. L'un des plus grands défis de l'ensemble des éditeurs de logiciels consiste à créer des logiciels mieux sécurisés nécessitant moins de mises à jour via des correctifs et une gestion de la sécurité moins pesante.
Pour l'industrie logicielle, la meilleure façon de satisfaire les exigences d'amélioration de la sécurité actuelles consiste à implémenter des processus répétitifs permettant d'obtenir et de mesurer de façon fiable l'amélioration de la sécurité. Par conséquent, les éditeurs de logiciels doivent passer à un processus de développement de logiciels plus strict, c'est-à-dire centré sur la sécurité. Un tel processus a pour but de réduire le nombre de vulnérabilités existantes en matière de sécurité dans la conception, le codage et la documentation et de détecter et supprimer ces failles le plus tôt possible au cours du cycle de développement. La nécessité d'un tel processus est d'autant plus grande pour les logiciels destinés aux entreprises et aux particuliers, susceptibles de traiter des données en provenance d'Internet, de contrôler des systèmes critiques exposés aux attaques ou de traiter des informations permettant d'identifier des personnes.
L'élaboration de logiciels à la sécurité renforcée repose sur trois aspects : un processus répétitif, la formation des développeurs, ainsi que des éléments de mesure et de transparence. Ce document est centré sur l'aspect répétitif du processus du SDL, bien qu'il aborde également la formation des développeurs et fournisse des éléments de mesure globaux montrant l'impact à ce jour de l'application d'un sous-ensemble du SDL.
Si l'expérience de Microsoft constitue une indication, l'adoption du SDL par d'autres entreprises ne doit pas accroitre excessivement les coûts du développement de logiciels. D'après l'expérience de Microsoft, les avantages procurés par des logiciels mieux sécurisés (par exemple, moins de correctifs, plus de satisfaction client) l'emportent sur ces coûts additionnels.
Le SDL implique la modification des processus des entreprises éditrices de logiciels grâce à l'intégration de mesures permettant d'améliorer la sécurité des logiciels. Ce document énumère ces mesures et décrit la façon dont elles s'intègrent dans le cycle de développement de logiciels type. L'objectif de ces modifications ne consiste pas à réviser totalement le processus, mais à ajouter des points de contrôle de sécurité bien définis et des tâches relatives à la sécurité.
Ce document part du principe qu'il existe un groupe central au sein de l'entreprise (ou de l'éditeur de logiciels) gérant le développement et l'évolution des pratiques de sécurité recommandées et les améliorations des processus, constituant une source d'expertise pour l'entreprise en général et chargé d'effectuer une révision (la révision de sécurité finale ou FSR, « Final Security Review ») avant le lancement du logiciel. D'après l'expérience de Microsoft, l'existence d'une telle organisation préside à la réussite de l'implémentation du SDL, ainsi qu'à l'amélioration de la sécurité des logiciels. Cependant, certaines entreprises peuvent recourir à un sous-traitant ou à un consultant pour jouer le rôle d'« équipe de sécurité centrale ». Cet article décrit l'intégration d'un ensemble d'étapes destinées à améliorer la sécurité logicielle au sein du processus de développement de logiciels généralement utilisé par les entreprises éditrices de logiciels. Ces étapes ont été conçues et implémentées par Microsoft dans le cadre de son projet TCI (Trustworthy Computing Initiative). Les améliorations apportées à ce processus visent à réduire la quantité et la gravité des vulnérabilités de sécurité des logiciels utilisés par les clients. Dans ce document, le processus de développement de logiciels modifié, actuellement implémenté chez Microsoft, est appelé « Informatique de Confiance : Cycle de Développement Sécurisé », ou SDL.
Selon l'expérience de Microsoft, l'équipe de sécurité doit se tenir disponible car elle est fréquemment sollicitée au cours de la conception et du développement du logiciel. L'équipe doit également savoir préserver la confidentialité de données commerciales et techniques sensibles. Pour ces raisons, il est préférable de créer une équipe de sécurité au sein de l'entreprise éditrice de logiciels (bien qu'il semble parfois plus approprié de recourir à des consultants pour constituer une équipe et en former ses membres).
1.1 Processus de base
Le processus de développement de logiciels généralement admis chez Microsoft suit approximativement le schéma représenté à la figure 1. À un niveau élevé, ce processus correspond typiquement à ce qui se pratique dans le secteur.
Bien que la figure 1 présente cinq étapes et semble indiquer un processus de développement en « cascade », il s'agit en fait d'un processus en spirale. Les exigences et la conception sont souvent reconsidérées lors de l'implémentation, en réponse aux besoins variables du marché et aux réalités apparues lors de l'implémentation du logiciel. De plus, le processus de développement insiste sur la nécessité de l'exécution d'un code pratiquement à chaque phase. Par conséquent, chaque étape principale est en fait divisée en une série de versions pouvant être constamment testées et utilisées de manière fonctionnelle (par l'équipe de développement).
1.2 Présentation du SDL
L'expérience de la sécurité des logiciels existants a engendré un ensemble de principes de haut niveau à respecter afin d'élaborer des logiciels plus sécurisés. Microsoft appelle ces principes les « SD3+C » : Secure by Design (sécurisation par conception), Secure by Default (sécurisation par défaut), Secure in Deployment (sécurisation dans le déploiement) et Communications. Voici de courtes définitions de ces principes :
| • | Sécurisation par conception : le logiciel doit être structuré, conçu et implémenté de manière à assurer sa propre protection, ainsi que celle des informations traitées, et à résister aux attaques. |
| • | Sécurisation par défaut : dans le monde réel, un logiciel ne sera jamais parfaitement sécurisé. Les concepteurs doivent donc partir du principe qu'il existe des vulnérabilités de sécurité. Afin de minimiser les dommages causés par les pirates qui parviennent à cibler ces vulnérabilités, l'état du logiciel par défaut doit favoriser la sécurité. Par exemple, le logiciel doit fonctionner avec le moins de privilèges possible et les services et fonctions qui ne sont pas utiles à la majorité des utilisateurs doivent être désactivés par défaut ou accessibles uniquement à un petit nombre d'entre eux. |
| • | Sécurisation dans le déploiement : le logiciel doit être livré avec des outils et des instructions destinés à aider les utilisateurs finaux et/ou les administrateurs à l'exploiter en toute sécurité. En outre, les mises à jour doivent être faciles à déployer |
| • | Communications : les développeurs du logiciel doivent être prêts à découvrir les vulnérabilités du produit et doivent communiquer de façon ouverte et responsable avec les utilisateurs finaux et/ou les administrateurs afin de les aider à prendre des mesures de protection (telles que l'installation de correctifs ou le déploiement de solutions de contournement). |
S'il est vrai que chaque élément de SD3+C impose des exigences au niveau du processus de développement, seuls les deux premiers éléments (sécurisation par conception et sécurisation par défaut) sont les plus avantageux en matière de sécurité. La sécurisation par conception utilise des processus permettant d'empêcher l'introduction de vulnérabilités, tandis que la sécurisation par défaut implique la minimisation de la zone d'exposition par défaut du logiciel (ou « surface d'attaque »).
En introduisant les mesures de sécurité visant à intégrer le paradigme SD3+C dans le processus de développement existant, on obtient l'organisation de processus globale représentée par la figure 2.
2. Le processus SDL
Comme indiqué précédemment, la formation des développeurs n'est pas l'objet de cet article. Cependant, il est important de noter qu'un programme de formation est primordial pour la réussite du SDL. Les jeunes diplômés en informatique et issus de disciplines connexes n'ont généralement pas bénéficié d'une formation leur permettant de s'intégrer immédiatement au personnel afin de concevoir, développer et tester des logiciels sécurisés. Même ceux ayant obtenu un module en sécurité auront plus probablement rencontré des algorithmes cryptographiques ou des modèles de contrôle d'accès que des problèmes liés à la saturation de la mémoire tampon ou à la canonicalisation. En général, les concepteurs, ingénieurs et testeurs de logiciels du secteur ne disposent pas des compétences appropriées en matière de sécurité.
Dans de telles circonstances, une entreprise qui cherche à développer un logiciel sécurisé doit tout mettre en œuvre pour former convenablement son personnel technique. En fonction de la taille de l'entreprise et des ressources disponibles, il existe des méthodes spécifiques permettant de relever ce défi. Une entreprise au personnel technique important peut s'engager à élaborer un programme interne afin de dispenser à ses techniciens une formation constante en matière de sécurité, tandis qu'une entreprise plus petite peut recourir à des formations externes. Chez Microsoft, l'ensemble du personnel impliqué dans le développement de logiciels doit suivre une formation de rappel annuelle sur la sécurité.
2.1 Phase de définition des exigences
La nécessité de prendre en compte la sécurité sur l'ensemble du processus constitue le principe fondamental du développement de systèmes sécurisés. Tandis qu'un grand nombre de projets de développement produisent des « versions suivantes » élaborées à partir de versions précédentes, la phase de définition des exigences et de planification initiale d'une nouvelle version offre l'occasion idéale d'élaborer un logiciel sécurisé.
Au cours de la phase de définition des exigences, l'équipe produit contacte l'équipe de sécurité centrale afin qu'elle lui attribue un conseiller en sécurité (appelé le « compagnon de sécurité » dans l'implémentation du SDL chez Microsoft) faisant office d'interlocuteur, de ressource et de guide tout au long de la planification du processus. Le conseiller en sécurité assiste l'équipe produit en examinant les plans, en formulant des recommandations et en s'assurant que l'équipe de sécurité prévoit les ressources adéquates pour prendre en charge le programme de l'équipe produit. Le conseiller en sécurité guide l'équipe produit dans chaque étape de sécurité et pour les critères de sortie requis en fonction de la taille du projet, de sa complexité et des risques encourus. Le conseiller en sécurité reste l'intermédiaire entre l'équipe produit et l'équipe de sécurité du début du projet jusqu'à la fin de la révision de sécurité finale et le lancement du logiciel. Le conseiller en sécurité assure également la communication entre l'équipe de sécurité et les responsables de l'équipe produit et avertit ces derniers de l'état de l'aspect sécuritaire du projet afin d'éviter toute surprise relative à la sécurité en fin de processus.
La phase de définition des exigences représente l'occasion pour l'équipe produit de réfléchir à la façon dont la sécurité sera intégrée dans le processus de développement, d'identifier les objectifs de sécurité fondamentaux, ainsi que d'optimiser la sécurité du logiciel tout en minimisant les interruptions au niveau de la planification et du calendrier. Dans le cadre de ce processus, l'équipe a besoin de réfléchir à la manière dont les fonctions de sécurité et les mesures d'assurance de son logiciel vont s'intégrer à d'autres logiciels susceptibles d'être utilisés en combinaison avec son logiciel (L'interaction avec d'autres logiciels est un aspect crucial à prendre en compte afin de satisfaire les besoins des utilisateurs d'intégrer des produits individuels dans des systèmes sécurisés). L'approche générale de l'équipe produit relative aux objectifs, aux défis et aux planifications en matière de sécurité doit se refléter dans les documents de planification élaborés lors de la phase d'exigences. Les planifications étant susceptibles d'être modifiées à tout moment, une définition de ces plans en début de projet permet qu'aucune exigence ne soit négligée ou évoquée à la dernière minute.
Chaque équipe produit doit prendre en compte les exigences des fonctions de sécurité en tant que partie intégrante de cette phase. Tandis que certaines exigences en matière de fonctions de sécurité sont identifiées en réponse à la modélisation des menaces, les exigences de l'utilisateur sont susceptibles d'imposer l'introduction de fonctions de sécurité pour répondre à la demande des clients. Le besoin de compatibilité avec les normes industrielles et les processus de certification tels que celui de Common Criteria influent sur les exigences en matière de fonctions de sécurité. L'équipe produit doit reconnaître et répercuter ces exigences dans le cadre de son processus de planification normal.
2.2 Phase de conception
| • | Définir les directives de conception et d'architecture en matière de sécurité. Définir la structure générale du logiciel du point de vue de la sécurité et identifier les composants dont le fonctionnement correct est essentiel à la sécurité (la « base informatique fiable »). Identifier les techniques de conception, telles que la superposition, l'utilisation d'un langage fortement typé, l'application du moindre privilège et la réduction au minimum de la surface d'attaque, qui s'appliquent au logiciel de façon générale. La superposition désigne l'organisation du logiciel en composants bien définis structurés de manière à éviter les dépendances circulaires parmi les composants (Les composants sont organisés en couches et une couche supérieure peut dépendre des services des couches inférieures, tandis que les couches inférieures ne sont pas autorisées à dépendre des couches supérieures). Les spécificités de chaque élément de l'architecture seront détaillées dans chaque spécification de conception, mais l'architecture de sécurité détermine une perspective globale de la conception de la sécurité. |
| • | Répertorier les éléments présents dans la surface d'attaque du logiciel. Dans la mesure où le logiciel n'atteindra pas un niveau de sécurité parfait, il est important que seules les fonctions qui seront utilisées par la vaste majorité des utilisateurs soient accessibles par défaut à tous les utilisateurs et que ces fonctions soient installées avec le niveau de privilège le plus bas possible. Évaluer le nombre d'éléments présents dans la surface d'attaque permet à l'équipe produit de disposer d'un élément de mesure constant de la sécurité par défaut et de détecter les instances au niveau desquelles le logiciel a le plus de chance d'être attaqué. Certaines instances amplifiant la surface d'attaque peuvent se justifier par l'amélioration d'une fonction ou d'une exploitation du produit, mais il est important de détecter et de remettre en question chacune de ces instances lors de la conception et de l'implémentation afin de délivrer un logiciel dont la configuration par défaut est aussi sécurisée que possible. |
| • | Effectuer une modélisation des menaces. L'équipe produit effectue une modélisation des menaces au niveau de chaque composant. À l'aide d'une méthodologie structurée, l'équipe chargée des composants identifie les ressources gérées par le logiciel et les interfaces permettant d'y accéder. Le processus de modélisation identifie les menaces pouvant endommager chaque ressource et la probabilité d'entraînement de dommages (évaluation du risque). L'équipe des composants détermine alors des contre-mesures limitant les risques, soit sous la forme de fonctions de sécurité telles que le cryptage, soit sous la forme d'une fonction propre au logiciel permettant de protéger les ressources de dommages éventuels. Par conséquent, la modélisation des menaces aide l'équipe produit à identifier les besoins en fonctions de sécurité, ainsi que les zones pour lesquelles une révision de code attentive et des tests de sécurité sont nécessaires. Le processus de modélisation des menaces doit être pris en charge par un outil qui capture les modèles de menace sous une forme lisible par un ordinateur à des fins de stockage ou de mise à jour. |
| • | Définir des critères de lancement supplémentaires. Les critères de lancement de sécurité élémentaires devant être définis au niveau de l'entreprise, chaque équipe produit ou version d'un logiciel doit disposer de critères spécifiques devant être satisfaits avant le lancement de ce dernier. Par exemple, il se peut qu'une équipe produit développant une version mise à jour d'un logiciel expédié aux clients et victime d'un grand nombre d'attaques choisisse d'exiger que la nouvelle version soit dénuée de vulnérabilités signalées en externe pendant un certain temps avant d'être considérée comme prête à être lancée (En d'autres termes, le processus de développement doit avoir détecté et supprimé les vulnérabilités avant qu'elles ne soient signalées afin d'éviter que l'équipe produit doive les « corriger » une fois qu'elles ont été signalées). |
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 vulnérabilités de sécurité ou éviter leur apparition au cours de cette phase sont énormément exploitées. Elles réduisent considérablement la probabilité d'obtention de vulnérabilités en matière de sécurité dans la version finale du logiciel délivrée aux clients.
Les résultats de la modélisation des menaces sont particulièrement précieux lors de la phase d'implémentation. Les développeurs prêtent une attention toute particulière à l'exactitude du code permettant de limiter les menaces à haute priorité et les testeurs vérifient que de telles menaces sont effectivement bloquées ou limitées.
Les éléments du SDL applicables dans la phase d'implémentation sont les suivants :
| • | Appliquer les normes de codage et de test. Les normes de codage évitent aux développeurs d'introduire des erreurs pouvant entraîner des vulnérabilités en matière de sécurité. Par exemple, l'utilisation d'une gestion des chaînes et de structures de manipulation de la mémoire tampon plus sûres et plus cohérentes peut permettre d'éviter l'introduction de vulnérabilités liées à la saturation de la mémoire tampon. Les normes de test et les pratiques recommandées permettent d'orienter exclusivement les tests sur la détection de vulnérabilités potentielles en matière de sécurité plutôt que sur le fonctionnement correct des fonctions et fonctionnalités du logiciel. |
| • | Appliquer des outils de test de la sécurité, y compris des outils de test de robustesse. Un test de robustesse consiste à fournir des données structurées mais non valides aux interfaces de programmation de l'application (API) et aux interfaces réseau afin d'optimiser la probabilité de détection des erreurs pouvant entraîner des vulnérabilités au niveau du logiciel. |
| • | Appliquer des outils d'analyse statique de code. Ces outils peuvent détecter certains types d'erreurs de codage pouvant générer des vulnérabilités, de type saturation de la mémoire tampon, saturation d'entiers et non-initialisation de variables. Microsoft a énormément investi dans le développement de tels outils (les deux principaux outils s'appellent PREfix et PREfast) et les améliore constamment pour faire face aux nouveaux types d'erreurs de codage et de vulnérabilités au niveau du logiciel. |
| • | Effectuer des révisions de code. Les révisions de code complètent les outils et les tests automatisés dans la mesure où ils concentrent les efforts des développeurs compétents sur l'examen du code source et la détection et la suppression des vulnérabilités potentielles en matière de sécurité. Ils constituent une étape cruciale du processus de suppression des vulnérabilités d'un logiciel au cours du processus de développement. |
2.4 Phase de vérification
La phase de vérification constitue l'étape à laquelle le logiciel terminé est opérationnel et sa version bêta est testée par les utilisateurs. Au cours de cette phase, pendant que le logiciel est soumis à des tests bêtas, l'équipe produit effectue une « campagne de sécurité » comprenant des révisions de code de sécurité plus poussées que celles réalisées à la phase d'implémentation, ainsi que des tests de sécurité ciblés.
Microsoft a introduit la campagne de sécurité au cours de la phase de vérification de Windows Server 2003 et plusieurs autres logiciels au début de l'année 2002. La campagne de sécurité a été introduite dans le processus pour deux raisons :
| • | Le cycle de vie des logiciels en question avait atteint la phase de vérification et cette phase constituait le moment idéal pour effectuer les révisions de code ciblées et les tests nécessaires. |
| • | Mener une campagne de sécurité pendant la phase de vérification garantit que la révision de code et les tests sont effectués sur la version finale du logiciel et permet de réviser à la fois le code développé ou mis à jour lors de la phase d'implémentation et le code « hérité » n'ayant pas été modifié. |
La première de ces raisons reflète un incident historique : la décision de lancer une campagne de sécurité est apparue pour la première fois au cours de la phase de vérification. Cependant, Microsoft est parvenu à la conclusion que mener une campagne de sécurité lors de la phase de vérification était réellement une pratique utile, permettant à la fois au logiciel final de satisfaire les exigences et de subir une révision plus approfondie de tous ses codes hérités de versions précédentes du logiciel.
Il est important de noter que les révisions et les tests d'un code à haute priorité (code faisant partie de la « surface d'attaque » du logiciel) sont cruciaux aux différentes étapes du SDL. Par exemple, de telles révisions et tests devraient être obligatoires à la phase d'implémentation afin de permettre de corriger en amont tous les problèmes et d'identifier et corriger la source de ces problèmes. Ils revêtent également beaucoup d'importance à la phase de vérification lorsque le produit est presque terminé.
2.4 Phase de vérification
Lors de la phase de lancement, le logiciel doit subir une révision de sécurité finale, ou FSR. L'objectif de la FSR est 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 effectuée deux à six mois avant la finalisation du logiciel, en fonction de l'étendue de celui-ci. Le logiciel doit être stabilisé avant la FSR et comporter seulement quelques modifications minimes ne concernant pas la sécurité avant le lancement.
La FSR est une révision du logiciel indépendante, menée par l'équipe de sécurité centrale de l'entreprise. Le conseiller en sécurité de l'équipe de sécurité avertit l'équipe produit de l'étendue de la FSR nécessaire pour le logiciel et lui fournit une liste de ressources requises avant d'effectuer la FSR. L'équipe produit fournit à l'équipe de sécurité les ressources et les informations nécessaires à l'exécution de la FSR. Pour commencer, l'équipe produit remplit un questionnaire et s'entretient avec le membre de l'équipe de sécurité chargé de la FSR. Toute FSR exige une révision des bogues initialement identifiés comme des bogues de sécurité, mais qui, suite à une analyse approfondie, se sont avérés sans impact sur la sécurité, afin de s'assurer que l'analyse a été correctement effectuée. Une FSR comprend également une révision de la capacité du logiciel à résister à des vulnérabilités récemment signalées affectant des logiciels similaires. La FSR de la version principale d'un logiciel demandera un test de pénétration et, éventuellement, l'utilisation de sous-traitants pour un contrôle de sécurité extérieur pour compléter l'équipe de sécurité.
La FSR ne constitue pas un simple examen de passage et son objectif n'est pas non plus de détecter toutes les vulnérabilités de sécurité restantes dans le logiciel ; cela n'est clairement pas réalisable. La FSR consiste plutôt à donner à l'équipe produit et à la direction générale de l'entreprise une vision globale de la position du logiciel en terme de sécurité et de ses chances de pouvoir résister aux attaques une fois qu'il sera délivré aux clients. Si un ensemble de vulnérabilités restantes est détecté lors de la FSR, la réponse adaptée ne consiste pas à les corriger, mais à revenir à l'étape précédente et à prendre d'autres mesures ciblées pour traiter les causes premières (par exemple, amélioration de la formation et des outils).
2.6 Phase de support et de maintenance
Malgré l'application du SDL au cours du développement, les pratiques de développement de pointe ne garantissent pas encore l'envoi de logiciels totalement invulnérables et il y a de bonnes raisons de croire que cela n'arrivera jamais. Même si le processus de développement pouvait éliminer toutes les vulnérabilités d'un logiciel au moment où il est expédié, de nouvelles attaques seraient découvertes et le logiciel « sécurisé » s'avérerait vulnérable. Par conséquent, les équipes produit doivent être prêtes à réagir face aux nouvelles vulnérabilités découvertes dans le logiciel expédié aux clients.
Une partie du processus de réponse implique de se préparer à évaluer des rapports de vulnérabilités et à diffuser des avertissements de sécurité et des mises à jour quand cela s'avère nécessaire. L'autre élément du processus de réponse consiste à effectuer une analyse des vulnérabilités signalées et à prendre des mesures si nécessaire. Les mesures prises pour répondre à la découverte d'une faille vont de l'émission d'une mise à jour en réponse à une erreur isolée à la mise à jour des outils d'analyse de code, en passant par le lancement de révisions de code des principaux sous-systèmes. L'objectif de la phase de réponse consiste à apprendre des erreurs commises et à utiliser les informations fournies dans les rapports de vulnérabilité afin d'aider à détecter et à éliminer les vulnérabilités avant qu'elles soient découvertes sur le terrain et exploitées pour mettre les clients en danger. Le processus de réponse aide également l'équipe produit et l'équipe de sécurité à adapter les processus afin que des erreurs similaires ne soient plus commises dans le futur.
3. Implémentation du SDL chez Microsoft
L'implémentation du SDL chez Microsoft a évolué depuis les « campagnes de sécurité » du début 2002. Afin de démarrer le processus et d'influer sur l'ensemble du développement des produits, les campagnes de sécurité ont été regroupées dans une période d'activités relativement courte qui aurait dû être répartie sur les différentes phases du SDL. Les campagnes de sécurité ont eu un impact considérable sur les plans, les ressources et les planifications des équipes produit et auraient été beaucoup plus difficiles à entreprendre sans le soutien actif de la direction générale de Microsoft. Les campagnes de sécurité sont consacrées à la modélisation des menaces, aux révisions de code et aux tests de sécurité (y compris de pénétration). La FSR a été introduite entre fin 2002 et début 2003, avant la sortie de Windows Server 2003. Elle a eu un impact considérable sur la configuration par défaut de Windows Server 2003.
À la suite des campagnes de sécurité et des FSR, Microsoft a lancé un projet visant à formaliser le processus du SDL. Quatre des résultats spécifiques obtenus par ce projet méritent d'être mentionnés :
| • | Stratégie d'implémentation d'une application obligatoire du SDL |
| • | Formation du personnel technique obligatoire |
| • | Éléments de mesures pour les équipes produit |
| • | Rôle de l'équipe de sécurité centrale |
Les sections suivantes abordent chacun de ces aspects.
3.1 Obligation d'application du SDL
Au vu des avantages réels du SDL (voir Section 5), Microsoft a décidé de formaliser l'obligation d'appliquer le SDL à une large gamme de logiciels. À partir de la rédaction de ce document, le SDL devient obligatoire pour tous les logiciels répondant aux critères suivants :
| • | Susceptibles d'être utilisés pour traiter des informations personnelles et sensibles |
| • | Susceptibles d'être utilisés dans une entreprise ou par toute autre organisation (par exemple, une université, un gouvernement ou une association). |
| • | Susceptibles d'être connectés à Internet ou bien utilisés dans un environnement réseau. |
Les logiciels auxquels cette obligation ne s'applique pas sont les applications autonomes ne correspondant pas aux critères ci-dessus (par exemple, les jeux pour jeunes enfants, tels que la série « Magic School Bus »). De manière significative, le SDL empêche ce type de logiciels d'interférer avec la sécurité de la plate-forme (système d'exploitation ou un autre logiciel) sur laquelle le logiciel fonctionne.
3.2 Obligation de formation
L'un des aspects clés des campagnes de sécurité menées début 2002 consistait à former l'ensemble des équipes des groupes de produit, développeurs, testeurs, responsables de programme et personnel de documentation compris. Microsoft a rendu obligatoire une formation annuelle sur la sécurité destinée aux ingénieurs des structures dont les logiciels sont sujets au SDL. Cette mise à jour annuelle devient nécessaire du fait que la sécurité n'est pas un domaine statique : les menaces, les attaques et les défenses évoluent. Par conséquent, même les ingénieurs dotés des compétences et des qualifications relatives aux aspects de la sécurité affectant leurs logiciels doivent suivre des formations supplémentaires à mesure que le paysage des menaces évolue. Par exemple, l'importance des vulnérabilités de saturation des entiers s'est développée de manière spectaculaire ces quatre dernières années et la preuve a été récemment faite que certains algorithmes cryptographiques contiennent des vulnérabilités n'ayant pas été identifiées auparavant.
Microsoft a élaboré une présentation et une mise à jour commune sur la sécurité dispensée aux ingénieurs à la fois au cours de formations en salles de classe ou sous la forme d'un média numérique. Microsoft a utilisé ce cours comme base pour élaborer des formations spécialisées en fonction de la technologie logicielle et du rôle de l'ingénieur. Microsoft est en passe de réaliser un programme de formations sur la sécurité proposant d'autres spécialisations en fonction de la technologie, du rôle et du niveau d'expérience des étudiants.
Un grand nombre de partenaires et de clients de Microsoft se sont renseignés quant à la disponibilité des processus et des formations en matière de sécurité chez Microsoft. Microsoft Press a publié des ouvrages basés sur les pratiques internes de Microsoft dans les domaines de la conception sécurisée, du codage et de la modélisation de la menace. Microsoft Learning propose des cours basés sur les pratiques internes de Microsoft.
3.3 Éléments de mesure destinés aux équipes produit
En tant qu'entreprise, Microsoft suit l'adage selon lequel « on ne peut pas gérer ce qu'on ne peut pas mesurer ». Il est très difficile de concevoir des éléments de mesure capables de mesurer fidèlement le niveau de sécurité d'un logiciel. Certains éléments de mesure assurent clairement par procuration la sécurité du logiciel. Ces unités de mesure vont des formations destinées au personnel technique (au début du cycle de développement) jusqu'au taux de vulnérabilités découvertes dans un logiciel envoyé à des clients.
Microsoft a conçu un ensemble d'éléments de mesure de la sécurité exploitables par les équipes produit pour évaluer le succès de l'implémentation du SDL. Ces éléments de mesure traitent de l'implémentation du SDL par l'équipe à partir de la modélisation des menaces jusqu'à la sécurité des logiciels présentés au FSR, en passant par la révision du code et les tests de sécurité. Ces éléments étant implémentés au fur et à mesure, ils doivent permettre aux équipes de suivre leur propre performance (amélioration, stabilisation ou détérioration), ainsi que leur performance comparée aux autres équipes. L'ensemble des éléments de mesure est régulièrement transmis au responsable de l'équipe produit et aux cadres supérieurs de Microsoft.
3.4 L'équipe de sécurité centrale
Bien avant les campagnes de sécurité de 2002, Microsoft a créé l'équipe SWI (Secure Windows Initiative) dont le rôle consistait à améliorer la sécurité des logiciels et à réduire les vulnérabilités de Windows, ainsi qu'à apporter une assistance en matière de sécurité aux équipes produit autres que celles qui développaient 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 dispensé des formations et des conseils pour toutes les campagnes de sécurité menées au début de l'année 2002. L'équipe SWI a également effectué la FSR de Windows Server 2003, appliquant ce processus pour la première fois.
Dans le cadre du déploiement formel du SDL, l'équipe SWI a pris le rôle d'équipe de sécurité centrale pour Microsoft. Les tâches 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 dispense d'une formation aux techniciens. |
| • | Attribution/mise à disposition de « conseillers en sécurité » qui assistent les équipes produit tout au long du processus, effectuent des révisions pour elles et s'assurent que les questions de l'équipe produit reçoivent des réponses précises, bien documentées et dans les meilleurs délais. |
| • | Faire office d'experts dans une large gamme de sujets relatifs à la sécurité, en s'assurant que les questions adressées aux conseillers en sécurité reçoivent des réponses précises dans les meilleurs délais. |
| • | Exécution des FSR avant le lancement du logiciel. |
| • | Investigation technique des vulnérabilités signalées dans les logiciels envoyés aux clients afin de s'assurer que les causes premières sont comprises et que le niveau de réponse approprié est mis en œuvre. |
La disponibilité et l'efficacité de l'équipe SWI se sont avérées des facteurs clés de l'implémentation du SDL chez Microsoft. Microsoft envisage de disposer d'un processus évolutif permettant de développer des logiciels plus sécurisés, ce qui implique d'avoir des compétences en sécurité largement réparties au sein de l'ensemble des équipes produit. Cependant, le fait de disposer d'une équipe de sécurité centrale et hautement qualifiée est essentiel pour mettre à niveau l'ensemble des équipes produit de l'entreprise et les assister dans leur travail d'élaboration de logiciels plus sécurisés. Cela assure également qu'une personne extérieure à l'équipe produit effectue la FSR.
4. Résultats de l'implémentation du SDL chez Microsoft
Il serait prématuré pour Microsoft de conclure que le SDL améliore la sécurité des logiciels Microsoft, mais jusqu'ici les résultats sont encourageants.
Windows Server 2003 a été la première version d'un système d'exploitation de Microsoft à intégrer des portions considérables du SDL. La figure 3 indique le nombre de bulletins de sécurité émis l'année suivant le lancement des deux plus récents systèmes d'exploitation serveur de Microsoft : Windows 2000 et Windows Server 2003 (Lors du lancement de Windows 2000, Microsoft ne disposait pas d'un système d'indice de gravité des bulletins de sécurité formel. Microsoft a évalué chaque bulletin de sécurité s'appliquant à Windows 2000 par rapport à son système d'indice de gravité actuel). Comme indiqué précédemment dans cet article, Windows Server 2003 a été développé en utilisant la plupart (et non l'intégralité) des processus du SDL ; Windows 2000 n'a pas été développé à l'aide de ces processus.
Figure 3. Nombre de bulletins de sécurité suivant l'année de lancement
Figure 4. Bulletins de sécurité pré- et post-SDL relatifs à SQL Server 2000
Figure 5 Bulletins de sécurité pré- et post-SDL relatifs à Exchange Server 2000
Un autre exemple encourageant est illustré par le composant Internet Information Server de Windows Server 2003 (IIS 6) ; depuis son lancement il y a deux ans, Microsoft a émis un seul bulletin de sécurité affectant le serveur Web et il ne s'agissait pas d'un composant (WebDAV) installé par défaut.
Les exemples de vulnérabilités en matière de sécurité restant minimes et les périodes de temps limitées, ces résultats fournissent la preuve que le SDL est efficace. Microsoft va continuer à surveiller le nombre de vulnérabilités dans Windows Server 2003 et dans les Services Packs Exchange Server et SQL Server pour voir si la tendance se confirme. Microsoft va également analyser d'autres logiciels lorsque de nouvelles versions seront expédiées après l'implémentation complète du SDL afin de déterminer si le nombre et l'indice de gravité des vulnérabilités continuent à chuter.
5. Remarques sur l'application du SDL
Les données présentées dans la section précédente fournissaient une vue d'ensemble des améliorations que le SDL est supposé apporter. Cette section tente de répondre à certaines questions concernant la « manière » dont le processus fonctionne. Tandis que la section précédente se base sur des chiffres concrets (Microsoft assure un suivi scrupuleux des rapports de vulnérabilité et des bulletins de sécurité), cette section se base sur des données anecdotiques 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 tout au long du cycle de développement du logiciel. Il a été demandé à l'équipe du SDL de hiérarchiser ces sous-processus en termes d'efficacité, c'est-à-dire d'un côté les plus bénéfiques et de l'autre ceux jugés moins efficaces.
L'équipe SWI est d'accord sur le fait que la modélisation des menaces est le composant le plus important du SDL. Évidemment, la modélisation des menaces ne s'applique pas de façon isolée : elle influe sur la conception, la révision de code et les tests. En outre, un processus ayant implémenté uniquement la modélisation des menaces mais n'ayant pris aucune mesure en réponse aux modèles (en négligeant de tester l'efficacité des minimisations par exemple) ne serait absolument pas efficace. Les statistiques sous la forme de comptes de bogues ont tendance à minimiser le rôle de la modélisation des menaces car l'objectif principal de celle-ci consiste à éviter de créer des bogues pouvant générer des vulnérabilités. Cependant, le rôle de la modélisation des menaces au sein du processus de développement de logiciels sécurisés est tellement fondamental qu'il vient se placer tout en haut de la liste.
Le SDL reste un processus relativement nouveau chez Microsoft, par conséquent, aucun composant du processus n'a encore été supprimé d'une instance. Cependant, les chercheurs de longue date en sécurité ne seront pas surpris de découvrir que les tests de pénétration ne constituent pas la meilleure façon de parvenir à un niveau de sécurité satisfaisant. Les tests de pénétration font partie de la FSR pour le lancement de logiciels importants, mais les activités de l'équipe produit au cours de l'ensemble du cycle de vie sont centrées sur la modélisation des menaces, les révisions de code et l'utilisation d'outils automatisés, ainsi que des tests de robustesse plutôt que sur des tests de pénétration. Toutes ces mesures sont bien plus efficaces pour empêcher et supprimer les vulnérabilités de sécurité que les tests de pénétration ponctuels classiques. Dans le cadre de la FSR, le test de pénétration permet de définir si le logiciel est prêt à être diffusé plutôt que de rechercher et corriger des bogues de sécurité. Si lors du test de pénétration de la FSR, un grand nombre de vulnérabilités de sécurité sont détectées, cela signifie que les phases précédentes n'ont pas été suffisamment efficaces. La réponse appropriée consiste à passer en revue les activités théoriquement effectuées lors de ces phases plutôt que de corriger uniquement les bogues du test de pénétration et diffuser le logiciel.
5.2 Outils, tests et révisions de code
Les outils d'analyse statique, les tests de robustesse et la révision de code sont complémentaires. Microsoft a largement investi dans les 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 engendrer des vulnérabilités, en particulier la saturation de la mémoire tampon. Cependant, les outils de pointe actuels ne détectent pas toutes les erreurs. C'est pour cette raison que les révisions de code manuelles restent obligatoires dans le SDL, à la fois pour détecter les erreurs que les outils ne traitent pas et pour identifier les possibilités d'amélioration de ces outils. L'article MSDN (Microsoft Developer Network) de Michael Howard cité en référence présente l'approche générale de l'exécution de révisions de sécurité des codes enseignée aux ingénieurs de Microsoft.
L'importance du test de robustesse est un ajout relativement récent au SDL, mais les résultats enregistrés à ce jour sont très encourageants. Contrairement aux outils d'analyse de code statique, les outils de test de robustesse doivent être élaborés (ou du moins configurés) pour chaque format de fichier et/ou protocole réseau à tester ; c'est pour cette raison qu'ils sont fréquemment capables de détecter les erreurs oubliées par les outils d'analyse statique. Les modèles de menace aident les équipes produit à hiérarchiser les interfaces et les formats en vue du test. Les résultats des tests de robustesse ne sont pas totalement déterminants (les outils sont lancés pour un nombre de cycles bien limité et ne garantissent pas la détection de tous les bogues), mais par expérience, un niveau de test de robustesse économique est susceptible de trouver des bogues « intéressants » pouvant être utilisés comme des vulnérabilités de sécurité.
5.2 Investissements
La formation obligatoire à la sécurité constitue un investissement considérable pour une entreprise dont le personnel technique est aussi nombreux que celui de Microsoft. La formation est dispensée à la fois sous la forme de cours traditionnels en présence d'un formateur et de supports en ligne. Les supports en ligne sont particulièrement précieux en tant qu'outil de formation pour les petites équipes techniques sur des sites éloignés du siège de Microsoft. Les formations réelles se sont avérées particulièrement efficaces lorsqu'elles sont dispensées à toute une équipe en cours de préparation de campagnes de sécurité ou d'autres activités clés. Dans ce cas, l'expérience de Microsoft indique que la formation de l'équipe provient non seulement de la formation en classe, mais également de la campagne de sécurité. La formation en sécurité (généralement une demi-journée) est amplifiée par le fait que l'ensemble des membres du groupe de travail est concentré sur la sécurité.
L'équipe de sécurité centrale (équipe SWI) s'est considérablement agrandie ces dernières années à mesure que l'importance accordée par Microsoft à la sécurité augmente. Par sa conception, l'équipe est petite comparée à la totalité du personnel technique de Microsoft et privilégie les approches évolutives afin que la responsabilité et les ressources destinées à produire des logiciels plus sécurisés restent entre les mains des équipes produit. Certaines stratégies reflétant cette attention particulière à l'évolutivité impliquent de mettre l'accent sur la formation et les outils, d'affecter des conseillers de sécurité dont le rôle consiste à aider l'équipe produit à résoudre ses propres problèmes (plutôt que résoudre les problèmes pour l'équipe) et d'effectuer des révisions (y compris la FSR) pour expliquer à l'équipe produit dans quelle mesure le logiciel est prêt ou non à être lancé.
5.4 Résultats
Le dernier test du SDL consiste à évaluer dans quelle mesure il permet de supprimer et de limiter les vulnérabilités d'un logiciel Microsoft. L'expérience (résumée à la section 4) démontre que le SDL satisfait ce test. Microsoft évalue également les vulnérabilités signalées à l'extérieur afin de mesurer leur effet sur les versions de logiciels en cours de développement. Une expérience récente a montré que les mesures de sécurité prévues ou implémentées dans des nouvelles versions bloquent de plus en plus les attaques qui s'avéraient efficaces contre les versions plus anciennes. Le Service Pack 2 de Windows XP récemment lancé a été révisé de cette manière. Des changements en terme de sécurité ont été prévus, mais pas encore implémentés ou évoqués publiquement et se sont avérés aptes à éliminer un nombre considérable de vulnérabilités signalées dans des versions précédentes de Windows par des chercheurs en sécurité extérieurs à Microsoft.
6. Conclusions
L'expérience de Microsoft montre que le SDL est efficace pour réduire le nombre de vulnérabilités en matière de sécurité. L'implémentation initiale du SDL (pour Windows Server 2003, le Service Pack 3 de SQL Server 2000 et le Service Pack 3 de Exchange 2000 Server) a entraîné des améliorations significatives au niveau de la sécurité des logiciels et les versions suivantes des logiciels, reflétant les améliorations apportées au SDL, témoignent d'autres améliorations au niveau de la sécurité.
L'implémentation progressive des éléments constitutifs du SDL a engendré des améliorations progressives, que nous analysons comme une preuve d'efficacité du processus. Le processus n'est pas parfait et continue à évoluer. D'ailleurs, il ne risque ni d'atteindre la perfection ni de cesser d'évoluer dans l'immédiat.
Le développement et l'implémentation du SDL représentent un investissement important pour Microsoft et un changement considérable dans la manière dont les logiciels sont conçus, développés et testés. L'importance croissante des logiciels dans la société souligne le besoin pour Microsoft et le secteur en général de continuer à améliorer la sécurité des logiciels ; par conséquent, cet article sur le SDL et les ouvrages relatifs à des techniques spécifiques (voir les références) ont été publiés dans le souci de faire partager l'expérience de Microsoft au reste de l'industrie logicielle.
7. Remerciements
La rédaction de cet article a débuté à la fin de l'année 2002 grâce aux efforts combinés des présents auteurs. Ses ébauches ont été mises à jour au fil de l'évolution du SDL et la présente version a été préparée pendant l'été et l'automne 2004. Les auteurs aimeraient remercier Matt Thomlinson, Matt Lyons, Jamil Villani et Eric Bidstrup (tous membres de l'équipe SWI de Microsoft) pour leur contribution à la définition et à l'amélioration du SDL. Outre les collaborateurs cités, Scott Charney et Phil Reitinger de Microsoft et Jeannette Wing de Carnegie Mellon University ont fourni des commentaires particulièrement utiles sur les premières ébauches. Les auteurs souhaitent également 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, November 2004
Howard, Michael, Expert Tips for Finding Security Defects in Your Code, MSDN Magazine, November 2003
Howard, Michael and David LeBlanc, Writing Secure Code, Second Edition, Microsoft Press, Redmond, Washington, 2003
Swiderski, Frank and Window Snyder, Threat Modeling, Microsoft Press, Redmond Washington, 2004
9. Avertissements
Les informations contenues dans ce document correspondent à la vision actuelle de Microsoft Corporation concernant les problèmes abordés à partir de la date de publication. Microsoft étant obligé de répondre aux conditions du marché en constante évolution, cet article ne doit pas être interprété comme un engagement de la part de Microsoft et Microsoft ne peut pas garantir l'exactitude de toutes les informations présentées après la date de publication.
Ce livre blanc a été rédigé à des fins purement informatives. MICROSOFT EXCLUT TOUTE GARANTIE, EXPRESSE, IMPLICITE OU LÉGALE, QUANT AUX INFORMATIONS PRÉSENTES DANS CE DOCUMENT.
La responsabilité de la conformité aux lois sur les droits d'auteur en vigueur incombe à l'utilisateur. Sans limiter les droits d'auteur, aucune partie de ce document ne peut être reproduite, stockée ou introduite dans un système de récupération de données ou transmise sous aucune forme, par quelque moyen que ce soit (électronique, mécanique ou autre) sans l'accord écrit explicite de Microsoft Corporation
Il se peut que Microsoft dispose de brevets, de demandes de brevets, de marques commerciales, des copyrights ou d'autres droits sur des propriétés intellectuelles couvrant le sujet abordé dans ce document. Sauf dans le cadre de dispositions expresses stipulées dans un contrat de licence écrit délivré par Microsoft, la publication de ce document ne vous donne aucun droit sur ces brevets, marques commerciales, copyrights ou autres propriétés intellectuelles.
© 2005 Microsoft Corporation. Tous droits réservés. Certaines parties de ce livre blanc sont la propriété de © 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 marques commerciales de Microsoft Corporation aux États-Unis et/ou dans d'autres pays.