Non je n'ai pas oublié mes fidèles lecteurs et non il ne m'est rien arrivé de grave, pas d'inquiétude. Deux mandats exigeant des bons gros rapports combinés à une météo particulièrement procrastinatrice ont simplement eu raison de ma plume blogueuse!

Avant de revenir au traitement de l'actualité, je reviens donc sur cette seconde journée de l'OWASP Appsec Research 2010, qui je le rappelle réunissait des experts et chercheurs venus de tous coins présenter les résultats de leurs recherches dans le domaine de la sécurité logicielle.

L'une des trois thématiques majeures de cette seconde journée s'est focalisée sur un sujet que j'affectionne tout particulièrement: la gouvernance de la sécurité dans le cadre des projets de développement d'applications.



9 heures, SDL, le cycle de développement sécurisé de Microsoft: retour d'expérience


Steve Lipner (SL), directeur stratégique pour la sécurité des développements chez Microsoft, a su capter l'intérêt de l'audience quasi-intégrale de la conférence lors de son intervention sur le cycle de développement sécurisé mis en place chez Microsoft. Un récit passionnant, que je tente de retranscrire le plus fidèlement possible ici.


Chronologie avant 2000

Tout commence dans les années 80, années fastes durant lesquelles Microsoft, grâce à ses suites logicielles Windows et Office, explose littéralement les ventes et se positionne en leader mondial sur les marchés des systèmes d'exploitation grand public et des logiciels bureautiques.

A cette époque, la sécurité de l'information a déjà gagné les esprits d'une poignée de collaborateurs. La menace est essentiellement interne, les réseaux sont encore loin de l'interconnexion que nous connaissons aujourd'hui et la menace est essentiellement constituée d'experts techniques de haut vol, occupant généralement une position interne dans l'entreprise. Le modèle est majoritairement théorique: "il serait possible de" mais l'on manque de cas et d'exemples avec lesquels convaincre. La réponse la plus fréquente des managers: "personne ne ferait ça!", les entreprises n'accordent pas encore un intérêt réel à la sécurité de leurs informations.

Années 90: Internet se démocratise. L'on voit alors apparaître les premiers virus à propagation massive exploitant l'interconnexion des machines. Les premiers chercheurs de vulnérabilités logicielles créent des communautés au travers desquelles ils échangent, ou vendent, des techniques d'intrusion dont les entreprises n'imaginent aucunement la nature. Une culture réactive se met alors en place, en particulier via l'apparition des logiciels antivirus, possédant des listes de signatures de virus connus. La sécurité de l'information est alors totalement réactive.

C'est également le début des grandes douleurs pour Microsoft: l'envergure et la domination mondiale de l'éditeur attirent les chercheurs de vulnérabilités, qui s'acharnent alors littéralement sur ses produits pour y trouver des failles de sécurité. L'année 1995 sort définitivement les éditeurs logiciels de leur zone de confort: le groupe de chercheurs en sécurité informatique 8lgm publie un exploit (un mode opératoire décrivant les étapes pour une intrusion sur des systèmes vulnérables) sur la fameuse liste Bugtraq. Le texte est clair: la prise de contrôle à distance est possible sur tout serveur dans lequel est exécutée la dernière version du service de messagerie Sendmail.

L'effet est immédiat: la faille qui n'était jusque là comprise que par de rares personnes prend alors toute sa dimension dans l'esprit des autres chercheurs. La horde est lâchée. Elle s'attaque en particuliers aux éditeurs de logiciels centraux tels que Sun, Cisco et surtout...Microsoft.

Microsoft répond lentement et prend fréquemment plusieurs mois pour diffuser les correctifs. Le mécanisme de mise à jour automatique est encore révolutionnaire à cette époque. La réputation de l'éditeur est entachée et des entreprises commencent à adhérer au dogme "Unix est sécurisé, Microsoft est troué."

1999: Microsoft constitue une taskforce de sécurité pour ses logiciels. L'équipe n'a qu'un objectif: chasser les failles de sécurité en interne et les faire corriger avant que quelqu'un dehors ne les découvre. En 2 ans, l'équipe en trouve plusieurs milliers. L'éditeur pense avoir trouvé la solution à ses problèmes.



Années 2000-2001, retournement de situation: plusieurs failles de sécurité de niveau critique sont publiées chaque mois par les chercheurs. Les jours de l'année durant lesquels un système Windows est considéré comme 'protégé' se comptent sur les doigts de la main. Vous vous souvenez peut-être de iLoveYou (plus de $8 milliards de pertes pour les entreprises), Melissa ($5 milliards), Sadmind, Code Red (350'000 systèmes connectés à Internet infectés en moins de 12 heures, $2,6 milliards) et Klez ($9 milliards)? Tous ont lieu la même année. La réputation de Microsoft est détruite concernant la sécurité de ses produits.

Le concept des "security pushs" est initié. Tous les développeurs des produits sensibles sont formés au développement sécurisé. La modélisation de menaces a lieu en amont de projet. Des outils auditent chaque ligne de code pour vérifier l'existence de mauvaises pratiques de développement. La formation des développeurs est une première claque: "1 jour de formation!" On se rend compte que le nombre magique est plutôt 2 mois...


Premier modèle de développement sécurisé chez Microsoft: the Trustworthy Computing Initiative

15 janvier 2002, Bill Gates (directeur exécutif de Microsoft à l'époque) envoie un mémo à tous les collaborateurs de la société. Nouvelle priorité numéro un de l'éditeur: l'informatique de confiance. Les actes terroristes de 2001 sont cités. Bill Gates y décrit le concept de l'informatique de confiance comme un ensemble de trois contrats: sécurité de l'information, protection de la sphère privée et disponibilité des services. Tout collaborateur de la société doit faire le nécessaire pour y arriver.

En 2003, Microsoft observe l'ensemble des mesures investies et prend conscience de trois choses. Les besoins en matière de développement sécurisé ne sont pas prêts de s'estomper. Il faut un processus, formalisé et documenté. D'autre part, Microsoft constate que le plus grand retour a lieu lors d'interventions légères durant les phases de lancement et de conception des produits (activités de security requirements et threat modeling) alors que le marché propose une offre concentrée sur les phases finales des projets (tests d'intrusion). Finalement, Microsoft prend conscience de sa position de leader dans le domaine et qu'il est dans son intérêt que les autres éditeurs produisent eux aussi des logiciels mieux sécurisés.

L'ensemble des actions initiées par l'éditeur pour la sécurité des développements est alors consigné au sein d'un document intitulé "trustworthy computing security development lifecycle" et l'acronyme SDL apparaît. Constitué de 13 pages, une quinzaine de points de contrôle sont recensés. Le document restera interne durant une année, avant d'être publié lors d'une conférence en 2004.

Au même moment, Microsoft formalise son outil de classification du risque pour une application donnée: passé un certain niveau de risque, le projet doit être accompagné par l'équipe SDL.

Un an après la sortie officielle du système d'exploitation Windows Server 2003, premier développement opéré sur la guidance SDL, l'observation des métriques de vulnérabilités de sécurité indique déjà une nette amélioration de la situation: trois fois moins de vulnérabilités graves sont identifiées durant la première année.

Il est convenu que SDL sera amélioré une fois par année, et publié. La version actuellement disponible est la version 5.


Outils et standards: d'un départ chaotique...vers des outils fiables
L'un des principaux éléments de succès de SDL au sein de Microsoft, selon S.L., est le pragmatisme manifesté tout au long de la démarche. Tous les outils, standards et références ont démarré sur des concepts extrêmement simples, basiques et, accessoirement, truffés d'erreurs. Dans leurs premiers pas avec SDL, des feuilles Excel constitueront l'élément majeur de l'outillage de sécurité.

Les outils SDL
Microsoft a construit trois classes d'outils autour de SDL:
  • Les chercheurs de problèmes (problem finders)
  • Les outils de suivi de la conformité (compliance tracking tools)
  • Les outils de gouvernance, assistant l'équipe de sécurité dans sa collaboration avec les équipes produits (support tools)

SDL Agile

Lorsque SDL 3 est publié, le retour principal de la communauté est de reprocher à Microsoft de vouloir répandre une méthodologie trop ambitieuse et impossible à mettre en pratique au sein de petites structures de développement, dont les méthodologies de projet s'éloignent du traditionnel modèle en cascade et privilégient des modèles dits agiles, tels que XP ou Scrum. Avec plus de 30'000 développeurs, en effet, Microsoft a les moyens de mettre en oeuvre SDL dans sa définition la plus pure.

Microsoft complète alors successivement les versions 4 et 5 de sa guidance pour développer une version alternative de SDL, particulièrement adaptée aux petites structures, la version Agile.

Les nouveautés principales sont:
  • Une réduction significative du nombre d'activités à mettre en oeuvre (simplified SDL)
  • Un modèle prescriptif plutôt qu'un modèle descriptif, partant du constat qu'il ne faut pas chercher à faire de chaque développeur un expert en sécurité
  • Une distribution des activités optimisée pour les cycles de développement itératif (tâches obligatoires, tâches de cycle, tâches à réaliser une fois dans le projet, etc.)

L'adoption de SDL

La méthodologie SDL a été rendue publique lors de la publication de la version 3.2 du document de référence en avril 2008. La communauté ne la connaît donc que depuis un peu plus de deux ans, alors que Microsoft l'intègre progressivement l'année 2004.

Le site officiel ne propose aucun moyen de connecter les pratiquants. D'autre part, les entreprises et les recruteurs n'ont pas encore la maturité nécessaire pour identifier la connaissance de cette méthodologie comme un critère déterminant lors de la recherche de candidats. Finalement, l'on ne sait pas non plus quelles organisations développent leurs propres produits et lesquelles mettent en oeuvre un cycle de développement sécurisé. Dès lors, il est difficile d'évaluer la pénétration de cette méthodologie.

Microsoft ne sait que deux choses: le nombre de téléchargements du document de référence (que SL n'a malheureusement pas communiqué) et que les sociétés Adobe et Cisco ont récemment annoncé l'intégration du processus SDL au sein de leurs propres cycles de développement. Cisco en a d'ailleurs publié les détails sous l'acronyme CSDL (Cisco Security Development Lifecycle) et Adobe sous l'acronyme SPLC ('Adobe Security Product Development Lifecycle ').


Questions

Parmi les questions posées, l'inéluctable "comment faire lorsque l'on n'a qu'une petite structure de développement, disons de 1 à 10 personnes?" SL, très pragmatique dans son approche, a simplement recommandé 2 choses:
  • Se lancer et ne pas avoir peur de n'avoir qu'une simple feuille Excel avec une ou deux checklists pour commencer. Ne pas viser immédiatement la qualité du processus mais privilégier une approche "mieux ça que rien du tout"
  • Automatiser et standardiser un maximum: tout doit être soit sous la forme de checklists, soit automatisé au sein d'un exécutable.

Autre question posée: "qu'est-ce qui n'a pas fonctionné chez Microsoft? Quelles ont été les difficultés rencontrées lors de la mise en oeuvre du processus?"

Cette question était source de nombreux échanges sur le web déjà bien avant la conférence. Microsoft a publié son "état de l'art" mais n'a pas décrit les difficultés rencontrées pour y arriver. Ici aussi, très pragmatiquement, SL répond que quasiment tout a foiré. En cause: la lourdeur du processus, l'incapacité des outils à détecter les menaces et les erreurs, le manque d'expertise des développeurs et des questionnaires construits selon le sens du vent. SDL est une méthodologie issue de plusieurs dizaines d'itérations internes et il est illusoire pour une entreprise de vouloir simplement se calquer sur ce modèle et espérer pouvoir en tirer des bénéfices.


10 heures, Annonces OWASP




Dinis Cruz, membre du board OWASP, a profité d'une brève pause de 10 minutes pour communiquer un état des lieux sur les projets OWASP dans leur généralité.

Divers aspects ont été abordés, tels que:
  • Le financement des projets (bourses d'encouragement) et la possibilité de rétribuer leurs contributeurs directs
  • La mise en place d'un service d'annuaire qui permettra aux entreprises proposant des services basés sur les outils de l'OWASP de s'annoncer sur le site officiel
  • Quelques mots sur le projet O2, un framework d'outils destiné à intégrer et centraliser toutes les activités de gouvernance et opérationnelles destinées au maintien de la sécurité dans les projets de développement
  • La sélection des projets "core" qui serviront en quelque sorte de cobayes pour mettre en place le nouveau modèle de financement des projets OWASP.

10 heures 15, OpenSAMM (et autres)


Session présentée par Pravir Chandra, créateur d'OpenSAMM, une guidance de développement sécurisé du même acabit que la SDL de Microsoft, mais en moins prescriptif et beaucoup plus orienté vers l'adoption croissante plutôt que la présentation d'un modèle "fini et complet."

Je ne suis pas certain d'avoir entendu le contenu qui avait été annoncé dans le programme mais plutôt une réflexion sur des perspectives d'amélioration pour les cycles de développement sécurisés, dont OpenSAMM en particulier.


Quelles activités de sécurité faut-il mettre en oeuvre?

Toute activité de sécurité ajoutée dans le projet de développement induira inéluctablement un coût additionnel immédiat. D'autre part, l'expérience indique que certains projets sont plus bénéficiaires de l'exécution de certaines activités que d'autres.

Comment choisir ces activités? Quelle est la "couverture" de sécurité à mettre en oeuvre pour atteindre la meilleure rentabilité? Pourquoi mettre en oeuvre un test d'intrusion pour tel projet et pas pour un autre?

La version actuelle du modèle de gouvernance OpenSAMM traite la sécurité du développement dans sa globalité au sein de l'entreprise mais ne propose pas de réponse pour qualifier les besoins de sécurité relatifs à un projet parmi d'autres.
La réflexion est ouverte sur la manière de répondre à ce besoin dans une prochaine version d'OpenSAMM.



Métriques: faut-il se diriger vers une échelle de maturité telle que proposée par Cobit?

La mise en oeuvre d'OpenSAMM commence par une évaluation du cycle de développement de l'organisation (OpenSAMM assessment). La méthodologie proposée résulte en l'identification du degré de couverture d'une pratique donnée, représenté par une note allant de 0 à 3. Par exemple, l'activité "revue de sécurité du code" va pouvoir être notée de 0 à 3 selon la couverture assurée par le processus en oeuvre.

Cette approche n'a pas posé de problème particulier outre-Atlantique mais plusieurs analystes ont pu constater une certaine réticence quant à ce système de notation au sein des institutions européennes, qui préfèrent largement les évaluations échelonnées sur les modèles de maturité IT à 5 niveaux, tels que l'échelle Cobit.

Certains se sont amusés à convertir l'indicateur OpenSAMM vers une échelle Cobit par une simple opération arithmétique. Bien évidemment, cette approche est désastreuse dans la mesure où l'échelle OpenSAMM mesure l'excellence dans une activité donnée alors que l'échelle Cobit en mesure son degré de formalisation et d'intégration au sein des processus. Par conséquent, une activité de "modélisation de menaces" conduite régulièrement par des experts peut atteindre la note maximale au sein de l'échelle OpenSAMM, sans pour autant que le processus n'ait lui-même été documenté, ce qui induira une formalisation extrêmement faible sur une notation Cobit.

Question ouverte donc, que faut-il évaluer exactement et sur quelle échelle faut-il présenter les résultats?


Risques et impacts: il faut parler le métier!

Troisième constat et piste de réflexion: la classification des risques et des impacts. L'expérience indique que les experts communiquent encore trop sur des impacts techniques, et lorsqu'ils utilisent un jargon métier, restent trop génériques. Difficile donc de convaincre et d'obtenir du soutien lorsque les décideurs peinent à identifier les enjeux ou qu'ils sont difficilement quantifiables.

Bien que l'expertise sous-jacente soit la sécurité du système d'information, il devient de plus en plus important pour les interlocuteurs d'être capables de s'exprimer dans un langage compris de tous et ne demandant pas des connaissances en sécurité pour être compris.

Question ouverte: comment parler plus 'métier'? Les méthodologies doivent-elles prendre en compte cet aspect?


Quantification du revenu sur investissement

La majorité des indicateurs mis en oeuvre au sein d'organisations pratiquant le développement sécurisé sont considérés comme des indicateurs réactifs. A titre d'exemple, le plus fameux étant le nombre de vulnérabilités critiques identifiées dans les projets, par année et par unité fonctionnelle.

L'efficacité croissante d'un modèle de développement sécurisé a pour effet paradoxal de rendre de nombreux indicateurs réactifs complétement inopérants sur le long terme. Un compteur de vulnérabilités n'a de valeur que lorsqu'il baisse. Mais qu'en est-il lorsqu'il ne peut pas descendre plus bas?

Question ouverte: quels indicateurs privilégier lors de la mise en place d'un cycle de développement sécurisé lorsque l'on souhaite mesurer le ROI sur le long terme?


OpenSAMM vs. BSIMM vs. SDL
Trois cycles de développement sécurisé sont aujourd'hui considérés comme leaders au sein de l'industrie. Leur approche est respectivement différente, tout comme leurs indicateurs, leur courbe d'adoption et leur méthodologie de formalisation.

Où en sommes-nous sur ce point? Quel modèle est plus avancé? Ces modèles sont-ils complémentaires ou exclusifs?


11 heures: Utilisation de SDL au sein d'une équipe de développement agile


Session présentée par Nick Coblentz (NC), responsable du chapitre OWASP à Kansas City.


Le cycle de développement Agile

NC a commencé par présenter à l'audience les particularités du mode de développement Agile. Ce modèle de développement se caractérise par:
  • Des équipes de petite taille, allant de 2 à 10 personnes
  • Des cycles de développement intensifs et extrêmement courts ("sprints"), allant de quelques jours à quelques semaines
  • Des cycles de développement itératifs: chaque boucle produit une version utilisable du logiciel et les nouveaux ajouts sont déterminés en sortie de boucle
  • Les itérations sont pilotées par la sélection de scénarios que le client souhaite rendre possibles dans la prochaine version ("stories")
  • Le projet s'arrête lorsque le client n'a plus de "stories" à implémenter
  • Une documentation réduite, tout au long du projet, et très peu de documents de conception produits
  • Une communication essentiellement orale et privilégiant la proximité, à l'instar des 'stand-up meetings'
  • Finalement, des projets parfois destinés à servir plusieurs millions d'utilisateurs avant-même que l'on n'ait le temps de relire une fois le code

La problématique SDL

Dans le cas d'une équipe Agile souhaitant adopter un cycle de développement sécurisé tel que SDL, plusieurs problèmes se posent:
  • Les spécifications fonctionnelles évoluent extrêmement rapidement, continuellement et parfois, drastiquement (ex: décider soudainement de connecter le site à une centrale de paiement électronique). Un modèle de risques ou de menaces n'a donc généralement plus de valeur après une ou deux itérations du produit.
  • Les critères fondamentaux d'évaluation du risque sont eux aussi continuellement modifiés: la classification des données, leur source et leur destination change continuellement.
  • Les environnements de développement Agile n'ont généralement pas les moyens de s'offrir un expert en sécurité logicielle et les développeurs n'ont pas les connaissances requises pour assurer la double-casquette.


SDL: 23 documents à produire. Les équipes agiles peuvent-elles se le permettre?

SDL version 5: Simplified SDL for Agile development

La cinquième version de SDL se scinde en deux documents de référence. Le premier destiné à formaliser la méthodologie dans son intégralité et en vue d'une intégration dans les règles de l'art. Le second document s'adresse aux équipes Agile en proposant une approche de SDL spécialement adaptée à leurs besoins.

En premier lieu, SDL 5 sépare à présent les activités de sécurité en 3 groupes distincts:
  • Les tâches uniques (one-time tasks)
  • Les tâches régulières (sprint tasks), à accomplir à chaque itération
  • Les tâches "à faire une fois" (bucket tasks)

En second lieu, une importance beaucoup plus grande est accordée à l'automatisation des tâches, en particulier celles réalisées à chaque sprint, telles que l'intégration d'un outil d'analyse de code source dans le processus de compilation continue.


Tâches sprint

Pour chaque sprint, SDL recommande la mise en oeuvre de 18 points de contrôle, dont 4 ne sont pas de simples applications de bonnes pratiques.

La majorité de ces contrôles peut être effectuée par un script exécuté par exemple chaque soir sur la base de code.


Tâches uniques

Ces tâches doivent être complétées au moins une fois sur une durée donnée (3,6 ou 12 mois). L'on y trouve la constitution du plan de réponse en cas d'incident, l'identification de l'expert sécurité, la mise à jour des outils de développement et l'élaboration d'un modèle de menaces générique pour l'application.


Tâches à faire une fois (bucket tasks)

Ces tâches se concentrent sur des activités beaucoup plus techniques en général, telles que l'analyse de sécurité des composants COM et ActiveX au moyen d'un fuzzer (le fuzzing est une méthode de test logiciel).


Est-ce faisable et acceptable pour une entité de petite taille?

Sur ce point, NC est clair: si une tâche ne peut être complétée par le lancement d'un exécutable ou au moyen d'une checklist, elle n'est pas acceptable. Considérant cela, l'expert confirme que la majorité de la méthodologie SDL peut être intégrée au sein d'une équipe fonctionnant en mode agile. Les facteurs-clé de succès en résumé:
  • Des standards documentés (en particulier, la cryptographie)
  • Des interlocuteurs bien formés aux outils d'exécution des tâches SDL
  • Un processus d'intégration continue déjà rôdé, dans lequel seront ajoutés tous les contrôles automatisables de SDL:
    • Analyse de la configuration des compilateurs
    • Tests unitaires de sécurité
    • Analyse statique du code source
    • Analyse dynamique de vulnérabilités
  • Dans le cas de la détection d'un problème ayant été jugé comme de haut risque, le processus d'intégration continue doit échouer et contraindre à la correction immédiate du problème.
  • Ne pas documenter. Cela ne sert à rien (sic)

Démonstration: filtres anti injections XSS

NC a conclu la session en ouvrant un projet de développement .Net vulnérable à des attaques de type injection XSS (démos à l'appui).

Il a installé l'extension WPL (Web Protection Library) sur la machine et complété le projet pour y référencer les librairies nouvellement installées.

Après cela, NC a utilisé le moteur de recherche interne de l'outil de développement pour voir si la faille était présente à d'autres endroits dans le projet (analyse d'impact et de surface), d'autres zones du projet présentaient la même vulnérabilité.

Il a ouvert toutes les pages vulnérables et modifié le code pour qu'il passe par le filtre Anti-XSS, recompilé le projet et lancé la batterie de tests unitaires pour s'assurer de la régression.

Six failles de sécurité corrigées en moins de 15 minutes.


12 heures, Le programme de sécurité logicielle au sein de Dell


Séance présentée par Michael Craigue, coordinateur de l'équipe de sécurité logicielle au sein de Dell. Ici aussi, tout comme pour la session de Steve Lipner (Microsoft), la foule se présente en masse pour venir écouter un retour d'expérience rarement disponible.

Michael Craigue (MC) commence la session en annonçant que l'audience peut l'interrompre pour poser ses questions. L'auteur de la première question jugée particulièrement pertinente recevra un cadeau. Il n'en faut pas plus pour que la session se transforme après deux minutes seulement en une séance intensive de questions. Du coup, j'ai pris des notes en vrac, difficile de faire deux choses à la fois (pour un homme ;)...


Organisation

Dell dispose d'une entité dédiée à la sécurité des systèmes d'information. Plusieurs unités la composent:
  • Gestion des identités
  • Services légaux et analyses forensiques
  • Ingénierie et expertise
  • Deux autres unités dont je n'arrive pas à relire le nom...

La sécurité logicielle est gouvernée au sein du pôle ingénierie et expertise.


Premiers pas

Le projet application security débute en 2006. A ce stade, Dell compte plus de 3'000 développeurs distribués sur plusieurs centres de développement dans le monde, auxquels s'ajoutent jusqu'à 2'000 développeurs externes. Au total, plus de 10'000 applications sont en production au sein de la société.

Aucun standard de développement n'est défini, chacun y va du sien et aucun poste de travail ne ressemble à un autre. La première mission de l'équipe est de définir un standard.

L'équipe se concentre alors sur un projet de formation. Elle réalise que cela coûtera trop cher de créer les supports et d'organiser leur diffusion. Approche ultra-pragmatique: ils s'adressent à une entreprise ayant déjà créé tout les supports de formation pour ses développeurs et leur achètent les droits pour les réutiliser en interne. Un "crash-course" de 30 minutes est suivi par chaque développeur, au programme: présentation des menaces et de leurs contremesures. On leur annonce l'existence d'un portail web sur lequel ils peuvent aller poser des questions et la constitution d'une équipe dédiée à la sécurité logicielle.

Pour structurer son approche, Dell choisit de s'appuyer sur la guidance fournie par SDL. Sept processus sont activés:
  • Vérification de la conformité avec la réglementation en collaboration avec une équipe compliance
  • Contrôle systématique des conditions contractuelles lors de l'acquisition d'un logiciel pour les clauses de sécurité et revue par une équipe légale
  • Classification des données et classification globale du risque induit par l'application (au moyen d'un simple formulaire en ligne)
  • Analyse statique du code source
  • Signoff: l'équipe sécurité est un cosignataire des documents sensibles de projet. La signature n'est pas obligatoire mais sert d'assurance pour obtenir certains budgets.
  • Suivi des vulnérabilités: un outil de suivi des vulnérabilités à l'échelle de l'organisation est mis en place, il centralise toutes les vulnérabilités de sécurité identifiées dans toutes les applications Dell.

Opérations

A ce stade de maturité, l'équipe ACE (Application Consulting and Engineering) est constitué de 10 personnes (aujourd'hui encore) pour une base de 3'000-5'000 développeurs. Elle inclut des experts en sécurité applicative, des bases de données et des systèmes et réseaux.

L'équipe est dispersée à travers le monde (3 personnes réunies au Texas, 3 en Asie, le reste un peu partout). Une visioconférence au minimum est organisée chaque semaine. MC précise que l'une des plus grandes difficultés dans la coordination de l'équipe est de...la conserver. En effet, chacun de ses membres est régulièrement soumis à des offres d'autres entreprises et un effort tout particulier est mis en oeuvre pour s'assurer que ces collaborateurs soient heureux chez Dell.

Le second challenge particulier est de gérer les produits issus d'acquisitions diverses de sociétés par Dell.

L'équipe n'a pas le pouvoir de dire "non", la stratégie est essentiellement de:
  • 1) Suivre les projets sensibles et proposer du soutien aux équipes impliquées
  • 2) Développer et maintenir des outils afin d'automatiser les activités de sécurité au maximum
  • 3) Optimiser ses outils de qualification de risques

En 2008, 420 projets passent par l'équipe sécurité. 726 projets pour l'année 2009. Et plus de 200 projets ont déjà été intégrés dans le premier trimestre 2010.


La qualification des risques: Risk Modeler Tool

Comme indiqué plus haut, l'un des axes stratégiques majeurs de l'équipe sécurité est la constante amélioration de ses outils d'analyse de risques, en particulier, l'outil central "Risk Modeler Tool."

Cet outil se résume à un questionnaire en ligne, composé de 10 à 30 questions (ajustement dynamique) que doivent remplir le chef de projet et les éventuels bénéficiaires de l'application. Sur la base des réponses fournies, l'outil prend une décision:
  • Le projet sera suivi de près par l'équipe sécurité
  • L'équipe projet va prendre en charge la sécurité de manière autonome
  • Le risque est maîtrisé et acceptable, aucun suivi particulier n'est à mettre en oeuvre.

La pertinence des décisions de l'outil est régulièrement testée:
  • Des projets marqués comme non risqués sont réévalués en phase finale et testés afin de s'assurer que l'outil avait "raison"
  • À l'inverse, certains projets marqués comme risqués ne sont pas suivis puis des tests et revues intensifs sont déployés en phase finale pour vérifier s'il y aurait eu avantage à prendre en charge la sécurité dès le départ.

Après trois ans d'ajustement des questions l'outil fonctionne et permet à l'équipe d'opérer des tris extrêmement importants dans la sélection des projets à suivre de près ou non. Environ un quart des projets est classifié à risque élevé.

Nous avons demandé quelles questions composaient cet outil magique (imaginez la moitié de la salle tenant son stylo bien fermement à ce moment), MC a indiqué qu'il s'agit d'un élément confidentiel et qu'il ne divulguerait pas les questions. Toutefois, le choix s'opère entre autres sur les éléments suivants:
  • Quels types de données sont traitées par l'application?
  • Qui peut accéder à l'application?
  • Quelles réglementations et conformités sont en vigueur sur cette application?
  • Qui va développer l'application?

Après décision de l'outil, le projet est traité comme "non sensible", "auto-documenté" ou "accompagné."

Dans le cadre des projets dont la sécurité est auto-documentée, la guidance projet établie au sein du groupe requiert la production de certains documents et le suivi d'une série de bonnes pratiques tout au long du cycle de développement. A la fin du projet, l'équipe compliance a pour rôle de vérifier que les projets marqués en "auto-documenté" ont bel et bien suivi les standards en vigueur (culture audit, pas tests d'intrusion). Le cas échéant, ils sont dénoncés et peuvent faire l'objet d'un arrêt par le management.

Le non-suivi des directives peut entraîner des conséquences pour les chefs de projet, MC n'a pas souhaité fourni lesquelles exactement mais il est clair que les chefs de projet ont un intérêt direct à suivre les directives en matière de sécurité des applications.


Le financement du projet

Afin de convaincre de l'utilité de la constitution d'une telle équipe, des collaborateurs déjà intéressés par les problématiques de sécurité ont été sollicités. Ils connaissaient déjà les produits et parfois, les outils de recherche de vulnérabilités. A plusieurs reprises, des rapports de vulnérabilités ont été présentés au top management, par ces collaborateurs. Ils ont fini par céder et créer une entité à part entière.

L'origine de l'initiative pour la sécurité logicielle remonte au Directeur exécutif lui-même, décrit comme particulièrement visionnaire à ses heures et en lien étroit avec Microsoft à l'époque du lancement de SDL. Les moyens étaient disponibles, Dell avait subi plusieurs gros échecs en matière de sécurité et il a été décidé de se lancer également vers cette direction.


La documentation et les standards

Toute la documentation est essentiellement constituée de FAQs et de "fact-sheets" dont le contenu est indexé dans un moteur de recherche. Les fact-sheets décrivent un problème particulier et la manière de le solutionner. Il n'y a pas de "guidance générale" à proprement parler, si ce n'est que les développeurs doivent solutionner les problèmes de la façon recommandée dans la base de connaissances.

Toute question traitée par l'équipe de sécurité est transcrite au sein d'une FAQ ou d'une fact-sheet. Dell utilise un portail Sharepoint pour l'accès et l'archivage de la documentation.


Le bagage minimal

Tout développeur intégrant Dell doit suivre un cours "conception et développement de systèmes sécurisés" avant de pouvoir intervenir dans des développements.

Pour ce qui est des externes, le cours leur est disponible mais Dell s'appuie sur des conditions contractuelles particulièrement contraignantes en cas de non-respect des bonnes pratiques.


Indicateurs

MC reste vague sur ce sujet. Toutefois, Dell accorde une importance toute particulière à un indicateur: le nombre de vulnérabilités n'ayant pas atteint la production.


Activité: modélisation de menaces (threat modeling)

Au début, Dell a beaucoup cru dans la modélisation de menaces et a tenté de diffuser la pratique au sein des équipes de développement. La première difficulté a été de formaliser les diagrammes de type DFD (data-flows diagram) nécessaires à l'approche puriste de la modélisation de menaces. Seconde difficulté: même après de nombreuses formations, les équipes de développement n'arrivaient pas à détecter les menaces convenablement. L'activité était longue et coûteuse. Elle a été d'abord abandonnée puis reprise entièrement par l'équipe sécurité. Retournement de situation: les security champions peuvent formaliser les flux et voient les menaces bien plus rapidement que lorsque l'activité est réalisée par les équipes techniques elles-mêmes ; on en conclut que la compétence est difficile à transmettre et qu'il est encore difficile de la formaliser. Au lieu d'optimiser la transmission du savoir, Dell optimise son processus au sein de l'équipe sécurité pour le rendre le plus efficient possible.


Activité: analyse de code source

Dell effectue une revue de sécurité du code source de ses projets. L'orateur admet qu'il s'agit d'une activité chère mais Dell bénéficie de très bons arrangements pour rester dans une frange raisonnable de coûts.

Les vulnérabilités majoritairement identifiées sont des injections SQL et des failles XSS.

Encore.


Activité: tests d'intrusion

Peu après leur mise en oeuvre, Dell rencontre quelques problèmes avec les collaborateurs en charge d'effectuer les tests d'intrusion. La nature de l'organisation induit une certaine bureaucratie et inertie dans des projets (plus de 10'000 applications), que ces personnalités ne semblent pas du tout apprécier.

L'entreprise réussir à en trouver sur le marché mais ils quittent les uns après les autres, une zone grise que Dell n'a pas réussi à solutionner. Les tests sont alors externalisés.


Et la non-conformité?

Il a été précisé que l'équipe sécurité ne peut pas bloquer un projet, elle intervient à titre consultatif. Comment sont solutionnées les situations de haut risque dans lesquelles les recommandations ne sont pas impliquées?

MC décrit que dans le cas où des risques sont identifiés et que les responsables du projet ne prennent pas en considération les recommandations, un document est produit: "statement of non-compliance" (rapport de non-conformité). Ce document est diffusé à tous les VPs ainsi qu'une copie à l'autorité la plus haute de Dell (à qui l'équipe sécurité rend des comptes), le conseil d'administration.

Les risques sont formalisés et documentés, la décision est déléguée à ces derniers.


Comment évolue la méthodologie?

L'objectif prochain est d'intégrer le modèle proposé par OpenSAMM pour évoluer vers une vision hybride SDL/OpenSAMM, en particulier sur les aspects concernant l'évaluation de la maturité des activités de sécurité.


Conclusion et critères de succès

MC conclut sur les éléments suivants comme étant au coeur du succès du projet 'application security':
  • Ne surtout pas proposer un SDLC "sécurisé" révolutionnaire à une équipe de développement. La seule démarche viable est de s'asseoir et observer les habitudes de l'équipe et comprendre précisément comment il sera possible d'y intégrer de la sécurité.
  • Impliquer les membres de l'équipe sécurité dans les autres groupes d'influence, ne surtout pas les laisser "entre eux."
  • Accompagner un département à la fois. Ne pas arriver avec une gouvernance 'entreprise' que l'on va descendre dans chaque département. Commencer avec un département et conclure sur un succès. Rebondir ensuite sur le département avec le plus d'affinités, et ainsi de suite.
  • Ne pas perdre de temps avec ceux qui ne veulent pas aller de l'avant, se focaliser uniquement sur les interlocuteurs facilitateurs: l'équipe doit accompagner et surtout pas "chasing the bad guys." Je prends bien note de ce conseil.

Après-midi: OWASP leaders meeting


En ce qui concerne l'après-midi, je n'ai assisté à aucune session. Une séance de travail avait été organisée durant la pause de midi avec tous les leaders de chapitres et projets OWASP présents à la conférence. L'agenda de 45 minutes s'est rapidement transformé en un débat de plus de 3 heures sur divers aspects d'actualité au sein de l'OWASP. Pour moi, une occasion rare de pouvoir débattre avec des professionnels anglo-saxons sur des sujets particulièrement polémiques, très intéressant!!!

Bref, aucun feedback donc sur les sessions de l'après-midi: /



Conclusion personnelle


C'est la première fois que j'assiste à une conférence où l'on obtient un vrai feedback du terrain des opérations en matière de sécurité logicielle non pas par des consultants mais par des internes. Ayant occupé un tel poste durant ces deux dernières années, mon objectif était essentiellement de capter un maximum de retours durant la matinée de cette seconde journée. Pas d'hésitation sur ce point: ces retours d'expérience sont encore difficiles à obtenir tant les entreprises appliquant de tels processus et les personnes capables d'en parler sont rares.

Comme vous aurez pu le constater en lisant ces comptes-rendus, le feedback provient encore des grandes entreprises exploitant des structures de développement extrêmement complexes. J'imagine que nous verrons les premiers retours d'expérience d'organisations de taille plus modeste d'ici une à deux années.

Les professionnels de la sécurité logicielle doivent donc encore faire usage d'un certain pragmatisme, d'improvisation et d'astuce, pour trouver des compromis entre les recommandations des diverses méthodologies et les moyens que les petites et moyennes entreprises peuvent mettre en oeuvre pour se prémunir contre les risques.

D'ici à ce que l'on obtienne de vrais modèles de cycle de développement sécurisé éprouvés, n'oublions pas que la petite checklist planquée au fond d'une feuille Excel reste aujourd'hui encore une très bonne défense contre de nombreuses mauvaises surprises!

Sinon en ce qui concerne la ville de Stockholm en soi, ça valait le coup d'y jeter un oeil mais je recommande n'importe quel autre weekend de l'année que celui du Midsummer festival, car les rues sont toutes désertes, et dangereuses de surcroît, comme le montre l'image ci-après où je me suis pris un pot géant sur la tête!




Bon, sur ce, je me remets au boulot, j'ai une analyse de code à terminer là si je veux manger à la fin du mois! ;)




Pour les plus curieuses: