Table of Contents
Le RSSI et le Lead OffSec de Veepee nous racontent la sécurité bien huilée de ce géant du commerce digital. Coup de projecteur sur les Hommes de l’ombre.
C’est quoi, Veepee ? Si l’on vous avait posé la question, vous nous auriez probablement parlé de la célèbre plateforme de ventes flash, de son logo rose flashy ou de votre dernière paire de baskets chinée en promo. Et vous auriez raison. On connait tous Veepee comme un acteur incontournable du commerce digital européen.
Mais il y a une facette de Veepee que l’on connaît beaucoup moins. Celle d’un groupe avec une culture tech historique, doublée d’une sécurité numérique qui s’essaie à rester exemplaire. Derrière le Veepee qu’on connaît tous, il y a vpTech.
“vpTech, c’est la volonté de créer une vraie communauté tech”
La communauté vpTech est née en 2016, de la fusion des différents groupes qui composent aujourd’hui Veepee. C’est une entité double : vpTech est la DSI du groupe Veepee, mais aussi une image de marque à part entière. Antonin Garcia, RSSI chez Veepee, témoigne :
“Avant, Veepee était une entreprise avec beaucoup de prestataires, qui avait intégré de nombreuses solutions. Puis il y a 7 ans, la décision a été prise de faire beaucoup d’investissements dans la tech. Pour embaucher énormément, faire un cloud en interne, créer une synergie et une marque commune pour regrouper les métiers tech du groupe Veepee… vpTech, c’est la volonté de créer une vraie communauté tech.”
Avec vpTech, Veepee a fait ce que beaucoup d’autres groupes n’ont pas réussi : intégrer la technologie dans l’ADN même de l’entreprise. L’entité délivre des solutions et des outils au reste du groupe, aussi bien prévus pour la plateforme e-commerce que pour les marques clientes et les prestataires. Concrètement, vpTech c’est :
- plus de 800 employés
- répartis dans 6 pays
- et utilisant plus d’une cinquantaine de technologies
Internaliser les développements pour s’approprier la sécurité des produits
Avoir sa propre flotte technologique interne permet alors une agilité et une appropriation de la sécurité des produits qui serait impossible autrement. Antonin, le RSSI, nous explique :
“Chez Veepee, les développeurs, SRE, architectes, Product Owners sont en interne et sont tous responsables de leurs produits. Donc quand on a une vulnérabilité, on n’a pas besoin d’ouvrir un ticket chez un presta ou un gestionnaire. On a vraiment le ownership du début à la fin ; du code, des applications, des serveurs, de tout.”
Veepee : une marque, plusieurs problématiques de sécurité numérique
La sécurité est un enjeu business majeur pour Veepee, dont la plateforme e-commerce enregistre 4.5 millions de visiteurs uniques et 130K€ de commandes chaque jour. Mais la surface d’attaque du groupe ne se cantonne pas à sa plateforme publique. Julien Reitzel est Lead Offensive Security chez Veepee. Il raconte :
“On a la plateforme e-commerce, mais derrière il y a beaucoup d’autres outils. Internes, mais aussi externes à destination des marques qui vendent sur Veepee. On a par exemple une marketplace, et depuis peu le service Re-cycle. Il y a donc un certain nombre d’activités et de sites qui ne sont pas à destination des membres mais orientés B2B. Tout ça mis bout à bout représente une surface d’attaque assez importante.”
Antonin Garcia seconde :
“On n’est pas seulement un acteur e-commerce. Notre CEO répète souvent qu’on fait du B2B2C, le cœur de métier c’est d’aider les marques à écouler leurs stocks en proposant des offres de qualité à nos membres. On a donc beaucoup de partenaires avec qui on discute et échange de l’information. Et évidemment, avec la partie e-commerce, on a droit à toutes les attaques classiques dès qu’on a une IP exposée. Une vulnérabilité sur une exposition publique, ça ne pardonne pas.”
Les problématiques de sécurité numérique sont donc variées pour le groupe, qui a :
- une plateforme e-commerce exposée publiquement ;
- une flotte de 800 techs chez vpTech qui travaillent à déployer des solutions technologiques pour l’interne et l’externe ;
- un écosystème de partenaires et de marques, source d’échange d’informations.
Pour faire face à ces différents défis, Veepee s’est doté de sa propre équipe de sécurité interne au sein de vpTech. Un choix qui s’inscrit pleinement dans la stratégie d’internalisation de la tech. Après tout, on n’est jamais mieux servi que par soi-même.
Veepee : une équipe de sécurité interne divisée en quatre pôles
L’équipe sécurité chez vpTech se compose d’une dizaine de personnes, réparties en quatre pôles :
- le pôle InfoSec (Information Security), en charge de la GRC (Gouvernance, Risque et Conformité) ;
- le pôle SOC (Security Operations Center), qui porte sur la gestion des logs, la gestion des alertes et incidents de sécurité. Bref, la détection des comportements suspects en interne ;
- le pôle OffSec (Offensive Security), qui gère la partie offensive – pentests, vulnérabilités, red team, gestion des programmes de bug bounty ;
- le pôle Ingénierie, avec des SRE qui portent des solutions et des projets d’architecture, en plus d’améliorer l’infrastructure des services utilisés en interne.
“Le plus gros défi du RSSI, c’est de trouver le bon équilibre entre la gouvernance, la défense, l’offensif et l’opérationnel quotidien des métiers.”
Cette segmentation des rôles s’explique en grande partie par la vision de la sécurité portée par Antonin, le RSSI du groupe :
“Avant de rejoindre Veepee, j’ai eu un parcours très orienté gouvernance et conformité. J’étais QSA (Auditeur de Sécurité Qualifié), et je faisais de la conformité PCI DSS dans des mondes très bancaires, très processés. Puis je suis arrivé chez Veepee, avec un IT totalement différent, presque celui d’une start-up.
On a tout de suite essayé de ne pas être dans la politique et la gouvernance, mais de faire quelque chose de très opérationnel. La gouvernance et les standards peuvent faire perdre de vue l’essence de la sécurité. A trop se cacher derrière des politiques et des process, on ne sait plus pourquoi on les fait. On se retrouve alors avec des trucs supers sur le papier, mais qui opérationnellement sont des gruyères. […] Je pense que le plus gros défi du RSSI, c’est de trouver le bon équilibre entre la gouvernance, la défense, l’offensif et l’opérationnel quotidien de l’ensemble des métiers.
Nous, on a commencé par la défense. On a créé un SOC, on a déployé nous-mêmes nos propres serveurs, on centralise les logs… Ensuite, on est passé sur de l’offensif. Aujourd’hui, on se retrouve à une dizaine de personnes et ça s’inscrit dans la culture de vpTech. On ne veut pas prendre de la presta pour former des gens qui partiront à la fin de leur mission. L’idée, c’est que la sécurité soit portée par des sachants en interne.
Gestion des incidents : “Être prêt, c’est surtout savoir s’entourer de gens compétents et responsables”
On ne le répétera jamais assez : une sécurité efficace se doit d’être proactive de bout en bout. Si la prévention et la détection des incidents sont indispensables, avoir un plan de réponse l’est tout autant. Là encore, Veepee fait figure d’exemple :
“Toute entreprise qui est exposée sur Internet se prend quelques breach dans l’année, c’est inévitable. Mais l’important ce n’est pas la breach, c’est la préparation. Il faut être préparé de façon à ce qu’elle soit la plus restreinte possible, et que les équipes soient les plus prêtes possible à y répondre mais surtout le plus rapidement possible.
Chez Veepee, on a la chance d’avoir une super équipe d’Incident Management. Ils ont développé tout le tooling en place, la méthodologie d’astreinte, et même des petits trucs tout bêtes comme un bot Slack qui aide à ouvrir des incidents opérationnels. On peut être très réactif, et activer les gens rapidement.
Si l’on se pose des questions une fois que la breach est arrivée, c’est un peu tard… Il faut mettre en place de la traçabilité, et beaucoup d’offensif. Mais être prêt, c’est surtout savoir s’entourer de gens compétents et responsables.”
– Antonin Garcia, RSSI chez Veepee
vpTech : penser la sécurité avec des équipes et technologies multiples
vpTech, c’est pas moins de 800 techs répartis dans 6 pays. L’internalisation d’une telle force de frappe technologique est un véritable atout pour le groupe. Néanmoins, la multiplication des équipes et des technologies vient avec son lot de défis en matière de sécurité numérique. C’est ce qu’explique Julien Reitzel, Lead du pôle Sécurité Offensive :
Ce qu’on voit en tant que client, que membre, c’est le site web ecommerce. Mais derrière veepee.fr, il y a un grand nombre d’équipes qui s’occupent des différentes pages. Certaines s’occupent de la partie création de compte et connexion, d’autres de l’affichage des ventes ou des paiements. Et il n’y a pas que le site .fr : Veepee est présent en Espagne, en Allemagne, en Italie…
Donc ça fait beaucoup d’équipes et de technologies différentes utilisées, d’autant plus que tout le monde n’a pas la même maturité. Et il y a toujours du legacy, et une partie Shadow IT comme dans toutes les boîtes, avec des personnes qui font leur tambouille dans leur coin.
Le contrôle par la centralisation et la responsabilisation
Comment s’assurer de la bonne sécurité des applicatifs produits quand les techs sont 80 fois plus nombreux que l’équipe de sécurité ? Un défi de taille pour le RSSI du groupe – mais comme il aime le dire, “même pas peur !” Antonin y a longuement réfléchi :
“Chez Veepee, l’équipe sécurité ne peut pas vérifier toutes les publications de toutes les applications. Pourquoi ? Car on est une dizaine face à 800 personnes qui produisent. On veut de l’agilité, et mettre du code en production rapidement. Alors on s’est posé pas mal de questions. Comment fait-on pour contrôler ? Pour interagir avec les dévs ?
L’idée de la sécurité, c’est qu’elle soit le plus près possible du métier, de la mise en production. On n’est pas sur un système de Change Management, de validation. Tout le monde est autonome, et on envisage la relation avec les développeurs autrement.
On utilise par exemple DefectDojo, un outil open-source vraiment super et fait par l’OWASP. Il standardise tous les inputs des outils de vulnérabilités. On a réussi à organiser tous nos tests à l’intérieur – pentest, red/purple team, bug bounty… Aujourd’hui, la collaboration avec les développeurs et les SRE se passe surtout via cet outil là.
Quand on trouve des vulnérabilités, peu importe d’où elles viennent, on les ajoute dans l’outil et les produits reçoivent un mail récapitulatif par mois avec un score. Les équipes sont objectivées sur un niveau de maturité, et l’idée est de gamifier un peu tout ça. Chaque produit a une note entre A et E, on essaie de les publier et ils l’incluent à leurs dashboards.”
– Antonin Garcia, RSSI
Sensibiliser les développeurs à la sécurité
Ce n’est pas tout de centraliser, il faut aussi éduquer. Chez Veepee, la sécurité passe aussi par la sensibilisation des corps de métier tech à la sécurité. C’est un sujet que Julien prend à cœur :
“L’équipe sécu fait partie de vpTech, de la DSI. On est dans la même communauté que les développeurs, mais il y a un nombre conséquent de produits et d’équipes. La relation qu’on entretient avec les dévs et les PO diffère donc d’un produit à l’autre. On est très proches de certaines équipes, et c’est forcément plus compliqué avec d’autres qui ont une culture sécurité moins développée. C’est donc essentiel de faire de la formation sécu auprès des développeurs. A l’origine, je suis même arrivé chez Veepee pour ça – avant de faire du pentest, j’étais moi-même dév. […]
On a notamment organisé des CTFs (Capture The Flag) en interne, avec des petites épreuves de sécurité à destination du public tech. Je me rappelle d’un coffre-fort qu’on avait mis dans notre bureau. Il fallait lui envoyer quelques instructions pour réussir à l’ouvrir. On avait mis des chocolats à l’intérieur pour le gagnant, c’était ludique. On avait eu pas mal de participations, et ça avait éveillé l’intérêt des gens.”
– Julien Reitzel, Lead OffSec
“On a remarqué que les vulnérabilités remontées par le bug bounty suscitent plus l’intérêt des équipes.”
Il y a quelques années déjà, Veepee a choisi de lancer un programme de bug bounty avec Yogosha. Outre ses objectifs premiers de détection des vulnérabilités, le programme a eu un effet inattendu en interne. Cette nouvelle forme d’audit a suscité la curiosité des développeurs, et renforcé leur investissement dans la remédiation des vulnérabilités identifiées par les hunters de la Yogosha Strike Force. Julien explique :
“Je ne m’y attendais pas forcément, mais on a remarqué que les vulnérabilités remontées par le programme de bug bounty suscitent beaucoup plus l’intérêt des équipes.
Comme tout le monde, on a fait des pentests avec des boîtes extérieures, qui nous produisaient un joli rapport PDF à la fin qu’on communiquait aux équipes concernées. Certaines prenaient ça en compte et faisaient les corrections rapidement. Mais avec d’autres, rien n’avait bougé un an ou deux après, et on découvrait exactement les mêmes vulnérabilités lors des nouvelles rondes de pentests.
On a rapidement vu que le bug bounty offrait une nouvelle dimension. Quand on dit qu’une vulnérabilité vient du bug bounty, ils se disent : “ ah, mais ça veut dire que n’importe qui sur Internet peut faire ça sur mon application ! Et en plus, on a dû payer quelqu’un pour avoir trouvé cette vuln en particulier. “”
Même son de cloche chez Antonin : “Parler de bug bounty, ça interpelle les corps de métier tech et non tech. Ils demandent ce que c’est, comment ça marche. Ça pour moi, ça a été une super victoire.”
Le bug bounty, une partie intégrante de la sécurité offensive chez Veepee
Si aujourd’hui tout se passe bien, Antonin, le RSSI, n’était pas rassuré à l’idée de se lancer dans l’aventure du bug bounty :
“Je n’avais jamais fait de bug bounty avant. Au début ça fait un peu peur, on se dit qu’on va autoriser des mecs à rentrer sans pouvoir se cacher derrière le légal. Puis c’était compliqué d’aller défendre ça au budget, alors que même moi je n’avais pas confiance. Je ne savais pas si on allait cramer le budget en 24h, 48h, deux semaines… Alors j’ai appelé quelques copains RSSI à droite à gauche, qui m’ont expliqué un peu ce qu’ils faisaient.
Finalement, on est parti directement sur *.veepee.fr – même pas peur ! Ce que j’ai trouvé vraiment bien, c’est qu’on peut gérer nos périmètres et les hunters invités, pour monter nous-mêmes en maturité. On a pu commencer avec très peu de hunters, avant d’augmenter au fur et à mesure. Le fait d’être sur un bug bounty privé, c’est aussi très agréable. On peut gérer la communauté et les personnes, c’est plus facile.”
Aujourd’hui, les choses ont bien changé. L’inquiétude des débuts a disparu, et le RSSI de Veepee ne regrette pas son choix :
“Je suis vraiment content du service Yogosha, et de l’accompagnement surtout. Pour moi, c’est obligatoire aujourd’hui de faire du bug bounty. On ne peut pas passer à côté, ça serait se voiler la face. Je pensais qu’on allait se dédouaner de faire du pentest, mais non, c’est toujours nécessaire. Le bug bounty s’est révélé être un nouvel outil, et un outil qui est pour moi indispensable.”
“Le bug bounty permet d’aller chercher les angles morts”
Le bug bounty s’intègre maintenant pleinement dans la stratégie de détection des vulnérabilités voulue par l’équipe sécu, en complément des autres tests.
“On sait faire du pentest, et les applications qui sont très exposées pour les membres, on les connaît. Mais le bug bounty permet d’aller chercher les angles morts, les petits services qui ne sont pas forcément maintenus ou avec moins de rigueur. ” explique Antonin.
Un constat secondé par Julien, à la sécurité offensive : “Grâce à Yogosha, on a déjà eu vent d’un certain nombre de périmètres, de sous-domaines et de serveurs exposés sur Internet qu’on n’avait pas eu l’occasion de regarder avant. Ça nous a permis de couper des choses dont on n’avait pas forcément conscience. “
Un bug bounty géré en interne
On l’aura compris, chez vpTech on aime faire les choses en interne. Et le bug bounty ne déroge pas à la règle. C’est l’équipe Offensive Security qui s’occupe de la relation avec les hackers et du triage des rapports. Un vrai plus selon Antonin : “ Puisqu’ils font du pentest, ils ont la finesse nécessaire pour jauger les vulnérabilités. Ils savent qualifier la criticité, et être dans le débat s’il y a désaccord avec un hunter. “
En ce qui concerne la relation avec les hunters de la Yogosha Strike Force, Antonin prône la discussion.
“On reste toujours très cordiaux. Puis la sécurité c’est un petit monde, et ça peut atteindre notre image publique. […] De façon anecdotique, il peut arriver de se prendre un peu le bec avec les hackers. Le KYC Yogosha s’est révélé vraiment intéressant [ndlr : l’identité de tous nos hunters est vérifiée]. On se contacte, on peut avoir des débats. Mais ce que nous avons fini par comprendre, c’est qu’on est tous des humains. Il faut prendre le temps de la discussion, de l’échange et comprendre les différentes opinions.
Les désaccords viennent en général du score de criticité CVSS, qui ne retranscrit pas toujours les véritables impacts business d’une vulnérabilité. C’est ça la vraie difficulté du bug bounty, il faut savoir déterminer l’impact réel d’une vulnérabilité, tout en reconnaissant le temps passé dessus par un hunter.”
“Avec le bug bounty, on a parfois des hunters qui vont vraiment loin.”
Le bug bounty permet aux hunters de fouiller en profondeur et sur la durée, là où d’autres formes d’audits comme le test d’intrusion sont limitées dans le temps. Cette philosophie radicalement différente permet au bug bounty de mettre en lumière des vulnérabilités complexes, difficiles et chronophages à identifier. Le RSSI de Veepee confirme :
“Des pentests on en a fait plein, on en fait toujours un peu pour la conformité ou repasser sur des applications critiques. […] Mais avec le bug bounty, c’est différent. On n’est pas dans l’attente d’un rapport, on est dans l’attente d’une vulnérabilité critique. La différence est là aussi. Et avec Yogosha, les critiques ont quasiment toujours été pertinentes. Ce n’est pas le secure cookie ou le HSTS mal paramétré qu’on peut avoir d’un pentesteur qui arrive au bout de ses 5 jours, et qui doit faire un rapport alors qu’il n’a pas trouvé grand chose.”
– Antonin Garcia
Julien témoigne lui aussi de la pertinence du bug bounty, et des rapports soumis par les hackers de la Yogosha Strike Force.
“Avec le pentest, le périmètre est bien défini. Si on trouve une vulnérabilité, on ne va pas forcément plus loin. Avec le bug bounty, on a parfois des hunters qui vont vraiment loin. Certains passent des commandes réelles sur le site, donc ils dépensent de leur argent pour trouver des vulns derrière. Avec des pentests externes, on n’a jamais vu ça. […]
Quand on fait un pentest, une XSS c’est souvent afficher une alert box ou les cookies de session, mais ça va rarement plus loin. Avec le bug bounty, on a eu des XSS stored depuis un front qui permettaient de faire des choses sur le backoffice.
Ce genre de choses, ça nous permet aussi de faire de la sensibilisation auprès des devs. Le fait de savoir que tu peux faire une capture d’écran d’un backoffice qui n’est normalement pas accessible depuis Internet, ou prendre le contrôle du navigateur et potentiellement dumper une base de données via une XSS, forcément ça donne de l’impact et de l’intérêt.”
– Julien Reitzel, Lead OffSec chez Veepee
Julien confie par ailleurs que les rapports critiques soumis par les hunters sont si souvent pertinents qu’ils génèrent depuis peu des alertes 24/7 en astreinte chez vpTech. “On a décidé ça uniquement pour les criticals, on n’a pas envie de se faire réveiller n’importe quand pour une medium !” On s’excuse par avance auprès de tous les développeurs vpTech qui devront se réveiller à cause de nos hunters.
Maintenant, vous savez ce qu’il y a derrière le logo rose. La prochaine fois que vous commanderez sur Veepee, vous saurez que de l’autre côté de l’écran, il y a Antonin, Julien et le reste de l’équipe vpTech qui sont prêts à se réveiller au milieu de la nuit pour garantir la bonne sécurité du service.
Intéressé par le bug bounty ? Découvrez les solutions Yogosha.
