Implémentation simplifiée de Microsoft SDL2 février 2010

SDL Core Concepts Simplified

Pour les informations les plus récentes, consultez http://www.microsoft.com/sdl.

Le présent document est fourni « en l’état ». Les informations et points de vue contenus dans ce document, y compris les URL et autres références à un site Web, peuvent faire l'objet de modifications sans préavis. Vous assumez tous les risques liés à son utilisation.

Le présent document ne vous octroie aucun droit légal de propriété intellectuelle sur les produits Microsoft. Vous êtes autorisé à copier et utiliser le présent document à des fins de référence interne.

© 2010 Microsoft Corporation. Tous droits réservés. 

Sous licence Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported. 

France http://creativecommons.org/licenses/by-nc-sa/2.0/fr/, et Luxembourg http://creativecommons.org/licenses/by-nc-sa/3.0/lu/.

Implémentation simplifiée de Microsoft SDL 1

Sommaire

Introduction.......................................................................................................................................3

Cycle de développement Microsoft SDL........................................................................................3

Développement sécurisé chez Microsoft.......................................................................................4

Modèle d’optimisation Microsoft SDL............................................................................................4

Applicabilité de SDL.........................................................................................................................5

Rôles, responsabilités et qualifications du personnel de sécurité..............................................6

Activités de sécurité dans SDL simplifié........................................................................................7

Activités de sécurité obligatoires................................................................................................7

Exigences préliminaires à SDL : Formation à la sécurité..................................................8

Phase 1 : Exigences..........................................................................................................9

Phase 2 : Conception......................................................................................................10

Phase 3 : Implémentation................................................................................................11

Phase 4 : Vérification.......................................................................................................12

Phase 5 : Diffusion...........................................................................................................12

Activités de sécurité optionnelles.............................................................................................14

Autres exigences............................................................................................................................14

Analyse de la cause principale.................................................................................................14

Mises à jour régulières du processus.......................................................................................15

Processus de vérification de la sécurité de l’application...........................................................15

Conclusion......................................................................................................................................16

Annexe A : Illustration du processus SDL...................................................................................17

Implémentation simplifiée de Microsoft SDL 2

IntroductionL’objet de ce document est d’illustrer les principaux concepts de Microsoft Security Development Lifecycle (SDL) et de présenter les activités de sécurité à réaliser afin d’être en conformité avec le processus SDL.

Ce document contient :

Un bref aperçu de Microsoft SDL. Une présentation du modèle d’optimisation Microsoft SDL qui décrit notamment où se

place Microsoft SDL dans le modèle d’optimisation. Une présentation des pratiques de développement sécurisé Microsoft incluant :

Les rôles et les responsabilités des personnes impliquées dans le processus de développement d’applications.

Les activités de sécurité obligatoires. Les activités de sécurité optionnelles. Le processus de vérification de sécurité de l’application.

Le processus décrit dans ce document correspond à un seuil minimal pour respecter la conformité à SDL. Cela dit, aucune entreprise n’est identique à une autre et les équipes de développement devraient appliquer SDL en fonction des ressources humaines et des talents disponibles mais sans compromettre les objectifs de sécurité organisationnels.

Il est important de noter que ce document se concentre uniquement sur les méthodologies de sécurité mises en œuvre pour développer des applications et des services en ligne, internes et externes. Dans une entreprise, il existe d’autres méthodologies (comme les pratiques de sécurité du service informatique) qui se concentrent sur les menaces de sécurité « opérationnelles ». Bien que les groupes qui administrent ces processus puissent se retrouver dans des contextes technologiques et réglementaires comparables à ceux des groupes de développement, ils ne créent généralement pas de logiciels destinés à être utilisés dans des environnements où un risque important de sécurité existe.

Des références à des sources publiques d’informations sont fournies chaque fois que cela est possible. Ce document inclut aussi des liens Web vers des discussions spécifiques sur des processus, des outils et d’autres informations annexes.

Cycle de développement Microsoft SDLSDL (Security Development Lifecycle) est un processus d’assurance qualité centré sur le développement de logiciel. Initiative lancée en 2004 et processus appliqué à tous les développements Microsoft depuis cette date, SDL a joué un rôle important dans la prise en compte de la sécurité et du respect de la vie privée dans les logiciels Microsoft et dans la culture de l’entreprise. En combinant une approche globale et pratique, SDL introduit la sécurité et le respect de la vie privée dès le début du projet et tout au long des différentes phases du développement.

Microsoft SDL repose sur trois concepts fondamentaux : formation, amélioration continue du processus et responsabilisation. La sensibilisation permanente et la formation des personnes au sein d’un groupe de développement jouent un rôle très important. Un investissement adéquat dans le transfert des connaissances aide les organisations à réagir correctement à des changements dans la technologie et le paysage des menaces. Le risque de sécurité

Implémentation simplifiée de Microsoft SDL 3

n’étant pas statique, SDL insiste sur la compréhension des causes et l’effet des vulnérabilités en sécurité. SDL exige une évaluation régulière des processus SDL et l’introduction de changements en réponse à de nouvelles avancées technologiques ou à de nouvelles menaces. Des données sont collectées pour évaluer l’efficacité de la formation, des métriques pendant le déroulement du processus confirment la conformité du processus, et des métriques après la sortie du produit guident vers de futures modifications. Enfin, SDL exige l’archivage de toutes les données nécessaires à la résolution d’un problème en cas de crise. Lorsque SDL est couplé à des plans détaillés de communication et de réponse de sécurité, une organisation peut fournir des conseils précis et pertinents à toutes les parties concernées.

Développement sécurisé chez MicrosoftCe document décrit principalement la mise en œuvre de Microsoft SDL dans des pratiques de développement couramment utilisées par des équipes externes à Microsoft. Il existe bien sûr une forte corrélation entre ce document et le processus publié qui est appliqué au développement de services et de produits Microsoft. Il faut toutefois préciser que Microsoft va au-delà des concepts de base décrits ici, et applique SDL comme un processus qui reflète les contextes techniques et métier de Microsoft. SDL, tel qu’il est pratiqué chez Microsoft, a évolué à partir des concepts de base présentés dans ce document, puis a été appliqué à des centaines de produits qui fonctionnent sur différents systèmes d’exploitation et plateformes matérielles. Les mêmes concepts sont exploités par des équipes Microsoft dans plus de 100 pays afin de répondre à certains défis particuliers qui se posent dans les domaines de la sécurité et du respect de la vie privée.

Microsoft souhaite rendre transparent le processus de sécurité et de respect de la vie privée. Pour répondre aux utilisateurs qui souhaitaient savoir comment Microsoft applique SDL pour renforcer la sécurité de ses services et produits, une description détaillée du processus Microsoft SDL a été publiée sur www.microsoft.com/sdl.

Modèle d’optimisation Microsoft SDLL’intégration des concepts de développement sécurisé dans un processus de développement existant peut être intimidante et coûter cher si elle est menée de façon inadéquate. La réussite ou l’échec dépend souvent de variables comme la taille de l’entreprise, la disponibilité de ressources (temps, talents et budget), et le soutien apporté au projet par la direction. L’impact de ces éléments peut être contrôlé par la compréhension des bonnes pratiques de développement en terme de sécurité et par l’établissement de priorités en fonction du degré de maturité de l’équipe de développement. Microsoft a créé le modèle d’optimisation SDL pour aider à résoudre les problèmes potentiels.

Ce modèle se compose de cinq parties qui correspondent globalement aux phases de développement d’un logiciel :

Formation, stratégie et capacités organisationnelles Exigences et conception

Implémentation simplifiée de Microsoft SDL 4

Le processus Microsoft SDL décrit dans ce document se concentre sur l’application de pratiques prouvées de

sécurité à différents points dans le processus de développement. Ce

processus est indépendant des technologies et ne se limite

pas aux grandes entreprises.

Implémentation Vérification Diffusion et réponseDe plus, le modèle d’optimisation SDL définit quatre niveaux de maturité des pratiques dans ces phases : Basique, Standardisé, Avancé et Dynamique.

Le niveau Basique correspond à peu de formation et d’outils en place. Le niveau Dynamique correspond à une conformité totale à SDL dans toute l’entreprise. Lorsque la conformité est totale, les processus mis en place sont efficaces, les personnes sont bien formées, des outils spécialisés existent et l’ensemble des parties, tant internes qu’externes à l’entreprise, sont fortement impliquées.

Ce document se concentre sur les tâches et les processus nécessaires pour atteindre le niveau de maturité « Avancé » : l’entreprise prouve ses compétences dans chacune des cinq phases mentionnées ci-dessus et peut raisonnablement affirmer qu’elle respecte les pratiques de Microsoft SDL.

Implémentation simplifiée de Microsoft SDL 5

Par rapport aux autres modèles de maturité de logiciel, le modèle d’optimisation Microsoft SDL se concentre strictement sur les améliorations du processus de développement. Il fournit des conseils validés par l’usage et exploitables pour montrer comment passer d’un faible niveau de maturité à un niveau supérieur. Il évite aussi l’approche « liste de listes » des autres modèles d’optimisation.

Applicabilité de SDLPour une entreprise, il est très important de définir clairement les types de projets qui seront soumis aux contrôles imposés par Microsoft SDL. L’expérience pratique suggère que les applications qui présentent une ou plusieurs des caractéristiques suivantes soient soumises à SDL :

Applications déployées dans un environnement d’entreprise. Applications traitant des informations personnelles ou d’autres informations sensibles. Applications communiquant régulièrement sur Internet ou sur d’autres réseaux.En raison de l’omniprésence de l’informatique et de l’évolution des menaces, il peut être plus simple d’identifier les projets qui ne seront pas soumis à des contrôles de sécurité comme définis dans SDL.

Rôles, responsabilités et qualifications du personnel de sécuritéSDL inclut des descriptions des postes et des critères généraux pour les rôles relatifs à la sécurité et au respect de la vie privée. Ces rôles sont définis au cours de la phase Exigences du processus SDL. Ils permettent de définir la structure organisationnelle nécessaire pour identifier, cataloguer et atténuer des problèmes de sécurité et de respect de la vie privée présents dans un projet de développement logiciel. Ces rôles sont notamment :

Rôles des conseillers. Ces rôles assurent la surveillance de la sécurité et du respect de la vie privée ; ils ont l’autorité pour accepter ou rejeter des plans de l’équipe projet concernant la sécurité et la vie privée. Conseiller en sécurité / Conseiller en respect de la vie privée.

Ces rôles sont tenus par des experts en la matière et n’appartiennent pas à l’équipe projet. Il peut s’agit d’un membre qualifié d’un groupe central et indépendant dans l’entreprise, spécialement formé pour effectuer des contrôles de ce type, ou d’un expert externe à l’entreprise. La personne choisie doit remplir deux sous-rôles : Auditeur. La personne contrôle chaque phase du

processus de développement logiciel et atteste que l’application respecte chacune des exigences dans le domaine de la sécurité. Le conseiller doit avoir la liberté d’attester la conformité (ou la non-conformité) par rapport aux exigences en matière de sécurité et de respect de la vie privée, sans interférer avec l’équipe projet.

Implémentation simplifiée de Microsoft SDL 6

Figure 1. Modèle d’optimisation SDL avec niveaux de maturité.

Un groupe central interne à l’entreprise est préférable car il

connaît mieux le contexte de

l’entreprise que des experts extérieurs.

Expert. La personne choisie pour un rôle de conseiller doit posséder une expertise reconnue dans le domaine de la sécurité.

Combinaison des rôles de conseil. Le rôle de conseiller en sécurité peut être combiné avec le rôle de conseiller en respect de la vie privée si la personne possède des compétences et une expérience reconnues dans les deux domaines.

Champions d’équipe. Les rôles de champions devraient être tenus par des experts en sécurité faisant partie de l’équipe projet. Ces personnes sont responsables de la négociation, de l’acceptation et du suivi des exigences minimales en termes de sécurité et de respect de la vie privée. Ils assurent une communication claire avec les conseillers et les chefs de projet. Champion en sécurité / Champion en respect de la vie privée. Cette personne (ou le

groupe de personnes) n’a pas seule la responsabilité d’assurer qu’un logiciel réponde à tous les problèmes de sécurité, mais elle est responsable de la coordination et du suivi des questions de sécurité pour le projet. Ce rôle doit aussi remonter l’état du projet au conseiller en sécurité et aux autres parties concernées (par exemple, aux responsables des tests et du développement).

Combinaison des rôles. Comme pour les rôles de conseiller en sécurité et en respect de la vie privée, les rôles de champions peuvent se combiner si la personne possède des compétences et une expérience reconnues dans les deux domaines.

Activités de sécurité dans SDL simplifiéEn synthèse, Microsoft SDL est un ensemble d’activités obligatoires dans le domaine de la sécurité, réparties sur l’ensemble des phases du développement logiciel. Ces activités peuvent déjà contribuer à renforcer la sécurité lorsqu’elles sont appliquées chacune séparément. Toutefois, l’expérience pratique de Microsoft montre que ces activités conduisent à des améliorations bien supérieures de la sécurité lorsqu’elles sont combinées entre elles, tout au long du processus de développement.

L’équipe projet et le conseiller en sécurité ont la possibilité d’ajouter des activités de sécurité optionnelles pour atteindre les objectifs souhaités en sécurité et en respect de la vie privée. Nous n’aborderons pas ici la présentation détaillée de chacune des activités de sécurité.

Figure 2. Le cycle de développement sécurisé SDL de Microsoft - simplifié.

Implémentation simplifiée de Microsoft SDL 7

Il faut se concentrer sur l’exactitude des résultats atteints à chaque phase. Des rapports incomplets

ou inexacts font perdre du temps et gaspillent des

ressources.

Dans SDL, il est fondamental que l’entreprise vérifie à la fin de chaque phase du développement, la qualité des résultats obtenus. Un certain degré de sophistication du processus de sécurité est attendu des entreprises qui se situent au niveau Avancé ou Dynamique du modèle d’optimisation SDL. Mais certaines différences ne sont pas prises en compte, par exemple si un modèle de menace est le résultat d’une session de réflexion devant un tableau blanc avec l’équipe de développement, ou s’il est écrit comme un récit sous Word, ou s’il est produit par un outil spécialisé comme SDL Threat Modeling Tool. Le processus SDL bénéficie d’investissements dans des outils efficaces et l’automatisation, mais la vraie valeur réside dans des résultats précis et complets.

Pour faciliter une revue, l’Annexe A présente un diagramme détaillé d’un processus SDL. Ce diagramme représente les activités de sécurité pour un projet hypothétique, depuis la formation des employés jusqu’à la diffusion de l’application. Il inclut les tâches obligatoires et optionnelles.

Activités de sécurité obligatoiresSi un projet doit être soumis à SDL (voir la section Applicabilité de SDL), l’équipe de développement doit réaliser et démontrer le succès de seize activités obligatoires de sécurité pour respecter le processus Microsoft SDL. Ces activités sont considérées comme efficaces par des experts en sécurité et en respect de la vie privée ; elles sont revues régulièrement dans le cadre de l’évaluation rigoureuse annuelle du processus. L’équipe de développement peut ajouter, si elle le souhaite, d’autres activités à ces seize activités obligatoires mais elle ne peut pas en supprimer.

Exigences préliminaires à SDL : Formation à la sécurité

Activité SDL 1   : Exigences en formation Tous les membres des équipes de développement doivent recevoir une formation appropriée pour être informés des bases de la sécurité et des évolutions récentes dans les domaines de la sécurité et du respect de la vie privée. Les personnes qui jouent un rôle technique (développeurs, testeurs et chefs de projet) et qui sont directement impliquées dans le développement de logiciels, doivent participer au moins à une formation sur la sécurité chaque année.

Une formation de sécurité de base devrait couvrir les concepts suivants :

Conception sécurisée : Réduction de la surface d’attaque Défense en profondeur Principe du moindre privilège Paramètres par défaut respectant la sécurité

Modélisation des menaces : Présentation de la modélisation des menaces Implications sur la conception d’un modèle des menaces Contraintes de programmation résultant du modèle

Écriture de code sécurisé : Débordements de tampons (pour applications écrites en C et C++) Erreurs arithmétiques sur entiers (pour applications écrites en C et C++) Scripts intersites (pour code managé et applications Web)

Implémentation simplifiée de Microsoft SDL 8

Injection SQL (pour code managé et applications Web) Cryptographie faible

Tests de la sécurité : Différences entre tests fonctionnels et tests de sécurité Évaluation du risque Méthodes de test de la sécurité

Respect de la vie privée : Types de données personnelles sensibles Pratiques de conception recommandées en termes de respect de la vie privée Analyse du risque Pratiques de développement recommandées pour le respect de la vie privée Pratiques de tests recommandées pour le respect de la vie privée

Ces éléments de formation définissent les connaissances minimales pour le personnel technique. Si le temps et les ressources le permettent, une formation sur des sujets plus évolués peut être nécessaire. Par exemple :

Architecture et conception avancées de la sécurité Conception d’une interface utilisateur de confiance Vulnérabilités de sécurité en détail Mise en œuvre d’atténuations des menaces

Phase 1 : Exigences

Activité SDL 2   : Exigences de sécurité La nécessité de prendre en compte dès le début du projet la sécurité et le respect de la vie privée constitue un principe de base du développement sécurisé. Le meilleur moment pour définir les exigences en sécurité pour un logiciel se situe au début des étapes initiales de planification. Cela permet à l’équipe de développement d’identifier les jalons les plus importants ainsi que les éléments livrables, et permet l’intégration de la sécurité et du respect de la vie privée sans trop perturber les plannings et les calendriers. Une analyse des exigences en sécurité et vie privée est réalisée au début du projet. Elle inclut les exigences minimales de sécurité pour l’application lorsqu’elle fonctionnera dans son environnement normal d’exploitation, ainsi que les spécifications et le déploiement d’un système de suivi des éléments de travail et des vulnérabilités.

Activité SDL 3   : Échelle des bogues et niveaux de qualité Les niveaux de qualité et l’échelle des bogues servent à établir les niveaux de qualité minimaux acceptables en termes de sécurité et de respect de la vie privée. Définir ces valeurs au début du projet permet de mieux comprendre les risques associés aux problèmes de sécurité. Les équipes savent alors sur quels risques se concentrer pendant le développement. L’équipe projet doit définir des niveaux de qualité (par exemple, tous les messages d’avertissement du compilateur doivent être triés en fonction de ces niveaux avant de commencer l’écriture du code) pour chaque phase de développement. Ces niveaux doivent ensuite être approuvés par le conseiller en sécurité qui peut clarifier certains points du projet et ajouter des exigences de sécurité plus fortes si nécessaire. L’équipe projet doit aussi prouver la conformité avec les niveaux de qualité définis, afin de réussir la revue finale de sécurité (FSR).

Implémentation simplifiée de Microsoft SDL 9

L’échelle des bogues est un niveau et un seuil de qualité qui s’appliquent à l’ensemble du projet de développement. Elle sert à définir le seuil de sévérité des vulnérabilités de sécurité et, par exemple, aucune vulnérabilité connue dont le niveau est « critique » ou « important » ne doit apparaître dans la version finale. L’échelle des bogues, une fois définie, ne doit jamais être assouplie. Une échelle fluctuante serait mal comprise et mal acceptée par l’équipe de développement.

Activité SDL 4   : Analyse de risque de sécurité et de respect de la vie privée Les analyses de risques de sécurité (SRA) et les analyses de risque de respect de la vie privée (PRA) sont des processus obligatoires qui identifient les aspects fonctionnels du logiciel nécessitant une revue approfondie. Ces analyses doivent inclure les informations suivantes :

1. (Sécurité) Parties du projet qui nécessitent des modélisations des menaces avant la diffusion du logiciel.

2. (Sécurité) Parties du projet qui nécessitent des revues de la conception de la sécurité avant la diffusion du logiciel.

3. (Sécurité) Parties du projet qui nécessitent des tests de pénétration de la part d'un groupe agréé, externe à l'équipe projet.

4. (Sécurité) Toutes exigences de revue d’analyse ou de test que le conseiller en sécurité juge nécessaire pour réduire les risques de sécurité.

5. (Sécurité) Portée spécifique des tests par injection de fautes aléatoires.6. (Respect de la vie privée) Impact du respect de la vie privée. Pour évaluer cet impact, il

faut suivre la classification suivante : P1 : Risque élevé sur la vie privée. La fonctionnalité, le produit ou le service

enregistre ou transfère des informations personnelles sensibles, modifie des paramètres ou des associations de types de fichiers, ou installe un logiciel.

P2 : Risque modéré sur la vie privée. Le seul comportement qui est en rapport avec la confidentialité dans le produit, le logiciel ou le service est un transfert unique de données anonymes, effectué par l’utilisateur. Par exemple, l’utilisateur clique sur un lien qui lui fait quitter le site Web sur lequel il se trouve.

P3 : Faible risque sur la vie privée. Rien dans ce produit, ce logiciel ou ce service, n’affecte la vie privée. Aucune donnée anonyme ou personnelle n’est transférée, rien n’est enregistré dans l’ordinateur, aucun paramètre n’est modifié et aucun logiciel n’est installé.

Phase 2 : Conception

Activité SDL 5   : Exigences de conception Pour pouvoir influer sur la confiance mise dans la conception d’un projet, il est important de s’en préoccuper dès le début du projet. Il est particulièrement important de prendre en compte les problèmes de sécurité et de respect de la vie privée dès la phase de conception. La résolution ou l’atténuation de ces problèmes coûtent moins cher lorsqu’elles sont réalisées au tout début du projet. L’équipe ne doit pas reporter la prise en compte des problèmes de sécurité et de respect de la vie privée à la fin du développement.

Implémentation simplifiée de Microsoft SDL 10

Par ailleurs, l’équipe doit comprendre la différence entre « fonction de sécurité » et « fonction sûre ». Il est tout à fait possible d’implémenter une fonction de sécurité qui n’est pas sûre. Une fonction sûre est conçue en plaçant la sécurité au cœur de son développement. Par exemple, les données sont validées de façon rigoureuse avant d’être traitées, et les technologies de cryptographie employées sont parmi les plus robustes. Une fonction de sécurité est une fonction qui a des implications dans le domaine de la sécurité, comme une authentification Kerberos ou un pare-feu.

La définition des exigences lors de la conception implique un certain nombre d’actions obligatoires. Par exemple, il s’agit de définir les spécifications techniques de sécurité et de respect de la vie privée, d’analyser ces spécifications et de définir les exigences minimales en termes de cryptographie. Les spécifications techniques décrivent les fonctionnalités de sécurité et de respect de la vie privée qui seront directement exposées aux utilisateurs, comme demander une authentification de l’utilisateur pour accéder à certaines données ou obtenir le consentement de l’utilisateur avant d’utiliser une fonction présentant un risque élevé dans le domaine de la vie privée. De plus, les spécifications techniques doivent décrire comment implémenter de façon sûre les fonctionnalités décrites. Il est conseillé de valider les spécifications techniques en les rapprochant des spécificités fonctionnelles de l’application. Les spécifications fonctionnelles devraient :

Décrire de façon complète et précise l’utilisation prévue d’une fonctionnalité. Décrire comment déployer la fonctionnalité de façon sûre.

Activité SDL 6   : Réduction de la surface d’attaque La réduction de la surface d’attaque est étroitement liée à la modélisation des menaces bien qu’elle résolve des problèmes de sécurité selon une perspective différente. La réduction de la surface d’attaque est un moyen de diminuer les risques en offrant moins d’opportunités aux attaquants pour exploiter une faiblesse potentielle ou une vulnérabilité. Cette technique retire certains services ou en restreint l’accès, applique le principe de moindre privilège et emploie plusieurs niveaux de défense chaque fois que cela est possible.

Activité SDL 7   : Modélisation des menaces La modélisation des menaces est employée dans des environnements où il existe un risque sérieux de sécurité. L’équipe de développement prend en compte, documente et étudie les implications de la conception dans le domaine de la sécurité, dans le contexte de l’environnement opérationnel prévu, et de façon structurée. La modélisation des menaces permet aussi de prendre en considération des problèmes de sécurité au niveau de l’application ou d’un composant. C’est un travail d’équipe impliquant les chefs de projet, les développeurs et les testeurs. La modélisation des menaces représente la principale tâche d’analyse de la sécurité effectuée au cours de la phase de conception du logiciel.

Implémentation simplifiée de Microsoft SDL 11

Une exception formelle ou une méthode de report de bogue

doit faire partie de tout processus de développement

logiciel. De nombreuses applications exploitent encore

du code de conception ancienne et il peut être nécessaire de

reporter certaines mesures de sécurité ou de respect de la vie privée en raison de contraintes

techniques.

La meilleure méthode pour modéliser les

menaces est d’utiliser l’outil SDL Threat

Modeling Tool. Il est basé sur la

classification des menaces STRIDE.

Phase 3 : Implémentation

Activité SDL 8   : Utilisation d’outils approuvés Toutes les équipes de développement doivent définir et publier une liste d’outils approuvés et leurs contrôles de sécurité associés, comme les options du compilateur / éditeur de liens et leurs messages d’avertissements. Cette liste doit être approuvée par le conseiller en sécurité de l’équipe projet. De façon générale, les équipes de développement doivent s’efforcer d’utiliser la dernière version des outils approuvés afin de tirer parti des fonctionnalités et protections les plus récentes dans le domaine de la sécurité.

Activité SDL 9   : Retrait des fonctions peu sûres Beaucoup de fonctions et d’API ne sont pas sûres dans le contexte des menaces actuelles. Les équipes doivent analyser toutes les fonctions et les API qu’elles utilisent dans le cadre du projet, et écarter toutes celles jugées peu sûres. Lorsque la liste des fonctions interdites est établie, les équipes doivent utiliser des fichiers d’en-tête (comme banned.h et strsafe.h), des compilateurs récents ou des outils d’analyse du code pour vérifier leur code (y compris le code ancien réutilisé) et détecter l’utilisation des fonctions interdites. Il reste alors à remplacer ces fonctions par des alternatives plus sûres.

Activité SDL 10   : Analyse statique Les équipes du projet doivent effectuer une analyse statique du code source. Cette analyse fournit les faits et données pour la revue de sécurité du code et aide à vérifier que les stratégies pour un code sûr sont respectées. Toutefois, la seule analyse statique du code est généralement insuffisante et ne remplace pas une revue manuelle du code. L’équipe de sécurité et les conseillers en sécurité doivent connaître les forces et les faiblesses des outils d’analyse statique pour savoir les compléter par d’autres outils ou par une revue manuelle.

Phase 4 : Vérification

Activité SDL 11   : Analyse dynamique du programme Exécuter le programme est bien sûr nécessaire pour vérifier que les différentes parties du programme fonctionnent comme prévu. Cette tâche de vérification doit préciser les outils utilisés pour contrôler le comportement de l’application vis-à-vis de la corruption mémoire, de problèmes de privilèges utilisateur et d’autres problèmes de sécurité importants. SDL utilise des outils comme AppVerifier et des tests par injection de fautes aléatoires.

Activité SDL 12   : Tests par injection de fautes aléatoires Les tests par injection de fautes aléatoires constituent une forme d’analyse dynamique. Ils créent des pannes en introduisant de façon volontaire des données mal formées ou aléatoires dans une application. La stratégie de ces tests dépend de l’utilisation prévue de l’application, des spécifications fonctionnelles et techniques de l’application. Le conseiller en sécurité peut exiger des tests supplémentaires ou accroître la portée et la durée de ces tests.

Implémentation simplifiée de Microsoft SDL 12

En général, les équipes de développement décident de la fréquence optimale pour

réaliser des analyses statiques, afin de trouver un

bon compromis entre productivité et sécurité.

Activité SDL 13   : Revue de la surface d’attaque et de la modélisation des menaces Il arrive fréquemment qu’une application s’écarte des spécifications fonctionnelles et techniques définies pendant les phases d’exigences et de conception, au début du projet. Par conséquent, il est très important de revoir les modèles de menaces et la surface d’attaque lorsque l’écriture du code est terminée. Cette revue vérifie que toute modification dans la conception ou l’implémentation a été prise en compte, et que les nouveaux vecteurs d’attaque qui pourraient résulter de ces modifications ont été analysés et contrés.

Phase 5 : Diffusion

Activité SDL 14   : Plan de réponse aux incidents Chaque développement logiciel soumis aux exigences SDL doit inclure un plan de réponse aux incidents. Même un logiciel qui ne possède pas de vulnérabilités connues au moment de sa diffusion peut être soumis à de nouvelles menaces et nécessiter des actions après sa diffusion. Le plan de réponse devrait inclure :

Une équipe d’ingénierie permanente, ou si l’entreprise ne peut pas s’équiper d’une telle ressource, un plan de réponse aux urgences qui peut monopoliser les responsables en communication, marketing, technique et direction qui constitueront les premiers points de contact en cas d’urgence.

Des contacts téléphoniques avec une autorité capable de prendre des décisions, disponibles 24 heures sur 24, 7 jours sur 7.

Des plans de sécurité pour le code en provenance d’autres groupes dans l’entreprise. Des plans de sécurité pour du code externe sous licence, incluant noms de fichiers,

versions, code source, informations de contact externe et permission contractuelle d’apporter des modifications si nécessaire.

Activité SDL 15   : Analyse finale de la sécurité L’analyse finale de la sécurité (ou FSR - Final Security Review) est un examen approfondi de toutes les activités de sécurité effectuées sur un logiciel avant sa diffusion. Cette analyse est effectuée par le conseiller en sécurité avec l’aide de l’équipe de développement et des responsables de la sécurité et de la vie privée au sein de l’équipe. L’analyse finale de la sécurité n’est pas un exercice de pénétration et de correction. Elle ne permet pas non plus de réaliser des activités ignorées jusqu’à présent. Elle inclut l’examen des modèles de menaces, les requêtes d’exception, les rapports produits par les outils et le niveau atteint par rapport à l’échelle des bogues et au niveau de qualité précédemment définis. Trois résultats sont possibles :

Analyse réussie. Tous les problèmes de sécurité et de respect de la vie privée ont été résolus ou atténués.

Analyse réussie avec exceptions. Tous les problèmes de sécurité et de respect de la vie privée ont été résolus ou atténués et/ou toutes les exceptions ont été résolues de façon satisfaisante. Les problèmes qui ne peuvent pas être résolus (par exemple, des vulnérabilités impliquées par des conceptions anciennes) sont enregistrés et devront être résolus dans la version suivante.

Analyse avec remontée de problèmes. Si une équipe ne parvient pas à répondre à toutes les conditions SDL, et si le conseiller en sécurité et l’équipe produit ne parviennent pas à un compromis acceptable, le conseiller en sécurité refuse d’accepter le projet. Le projet ne peut pas, dans ces conditions, être diffusé. Les équipes doivent

Implémentation simplifiée de Microsoft SDL 13

répondre aux conditions SDL si elles le peuvent, ou remonter le problème à un niveau hiérarchique supérieur.

Activité SDL 16   : Diffusion/Archivage   : Si le processus SDL se termine correctement, la version peut être mise en production (RTM) ou mise en diffusion sur le Web (RTW). Le conseiller en sécurité responsable de la version doit certifier (via l’analyse finale de sécurité ou tout autre moyen) que l’équipe a répondu à tous les critères de sécurité. De même, pour tous les produits dont un composant au moins a un impact sur le respect de la vie privée de niveau P1, le conseiller en vie privée doit certifier que l’équipe a répondu à tous les critères nécessaires.

De plus, toutes les données et les informations pertinentes doivent être archivées pour permettre la maintenance du produit. Cet archivage inclut toutes les spécifications, le code source, les binaires, les symboles privés, les modélisations des menaces, la documentation, le plan de réponse de secours, les conditions de licence et de maintenance pour tout logiciel tiers, et toutes les données nécessaires à la maintenance du logiciel.

Activités de sécurité optionnellesDes activités de sécurité optionnelles s’appliquent généralement lorsque le logiciel doit être utilisé dans des environnements ou des scénarios critiques. Elles sont souvent demandées par un conseiller en sécurité dans un cadre négocié d’exigences supplémentaires, afin de renforcer la sécurité de certains composants logiciels. Cette section présente des exemples de tâches de sécurité optionnelles et ne doit pas être considérée comme une liste exhaustive.

Revue manuelle du codeLa revue manuelle du code est une tâche optionnelle dans SDL. Elle est généralement pratiquée par des personnes très compétentes de l’équipe de sécurité et/ou par le conseiller en sécurité. Bien que les outils d’analyse puissent réaliser une part importante dans la découverte et le signalement des vulnérabilités, ils ne sont pas parfaits. Il en résulte que l’analyse manuelle est principalement centrée sur les composants « critiques » de l’application. La plupart du temps, elle est employée sur le code qui traite et stocke des informations personnelles identifiables. Elle est utile aussi pour des fonctionnalités importantes comme la cryptographie.

Test de pénétrationLe test de pénétration est une analyse de sécurité réalisée par des professionnels de la sécurité qui simulent les actions d’un attaquant. L’objectif est de découvrir des vulnérabilités potentielles résultant d’erreurs de codage, d’erreurs de configuration du système ou d’autres faiblesses d’un déploiement opérationnel. Les tests de pénétration accompagnent généralement des revues automatiques et manuelles du code afin d’approfondir l’analyse.

Analyse des vulnérabilités d’applications similairesInternet propose de nombreuses sources d’informations de qualité sur les vulnérabilités dans les logiciels. Dans de nombreux cas, l’analyse des vulnérabilités découvertes dans des

Implémentation simplifiée de Microsoft SDL 14

Tout problème identifié pendant les tests de pénétration doit être traité et résolu avant que le logiciel ne soit approuvé et diffusé.

logiciels analogues peut révéler des problèmes potentiels dans la conception ou l’implémentation du logiciel en cours de développement.

Autres exigencesAnalyse de la cause principaleBien qu’elle ne fasse généralement pas partie du processus de développement logiciel, l’analyse de la cause principale joue une part importante dans la sécurité logicielle. Dès la découverte d’une nouvelle vulnérabilité, une investigation doit être effectuée pour établir précisément où les processus de sécurité sont pris en défaut. Ces vulnérabilités peuvent être dues à de nombreuses causes comme une erreur humaine, une défaillance d’un outil ou une mauvaise stratégie. L’objet de l’analyse de la cause principale est de comprendre la nature précise de la défaillance. Cette information permettra de s’assurer que les erreurs de même type seront prises en compte dans les futures révisions de SDL.

Mises à jour régulières du processusLes menaces logicielles ne sont pas statiques. Par conséquent, le processus utilisé pour sécuriser un logiciel ne peut pas être statique. Les entreprises doivent exploiter les connaissances apprises à partir de l’analyse de la cause principale, les changements de stratégies et les améliorations dans la technologie et l’automatisation, et les appliquer à SDL selon un calendrier bien défini. En général, un calendrier annuel de mise à jour devrait suffire. L’exception à cette règle se produit lorsqu’un nouveau type de vulnérabilité est identifié. Ce phénomène nécessite une révision immédiate de SDL afin que des méthodes de résolution ou d’atténuation soient mises en place rapidement.

Processus de vérification de la sécurité de l’applicationLes entreprises qui développent des logiciels souhaitent vérifier que les processus de Microsoft SDL ont été suivis. L’accès à un développement centralisé et à des données de test favorise la prise de décision dans un nombre important de scénarios, comme pour la revue finale de sécurité, la gestion des exceptions aux exigences SDL, et les audits de sécurité. La vérification de la sécurité de l’application implique un certain nombre d’acteurs et de processus : Une application spécialement désignée doit être utilisée pour surveiller la conformité à

SDL. Cette application sert comme référentiel central pour tous les éléments SDL, en incluant (mais s’en s’y limiter) les notes de conception et d’implémentation, les modèles de menaces, les rapports des outils et les attestations. Comme pour toute application critique, elle doit mettre en œuvre un contrôle d’accès pour vérifier que : Seul le personnel autorisé peut exploiter l’application. Les rôles sont clairement séparés. Par exemple, un développeur peut utiliser

l’application et y transférer des données mais ne peut pas accéder aux fonctionnalités réservées aux conseillers de sécurité et de vie privée, aux responsables de la sécurité et aux testeurs.

Les responsables de la sécurité et de la vie privée au sein de l’équipe doivent vérifier que toutes les données nécessaires à un jugement objectif sont correctement classées dans cette application de suivi.

Les informations entrées dans l’application de suivi sont exploitées par les conseillers en sécurité et en vie privée pour créer le cadre d’analyse pour la revue finale de sécurité.

Implémentation simplifiée de Microsoft SDL 15

Les conseillers en sécurité et en vie privée sont responsables de la revue des données introduites dans le logiciel de suivi (y compris les résultats de l’analyse finale de sécurité et les autres tâches optionnelles de sécurité exigées par les conseillers). Ils certifient que toutes les exigences sont remplies et/ou que toutes les exceptions sont correctement résolues.

Ce document se concentre sur le niveau Avancé du modèle d’optimisation SDL ; à ce niveau, le processus de suivi doit déjà être évolué. Toutefois, les entreprises appliquant des processus moins sophistiqués ou disposant de moins de ressources (niveaux Basique et Standardisé du modèle d’optimisation SDL) peuvent appliquer un processus de suivi plus simple.

Il est important que le processus de suivi et de vérification collecte de façon précise :

Les exigences en sécurité et vie privée de l’entreprise (par exemple, pas de vulnérabilités connues dans la version finale).

Les exigences fonctionnelles et techniques pour l’application en cours de développement.

Le contexte opérationnel de l’application.Par exemple, si une équipe de développement crée une application de contrôle de processus qui doit s’exécuter dans un environnement critique, l’entreprise doit investir en temps et en ressources pour créer le processus de suivi et en assurer sa maintenance, afin de permettre des analyses objectives par les responsables en sécurité et vie privée, par les responsables de l’entreprise et par des tiers comme des auditeurs en conformité. Ignorer le processus de suivi conduit inévitablement à des problèmes, qui apparaissent généralement lors d’une urgence. Il est important de vérifier que des systèmes fiables sont en place pour répondre à des questions critiques dans des délais très courts.

ConclusionL’objet de ce document est de fournir un cadre simple pour un traitement pragmatique des pratiques de sécurité dans le processus de développement logiciel. Il propose une série d’activités non propriétaires pour renforcer la prise en compte de la sécurité et de la vie privée. Combinées avec une automatisation efficace du processus et des conseils fiables, ces activités représentent les étapes nécessaires pour qu’une entreprise puisse objectivement affirmer respecter Microsoft SDL au niveau « Avancé » du modèle d’optimisation SDL.

Le processus décrit dans ce document correspond au seuil minimal pour respecter la conformité à SDL. Mais SDL n’est pas figé. Les équipes de développement doivent exploiter ce document comme un guide pour mettre en œuvre SDL de façon appropriée en fonction du temps, des ressources et des pratiques métier de l’entreprise.

Les concepts techniques présentés ici sont généralement reconnus comme de bonnes pratiques de sécurité et ne sont spécifiques ni à Microsoft ni à la plateforme Windows. Ils sont applicables à d’autres systèmes d’exploitation, à d’autres plateformes matérielles et à d’autres méthodologies de développement. Même une approche par étape n’utilisant que quelques-unes de ces techniques devrait avoir une influence bénéfique sur la sécurité et le respect de la vie privée d’une application en cours de développement.

Implémentation simplifiée de Microsoft SDL 16

Certes, une simple orchestration des processus de sécurité peut conduire à des améliorations globales en sécurité et respect de la vie privée, qui transcendent la valeur de tâches séparées. Mais, en informatique, les menaces ont évolué depuis les scripts naïfs des premiers attaquants et se situent aujourd’hui au niveau du crime financier organisé et de batailles entre nations. L’évolution des menaces conduit à mettre en place une approche plus rigoureuse de la sécurité.

Microsoft SDL est disponible gratuitement pour améliorer la sécurité et le respect de la vie privée dans les logiciels. Il a déjà été appliqué à des centaines de programmes et à des millions de lignes de code en production. SDL se compose d’actions obligatoires à effectuer tout au long du développement, et il est suffisamment flexible pour permettre l’ajout d’autres techniques et stratégies, afin de créer une méthodologie de développement spécifique à l’entreprise qui l’utilise. La combinaison du processus, de formation et d’outils conduit à de nombreux avantages comme un logiciel plus sûr, une meilleure compétence technique, un projet sans surprise, et une baisse du risque à la fois pour l’entreprise et pour l’utilisateur.

Implémentation simplifiée de Microsoft SDL 17

Annexe A :Illustration du processus SDL

Implémentation simplifiée de Microsoft SDL 17