Actus

p. 06   CyberEnJeux : former les élèves à la cybersécurité… par la création de jeux !

Pentest

p. 12   Les (mauvaises) idées reçues sur la robustesse des mots de passe
p. 20   Plongée au cœur des interactions inter-applications sur Android

Réseau

p. 38   Déploiement opérationnel d’un starter kit du CERT : retour d’expérience et outils open source pour la surveillance proactive
p. 50   DOIP : sécuriser les diagnostics automobiles utilisant Internet Protocol (IP)

Code

p. 44   Attaque de modèles d’apprentissage : cas d’usage pour le contournement de la détection d’hameçonnage

Organisation & Juridique

p. 74   Vulnerability Management : utiliser l’IA pour réduire la charge mentale des équipes ?

Je n’aime pas les programmes de bug bounty. J’ai bien essayé de changer d’avis, mais rien n’y fait. Le modèle semblant convenir à d’autres, j’ai discuté avec des hunters satisfaits, des triagers compétents, et des RSSI comblés. Néanmoins, plus je suis exposé à ces programmes et moins mon opinion change. Peut-être parce que je n’ai pas eu les mêmes expériences qu’eux.

Plusieurs points me gênent fondamentalement dans ce modèle tant du côté des équipes de sécurité que des chercheurs.

Tout d’abord, l’illusion du test en continu. Je n’adhère pas à la promesse d’exposer son code ou son application à des hunters et de le faire tester en continu de façon efficace et à moindre coût. Sur le papier, c’est séduisant, mais, en pratique, l’équation repose sur des variables que l’on ajuste en permanence. Un peu plus de périmètres, pour attirer les hunters. Un peu moins de récompenses, pour ne pas trop dépenser. Le tout, avec la possibilité de mettre en pause le programme quand il devient trop efficace, ou trop coûteux.

Ensuite, l’illusion de la qualité. Les hunters sont nombreux, et leurs expertises variées. La qualité des rapports est tout aussi aléatoire, et les triagers, dont le travail est aussi ingrat qu’essentiel, ont la tâche difficile d’uniformiser la qualité de ce qui est présenté au client, sans forcément connaître le code ni le contexte métier. À la fin, les équipes internes doivent s’impliquer pour reproduire, comprendre, et évaluer l’impact réel.

Puis, l’illusion du coût. Le bug bounty est parfois présenté comme une alternative efficace et économique aux pentests. C’est faux. Le tri, la coordination et la remédiation coûtent très cher. Le modèle ne tient que parce que le périmètre est large et qu’une grande partie des rapports reçus est sans valeur. En pratique, on paye surtout pour gérer le bruit, et filtrer les vulnérabilités critiques liées aux CSP.

Et enfin, l’illusion du programme de divulgation des vulnérabilités : un bug bounty n’en est pas un. C’est même dangereux de les assimiler. Accepter de les confondre, c’est aussi accepter de ne pas recevoir une vulnérabilité pertinente si elle est hors périmètre. Et c’est surtout déléguer la priorité de ce qui compte à des acteurs externes. En tant que chercheur, je constate souvent cet amalgame et je me retrouve dans des discussions absurdes où je dois préciser que je cherche seulement à remonter une vraie vulnérabilité hors périmètre, sans chercher une quelconque récompense.

Le bug bounty peut convenir à certains. Je ne le conteste pas. Mais il faut arrêter de le présenter comme une solution miracle, comme un substitut à un pentest solide ou à une vraie politique de divulgation de vulnérabilités structurée. Une clé privée exposée reste une clé privée exposée. Un logiciel qui plante reste un logiciel qui plante. Aucun programme de bug bounty ne remplacera jamais une équipe de sécurité. C’est au mieux un outil parmi tant d’autres, au pire un bel emballage autour de problèmes que personne n’a vraiment envie d’affronter.

Guillaume VALADON  
@guedou – guillaume@miscmag.com