Les vulnérabilités sont inhérentes à tout système d’information. 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 potentielles 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.
Du fait de la complexité des systèmes d’information et, surtout, de la multiplicité des parties prenantes, la coopération s’impose pour mieux identifier et gérer les vulnérabilités. « La coopération est au cœur de la divulgation des vulnérabilités », estime Guillaume Vassault-Houlière, CEO de YesWeHack, qui est intervenu lors d’une conférence organisée par le Clusif (Club de la sécurité de l’information français), le 18 octobre 2018.
Ce principe de coopération est défini, par 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 à ces vulnérabilités. » 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é :
- 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é.
Quand la sécurité devient collaborative
Ainsi, le concept de remontée coordonnée de vulnérabilité (CVD) a émergé pour réduire au maximum le risque, en veillant à ce que les vulnérabilités identifiées soient prises en compte. Il est donc nécessaire que suffisamment d’informations soient fournies aux entreprises pour évaluer la criticité des vulnérabilités de leurs systèmes.
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.
Le Bug Bounty est un moyen proposé par de nombreuses plateformes et sociétés de développement de logiciels, grâce auquel des chercheurs en sécurité peuvent remonter des bugs, en particulier des vulnérabilités, et, ainsi, être reconnus, voire recevoir une récompense, pour chaque vulnérabilité trouvée.
Aujourd’hui, de multiples plateformes de Bug Bounty proposent une alternative pour tester légalement la sécurité d’une panoplie d’applications. Réputés efficaces et peu coûteux pour identifier les vulnérabilités d’un système d’information, les premiers programmes Bug Bounty sont apparus au milieu des années 1990, 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 hackers 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 une 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.
« C’est un autre moyen, pour les entreprises, de découvrir et de corriger des vulnérabilités avant que celles-ci ne tombent dans les mains d’une personne malintentionnée. Les applications peuvent être testées en continu, c’est l’entreprise qui décide de la durée du programme. L’entreprise rémunère le chercheur pour chaque vulnérabilité remontée et non pour le temps passé à la trouver », explique Cristhian Parrot, expert en sécurité et chasseur de bugs.
Il existe essentiellement deux types de programmes de Bug Bounty : public et privé. Les programmes publics sont ouverts à tous, ils sont souvent organisés par les entreprises elles-mêmes, les plus matures en terme de sécurité. Les programmes privés sont gérés par des plateformes de Bug Bounty qui se positionnent comme intermédiaires entre les chercheurs et les entreprises. Ils se limitent souvent à une communauté réduite de chercheurs.
Les chasseurs de bugs passent à l’action
Pour une DSI, le plus simple est de rentrer en contact avec une plateforme de Bug Bounty, en charge de cadrer le programme, de trouver les profils adaptés à la cible et de mettre à disposition de l’entreprise tous les moyens nécessaires pour qu’elle puisse suivre l’avancement et corriger les vulnérabilités. Avant de lancer un programme de Bug Bounty, il faut déjà avoir réalisé des tests d’intrusion pour l’application que l’on souhaite auditer.
Dans le cadre d’une application Web, il faudra fournir les URL à auditer. Lorsque le périmètre sera bien défini, on donnera l’autorisation à la plateforme pour déclencher le Bug Bounty. Ensuite, l’analyse démarre très rapidement avec les chasseurs de bugs sélectionnés pour ce programme.
Pour Clément Domingo, chasseur de bugs, qui a fait part de son expérience lors de la conférence du Clusif, « il convient de définir précisément le 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 suggère 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. Il est 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 », ajoute Clément Domingo.
« Dans la plupart des cas, les chasseurs de bugs trouveront très rapidement des failles sur le système en question. Une fois que les failles sont identifiées, les chasseurs de bugs produisent un rapport de vulnérabilité, avec le détail de la faille de sécurité. Ce rapport de vulnérabilité permet aux équipes en interne de corriger les failles remontées.
Les chasseurs de bugs ont moins de contraintes (durée, horaires, déplacements, conditions de réalisation, etc.) pour effectuer leurs recherches, comme on peut le constater sur les prestations classiques. Ils disposent donc de plus de temps pour tester des vulnérabilités et produire des codes d’exploitation (PoC) beaucoup plus complexes », détaille Cristhian Parrot.
Confronté à un incident en décembre 2016, Dailymotion, qui a témoigné lors de la conférence du Clusif, 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, car cet outil n’a pas permis de répondre à l’objectif ciblé. En outre, 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.
Bug Bounty et tests d’intrusion : quelle différence ?
Le Bug Bounty constitue un outil supplémentaire à la disposition du RSSI qui complète, mais ne remplace pas, les approches existantes, en particulier les tests d’intrusion classiques. Il devrait être mis en place sur des applications ayant déjà fait l’objet d’un ou plusieurs tests d’intrusion.
Lors d’un test, on cherche à être exhaustif, alors que dans le cadre d’un Bug Bounty, on se focalise plutôt sur l’exploitation de vulnérabilités importantes ou ayant un impact direct sur la cible, par exemple l’exécution d’un code malveillant à distance. Par ailleurs, un programme de Bug Bounty est souvent planifié sur une durée plus longue qu’un test d’intrusion classique.
Il ne faut toutefois pas se passer des tests d’intrusion, car ceux-ci restent beaucoup plus exhaustifs qu’un programme de Bug Bounty. Ils devraient être appliqués à chaque fois qu’il y a des changements importants dans le code d’une application. Le listage d’un nombre important de vulnérabilités et de non-conformités, quelles qu’elles soient, vis-à-vis des guides de sécurité et des référentiels connus, tel que l’OWASP (Open Web Application Security Project), permet d’augmenter le niveau de sécurité des applications et de rendre plus difficile l’exploitation de certaines vulnérabilités.
Jean-Marc Cerles, RSSI de Véolia, privilégie les tests d’intrusion répétés au Bug Bounty, car « ils représentent une charge de travail moindre et peuvent être déployés sur un périmètre restreint. En outre, il faut être capable à tout moment de mesurer le niveau de risque et de diffuser des alertes pour que le travail des équipes informatiques soit mieux compris et reconnu par la direction générale. »
Les caractéristiques du Bug Bounty
- 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.
Source : Clusif.
Les facteurs de risques du 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.
Les principales méthodologies
- La Responsible Disclosure Policy, qui précise les modalités de communication des vulnérabilités par e-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.
- Security.txt, qui permet de transmettre des vulnérabilités en renseignant différents champs.
- 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é.
- Zerodisclo.com, qui permet de transmettre les vulnérabilités via un système décentralisé reposant sur la Blockchain.
Quelle organisation mettre en place ?
Pour Olivier Perrault, RSSI chez Orange Cloud for Business, la solution réside dans la mise en place d’une organisation interne 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 les guides d’implémentation, requalifier la criticité des vulnérabilités et fournir des environnements durcis. Cette étape est néanmoins 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 identifie 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ées pour les releases mineures et s’intégrant aux pratiques DevOps.