S’il n’y avait pas de vulnérabilités à mettre en face des menaces, il n’y aurait pas de surface d’attaque, donc pas de risques. Pas d‘incidents. Or, les vulnérabilités sont inhérentes à tout système d’information (SI). Si l’objectif d’en faire l’inventaire exhaustif est louable, il n’en reste pas moins difficile à atteindre dès que le SI devient complexe. Pour limiter les possibles conséquences graves des vulnérabilités, différents outils ont été développés pour les identifier tels que la veille, les techniques de scan, les tests d’intrusion, le Bug Bounty, les Red Team, les audits techniques, etc.

Au-delà de ça, il est intéressant de se poser la question de la posture à tenir face aux vulnérabilités : une fois qu’un chercheur a connaissance de vulnérabilités, comment communique-t-il auprès des organismes concernés, par exemple à travers une politique de full disclosure ? Retour sur une conférence organisée récemment par le CLUSIF.

Connaître ses vulnérabilités pour mieux se protéger : RETEX d’un hébergeur cloud

Le recours à des opérateurs de services cloud pose des problèmes spécifiques pour la sécurité des systèmes d’information :

  • Le nombre de serveurs et d’équipements à protéger ;
  • La très grande diversité des technologies à maîtriser et sécuriser ;
  • L’empilement de couches matérielles et applicatives interdépendantes ;
  • La forte exposition du système d’information dans la mesure où il est directement accessible sur les réseaux via des portails, API, machines virtuelles, etc ;
  • Les responsabilités partagées entre le client et le fournisseur d’infrastructures ;
  • La mutualisation d’environnements multi-clients répondant à des objectifs différents ;
  • L’interruption quasi-impossible des services cloud garantissant une forte disponibilité dans le Service Level Agreement (SLA).

Dans ces conditions, un système d’information tributaire des services cloud est fortement exposé aux attaques et les opérations pour limiter les vulnérabilités sont complexes à organiser. Pour Olivier Perrault, RSSI chez Orange Cloud for Business, la solution réside dans la mise en place d’une organisation interne robuste reposant sur :

  • La veille sur les vulnérabilités en focalisant les moyens d’analyse selon la stratégie retenue et en utilisant des outils d’agrégation évitant de devoir se fier uniquement au buzz ;
  • Le déploiement d’une ingénierie pour analyser et valider des scripts et guides d’implémentation, requalifier la criticité des vulnérabilités et fournir des environnements durcis. Cette étape est coûteuse car elle nécessite d’avoir du personnel qualifié et des environnements de test à disposition. Elle permet cependant de réduire les risques opérationnels et de ne pas se fonder uniquement sur les seuls guides des éditeurs ;
  • Le scan des vulnérabilités sur l’ensemble du parc informatique permettant d’avoir une vue d’ensemble du niveau de risque et d’orienter la stratégie de patch globale. Cette méthode permet d’identifier les systèmes effectivement vulnérables sans réaliser un inventaire parfait ;
  • Les tests d’intrusion pour toute nouvelle application afin de ne pas se limiter aux seuls outils automatiques. Cette politique impose de disposer d’une équipe de pentesters, d’anticiper l’étape du test dans les calendriers de production et de travailler en collaboration avec les développeurs pour identifier les mauvaises pratiques ;
  • Le scan automatique de toutes les applications adapté pour les releases mineures et s’intégrant aux pratiques devops.

En conclusion, Olivier Perrault précise que l’exigence d’exhaustivité dans l’évaluation des vulnérabilités demande un effort important et une expertise des technologies et de la sécurité en interne. Cela renforce la confiance dans le système d’information, la réactivité face aux attentes des clients et l’autonomie dans le déploiement des stratégies d’assurance qui permet d’éviter des crises graves de sécurité.

Le Bug Bounty aujourd’hui et demain

Pour Clément Domingo, aka SaxX, pentester le jour chez Sopra Steria et chasseur de bug bounties la nuit, les programmes de bug bounty incitent les hackeurs éthiques à signaler les vulnérabilités qu’ils ont identifiées aux organisations concernées contre une rémunération.

Réputés efficaces et peu coûteux pour identifier les vulnérabilités d’un système d’information, les programmes Bug Bounty ont connu leurs prémisses en 1994 lorsque Netscape a promis une rémunération à toute personne qui lui remonterait une faille de sécurité. En 2007, la fondation Mozilla a sollicité les hackeurs pour identifier des failles de sécurité dans son navigateur Firefox. Entre 2010 et 2012, ce fut au tour des GAFA de lancer des programmes Bug Bounty contre récompense en interne. Enfin, le Département de la Défense des États-Unis a décidé d’ouvrir au public son programme Bug Bounty en 2016, ce qui fait état d’une évolution des mentalités sur ce sujet.

L’expérience de chasseur de Clément Domingo lui a permis de constater que les mœurs deviennent de plus en plus favorables au Bug Bounty : le recours à ces solutions par les entreprises est croissant et les compétitions entre hackeurs se multiplient. Il regrette cependant que les événements organisés ne soient pas plus nombreux pour asseoir cette nouvelle pratique et encourage au partage d’informations plutôt qu’au maintien de la culture du secret.

Clément Domingo conseille à toute organisation qui souhaiterait lancer un programme Bug Bounty de définir précisément son périmètre, de décider si le programme doit être intégré à une plateforme ou managé en interne et s’il doit être public ou privé. Il lui semble opportun de commencer par un programme privé de façon à vérifier si l’équipe interne a les capacités de trier les vulnérabilités soumises et de les corriger. Une grille de rémunération doit également être accessible afin de motiver les chercheurs et de leur préciser s’ils seront récompensés au moment où la vulnérabilité est trouvée, acceptée ou résolue.

En tant que chasseur, Clément Domingo encourage les hackeurs à tester leurs compétences sur les plateformes Bug Bounty en se montrant persévérant car les échecs sont nombreux. Il souligne qu’un chercheur doit rester humble même s’il est talentueux et cultiver de bonnes relations avec le manager du programme Bug Bounty afin de mieux orienter ses recherches. Il lui semble enfin primordial de retranscrire les vulnérabilités identifiées de façon claire afin que l’équipe interne puisse les évaluer facilement et récompenser les chercheurs en conséquence.

Sur le modèle du site Cyberexcuse, Clément Domingo narre enfin quelques cas concrets de vulnérabilités qu’il a été en mesure d’exploiter afin d’acheter des produits gratuitement sur une e-boutique à l’aide d’un proxy, de cartographier tous les sites d’une entreprise grâce aux adresses IP recueillies lors d’une attaque SSRF, de récupérer tous les fichiers d’une base de données suite à une injection SQL avancée ou de prendre la main sur un système après avoir intercepté des mots de passe basiques de type admin.

La divulgation des vulnérabilités pour fédérer

La coopération est au cœur de la divulgation des vulnérabilités pour Guillaume Vassault-Houlière, CEO de YesWeHack. Il rappelle qu’elle est définie dans la norme ISO/CEI 29147 comme « un processus par lequel les fournisseurs et les personnes qui découvrent des vulnérabilités peuvent travailler en collaboration pour trouver des solutions qui réduisent les risques associés à une vulnérabilité. » La norme ISO/CEI 30111 précise quant à elle la procédure qui permet de coordonner les différents acteurs intervenant dans l’identification et la résolution d’une vulnérabilité, à savoir :

  • Le chercheur qui identifie la vulnérabilité ;
  • Le rapporteur qui avise le fournisseur de son existence ;
  • Le fournisseur qui créé ou entretient le produit vulnérable ;
  • L’administrateur système qui déploie des mesures correctives ;
  • Le coordinateur qui fédère la communauté.

Le concept de remontée coordonnée de vulnérabilité (CVD) a émergé pour réduire au minimum le risque en veillant à ce que les vulnérabilités identifiées soient prises en compte. Pour cela, il est nécessaire que suffisamment d’informations soient fournies aux entreprises pour évaluer la criticité des vulnérabilités de leurs systèmes. La CVD repose sur la croyance aux bonnes actions de bons samaritains, le respect de la déontologie et la stimulation de la coopération grâce aux récompenses des hackeurs sous forme de rémunérations, goodies ou inscription au Hall of Fame. Cette méthode favorise l’apprentissage en s’inspirant de la boucle OODA, ce qui permet d’éviter de trouver des vulnérabilités par hasard.

L’Europe est en avance dans l’adoption de la CVD même si les discussions sont toujours en cours.

La création de canaux de confiance est primordiale pour cadrer le processus de remontée des vulnérabilités et éviter que les chercheurs soient assimilés à des hackeurs malveillants. Diverses méthodologies existent, parmi lesquelles :

  • La Responsible Disclosure Policyqui précise les modalités de communication des vulnérabilités par mails cryptés en PGP, le délai de réponse de trois mois et le système de récompense pour les vulnérabilités qui n’ont pas déjà été rendues publiques en fonction de leur sévérité évaluée par le CERT ;
  • txtqui permet de transmettre des vulnérabilités en renseignant différents champs dans un draft RFC (contact, encryption, acknowledgements, policy, hiring…) ;
  • Les programmes Bug Bounty assimilés à de la crowd security dans la mesure où ils font appel à une communauté pour identifier des vulnérabilités sans contrainte de temps et contre rémunération ;
  • L’article 47 de la loi pour une République numérique (2016) qui cadre les règles de soumission des vulnérabilités en légitimant l’absence de poursuites pénales pour les personnes de bonne foi tout en garantissant leur confidentialité ;
  • com qui permet de transmettre les vulnérabilités via un système décentralisé reposant sur la blockchain.

RETEX d’une plateforme web

Confronté à un incident en décembre 2016, Dailymotion a déclenché un programme Bug Bounty privé afin d’identifier la vulnérabilité en cause. Malgré des remontées intéressantes, le programme a été mis en pause en l’état en sortie de crise car cet outil n’a pas permis de répondre à l’objectif ciblé et que l’équipe interne n’avait pas assez de ressources pour traiter toutes les soumissions dans un délai raisonnable.

Le programme initial a par la suite été réactivé en systématisant le tri des tickets, en réévaluant la sévérité des failles de sécurité et en vérifiant leur remédiation.

Un nouveau programme Bug Bounty privé intégré à un plan d’assurance sécurité a été lancé lors de la refonte complète du site Dailymotion. En formalisant les objectifs, le règlement et les rémunérations, le programme a permis d’obtenir des soumissions de qualité contribuant à l’amélioration du site de manière agile et de retarder la réalisation d’un audit technique exhaustif à un stade de développement plus avancé. Le Bug Bounty s’est dès lors inscrit dans une véritable démarche de gouvernance globale.

Quentin Berdugo, Chief Information Security Officer de Dailymotion, explique que l’ouverture du programme Bug Bounty au public a nécessité de clarifier le périmètre, les attentes et les rémunérations dans le règlement, d’anticiper la charge de travail pour les équipes internes et d’accompagner le lancement du projet par un plan de communication. Lorsque le programme est arrivé à maturité les équipes ont choisi de diversifier les communautés de chercheurs, de les orienter sur des périmètres spécifiques et de les motiver grâce à des rémunérations au forfait les incitant à se familiariser avec les couches profondes de l’application.

Le Bug Bounty est un outil supplémentaire à la disposition du RSSI qui complète mais ne remplace pas les approches existantes. Il se caractérise par :

  • Une structure de coûts difficilement prévisible qui peut néanmoins se révéler rentable et efficace dans la mesure où seuls les résultats sont rémunérés ;
  • Le soutien nécessaire par une équipe interne qualifiée afin d’évaluer la pertinence des soumissions et de pouvoir corriger les vulnérabilités rapidement ;
  • L’orientabilité limitée des recherches malgré la possibilité de définir des périmètres ciblés ;
  • L’inadaptabilité de cette méthode pour scanner des domaines particulièrement sensibles ou qui nécessiteraient des connaissances métier approfondies ;
  • L’efficacité du dispositif attirant une multiplicité de talents aux approches très pragmatiques.

Le devoir de transparence envers la communauté des chercheurs est essentiel afin de respecter le travail effectué. À cette fin, il est conseillé :

  • D’établir un règlement complet et intelligible qui explicite les attentes et les interdits ;
  • De faire preuve de réactivité dans le traitement des soumissions, la correction des failles et le versement des primes.
  • D’expliquer la logique qui préside à l’évaluation de la sévérité des vulnérabilités en encourageant par exemple les chercheurs à apporter la preuve de l’impact des failles de sécurité sur les applications métier.

Les bonnes pratiques imposent en revanche de considérer les chercheurs comme des intrus en déclenchant par exemple les procédures de vérification des journaux ou de rotation des secrets dès qu’ils sont repérés afin de garantir la sécurité.
Si une organisation n’a pas les moyens de déployer un programme Bug Bounty, il est recommandé au minimum de définir une politique de divulgation, de la publier dans un security.txt et de disposer d’une adresse security@ dédiée au recueil des soumissions.