La double casquette sécu du CTO

"Pour moi, la sécurité fait partie du mandat initial du CTO. Le CTO doit avoir une fibre sécurité et mettre en place de bonnes pratiques dès le début du développement du produit."

A l’heure où notre société fait l’éloge de la sécurité, où le principe de précaution est devenu la norme, la startup dénote. Une activité jeune, un marché incertain et des finances souvent dépendantes des levées de fonds, la prise de risque est plus présente que dans les entreprises traditionnelles.

Cependant, au moment du scale, l’asset de l’entreprise grandit, les enjeux augmentent et cette prise de risque devient déraisonnable. Une période de transition s’engage entre la prise de conscience et la mise en place de mesures qui permettent de placer le risque sous contrôle, ce qu’on appelle la “fenêtre de vulnérabilité”, sweet spot des hackers.

Le produit étant technologique, c’est généralement le CTO qui endosse la casquette sécurité au début de la vie de la startup. A quel moment le rapport au risque change-t-il dans la startup ? Comment évaluer et gérer la transition pour mettre les assets de l’entreprise sous contrôle ? Puis gérer le passage à l’échelle de la sécurité ?

Yann Perchec a fait partie des 10 premiers employés de Peopledoc, plateforme SaaS de digitalisation RH à succès. Développeur puis CTO et CISO, il a connu l’hyperscale et fait passer l’équipe de 10 à 150 en 4 ans. Il est aujourd’hui CTO d’Epsor. Il nous partage ses convictions et retours d’expériences dans ces entreprises SaaS B2B Enterprise. Les grands concepts de sécurité abordés sont cependant valables pour le plus grand nombre, à adapter selon son secteur d’activité et le niveau de risque qui s’y trouve.

Quand on parle de sécurité et de vulnérabilité en startup, de quoi parle-t-on ? Yann, est-ce que tu peux illustrer avec Epsor ? Peux-tu me décrire l’activité, les ressources de l'entreprise à protéger et les enjeux de sécurité auxquels tu fais face ?

En startup, la fonction sécurité a pour mission de protéger le patrimoine informationnel de l’entreprise.

Une startup, comme toutes les entreprises quel qu’en soient la taille et les moyens, est toujours plus ou moins vulnérable face aux différentes menaces présentes dans le cyber espace. Le zéro risque n’existe pas. En revanche, il est impératif de mettre en place le maximum de mécanismes de défense et d’utiliser des bonnes pratiques de sécurité pour réduire au maximum ce risque de vulnérabilité. Et, si une attaque a lieu, avoir les bons outils pour la détecter au plus tôt et réagir efficacement.

C’est une tâche assez complexe et qui peut parfois donner l’impression d’aller à l’encontre de l’agilité et la de rapidité d’exécution d’une startup.

Epsor est une solution de gestion d’épargne salariale et retraite digitale. L’entreprise s’adresse aux équipes “compensations et bénéfices” des directions RH des grands groupes puis est utilisée par l’ensemble des salariés.

L’asset principal est la donnée client : données coeurs générées par l’application (positions, transactions financières) et données d’identification pour que l’application fonctionne (email, adresse, numéro de sécurité sociale).

Les enjeux majeurs de sécurité sont :

1. la confidentialité des données (risque de fuite ou perte de données)
2. l'intégrité des données (que le client puisse voir le montant juste de ses comptes sur son application)

Quel taf ça représente au quotidien ? Est-ce normal selon toi que le CTO endosse cette casquette sécurité ?

Le mandat sécu chez Epsor, ce sont 3 choses au quotidien :

1. Gérer les aspects techniques : mise en place d’outils d’observabilité et formation des équipes aux bonnes pratiques.. J’ai besoin de pouvoir évaluer le niveau de sécurité à un instant t, aussi bien pendant le développement qu’en bout de chaîne avec des pentest¹.
2. Gérer la gouvernance : collaborer avec les autres équipes, mettre en place des mesures de sécurité au niveau des métiers non-tech, faire de l’awareness. Dans les faits, les attaques ciblent assez souvent les équipes non tech.
3. Participer à l’avant-vente : le client se pose des questions de sécurité, il faut lui apporter des éléments de réponse concrets. J’initie un travail de documentation technique pour accompagner les équipes et il peut m’arriver de discuter avec les responsables de la sécurité chez les prospects ou les clients.

J’y consacre une demi-journée par semaine, interlude pendant lequel je passe beaucoup de temps avec l’avocate qui nous aide sur les questions de Privacy ! C’est peu, mais à caler avec dans un agenda déjà très chargé par le reste de mes missions de CTO.

"Pour moi, la sécurité fait partie du mandat initial du CTO. Le CTO doit avoir une fibre sécurité et mettre en place de bonnes pratiques dès le début du développement du produit."

En 2022 on doit être sensibilisé aux problématiques de cybersécurité côté tech : chiffrement des données, sécurisation d’API, hardening, etc… … Et aujourd’hui les frameworks modernes embarquent déjà beaucoup de choses “out of the box”, sans parler des outils SaaS de plus en plus performants.

Quelles sont les difficultés allouées à cette fonction et les limites à cette double casquette ?

"La réelle difficulté pour le CTO selon moi est de s’approprier les questions de sécu en dehors de la tech. Ce n’est pas forcément naturel et demande pas mal de temps et d’énergie. La sécu c’est le truc qui fait peur et qu’on n’a pas trop envie de bouger ni de partager à ses clients…"

Faire bouger les lignes quand il y a déjà 200 personnes dans la boîte, c’est dur ! Ça prend du temps et ça coûte cher. Mieux vaut traiter le sujet le plus tôt possible. Il est impératif de communiquer autour de ces risques auprès de toutes les équipes, de partager les bons réflexes, d’avoir une sorte d'hygiène de sécurité. Il existe pas mal de supports² aujourd’hui qui peuvent aider notamment sur le site de l’ANSSI.

Côté client, pour moi, il n’y a qu’une solution :  jouer l’honnêteté. Ça nous a d’ailleurs clairement permis de closer des deals avec John et Clem chez Peopledoc. On vendait une solution de coffre-fort numérique aux RH, savoir discuter avec un RSSI et collaborer avec le client était devenu un argument commercial.

La limite de la double casquette ? Le CTO est juge et partie ! À la fois, tu as envie d’aller vite côté dév et en même temps, la sécurité est obligatoire. L’exercice peut être un peu périlleux lorsque la sécurité n’a pas été mise en place à la forge du développement.

A quel moment le rapport au risque change-t-il dans la startup ? Ce moment où la startup commence à investir voir staffer la fonction ?

Idéalement, le rapport au risque doit être présent dès les premières lignes de code écrites mais c’est généralement un événement à fort impact business qui déclenche l’investissement :

• Chez Peopledoc, acquérir les normes ISO 27001³ et constituer un rapport SOC2⁴ pour travailler avec les grands comptes a été game changer, je n’avais plus l’expertise pour y répondre moi-même.
• Un incident de sécurité, le scénario qu’on n’aimerait pas voir nous arriver : demande de rançon, fuite de données, ou la perte de laptops dans les bars parisiens au moment de l’apéro. Il y a un véritable marché parallèle structuré, j’ai déjà retrouvé des ordinateurs localisés en Inde…
• Une levée de fonds, un bon niveau de sécurité permet d’aller chercher les plus beaux fonds de la place, le cas inverse est éliminatoire.

Ce qui correspond au stade de série B pour une startup technologique. La sécurité ne crée pas de business mais permet de ne pas en perdre.  On est typiquement dans ce cas de figure avec Epsor : un objectif de scale et donc de s’assurer que les choses sont bien faites, sous contrôle.

Tu es arrivé il y a 9 mois, j’imagine qu’avec ton ancienne casquette de CISO c’est l’un des premiers chantiers que tu as ouvert ! Comment as-tu évalué le niveau de risque à ton arrivée ?

L’avantage d’arriver de l’extérieur est que je peux profiter de cette période pour faire prendre conscience et bousculer les habitudes.

Chez Epsor, l’équipe était assez senior et avait déjà mis en place pas mal de bonnes pratiques. En arrivant j’ai essayé de tout checker, je voulais avoir une vision objective de l’archi, des process et des outils que j’utilise. Être au courant des merdes dans la stack et des pratiques dans la gouvernance.

Il y a des infos faciles à obtenir que te donnent les dév ou les autres métiers, ils t'expliquent leurs pratiques et les incidents. Puis les trucs plus difficiles, est-ce que tu as des secrets, des mots de passe dans ton repository de code qui rendent le système fragile, tu te doutes que oui mais c’est difficile de le savoir ! Tu peux utiliser des outils types comme Gitguardian pour ça.

J’ai rapidement organisé un bon test d’intrusion (pentest) pour mesurer la solidité de l’app. Dans ce cas, c’est important de faire appel à des prestataires en qui tu as confiance, et de leur donner un maximum d’info, dont des accès aux codes. Le plus d’info ils auront, le plus complet et pertinent seront les tests.

Aujourd’hui j’ai un dashboard de ma stack, avec les versions des outils utilisées, comment je gère les accès à la prod, si mes datas sont chiffrées, la rotation des clés…

As-tu eu besoin de convaincre les fondateurs d’investir ?

Les fondateurs avec qui j’ai bossé ont toujours eu une bonne compréhension des risques. Toute la difficulté est de réussir à traduire ces risques en pratiques et processus pour les réduire. La discussion devient plus fine au moment de la définition du budget… Le tout est de mettre en place un budget sécurité en adéquation avec le stade de maturité de la boîte.

Comment fais-tu pour définir le budget sécurité ?

Première étape, je définis la nature des informations gérées par l’entreprise et le niveau de menace dont il faut se protéger. Chez Epsor, on est sur de la donnée personnelle (numéro de sécu, email, mot de passe..), on cherche à se protéger des pirates du dimanche et des groupes organisés (LAPSUS$, ShinyHunters, Anonymous…). Le niveau supérieur c’est le piratage étatique, mais on n’est pas concerné…

Deuxième étape, définir une matrice des risques.

"J’identifie l’ensemble des risques auxquels l’entreprise est exposée, leur probabilité d'occurrence  et les scénarios en cas de faille de sécurité. Du pire au moins pire, de l’image entachée à la clé sous la porte..."

Pour finir, je choisis les actions prioritaires à mettre en place, ce qui définit le budget. On ne peut pas tout faire, c’est la base du risk management, faire des compromis !

Comment fais-tu concrètement pour prioriser les risques à traiter ? C’est super subjectif et ça dépend de la sensibilité au risque de chaque CTO non ? Comment mettre la bonne mesure ?

Il y a les choses basiques les “must have” : est ce que tes apps les plus critiques ont le SSO⁵, est ce que tu as fait récemment un pentest, etc… puis il faut prioriser les gros chantiers. J'essaie de mesurer le niveau de risque en fonction du niveau d'occurrence, je priorise comme ça.

Pour moi c’est universel et ça fait partie de la formation de base du CTO. Ce qui serait vraiment dangereux, c’est de ne pas prendre conscience des risques existants. A partir du moment où on connaît les risques, on peut mettre les mesures nécessaires en face.

Et donc le budget, c’est quel ordre d’idée ?

Pour une boîte au niveau de la série B, c’est entre 100 et 150k€ sur l’année. De quoi faire un pentest complet de qualité une fois par an, sécuriser le parc informatique (ce qui bouffe assez vite le budget), rédiger le Plan d’Assurance Sécurité et le reste du budget passe dans la suite d’outils (slack, etc.).

Le passage au scale est réputé pour être une “fenêtre de vulnérabilité”, sweet spot des hackers. Est-ce que tu peux m’expliquer pourquoi ? Ça ne doit pas être confortable à gérer… Ça ne te donne pas trop de sueurs froides ?

C’est le gain de notoriété qui accompagne la levée de fonds qui explique l’augmentation des attaques. Et les responsabilités grandissantes de l’entreprise peuvent donner des sueurs froides ! Beaucoup d’argent, gérer un grand nombre de clients, faire vivre une centaine de personnes…

Cependant un minimum de sécurité fait renoncer 90% des hackers. Le but du jeu est de rendre la vie difficile au hacker, généralement quand il voit qu’il y a les premières barrières de sécu mises en place, il abandonne.

"Accepter le risque est inhérent à la fonction sécurité, on aura beau mettre en place toutes les barrières, ça ne sera jamais parfait !"

Une fois la fenêtre de risque réduite, comment fais-tu pour passer la sécurité à l’échelle ?

Mon objectif est d’insuffler une culture sécurité dans toute l’entreprise, comme je te le disais plus tôt, la sécurité est devenue la responsabilité de tous.

Côté produit, le maître-mot c’est le “shift-left security”⁶. On veut que la sécurité soit le plus en amont du cycle de dev. Ajouter un process en fin de développement qui ralenti le delivery, c’est casse couille et ça marche pas. La sécurité doit être discutée à chaque phase des développements comme partie intégrante des specs.

Pour le reste de l’entreprise, j’ai commencé par des trucs tout con, un channel slack dédié pour toute la boîte, un security committee auquel les fondateurs participent. J’ai gagné du temps en externalisant la gestion de l’IT et la rédaction du Plan d’Assurance Sécurité.

Mais à termes, pour scaler, il faudra quelqu’un qui gère la fonction sécurité à 100%.

‍

Pour conclure, l’approche de la sécurité doit être construite by design, il faut concevoir les processus de sécurité dès la conception du produit et tout au long du cycle de développement. C’est une mission inhérente à la tech. Le CTO porte naturellement cette casquette technique mais le mandat ne s’arrête pas là… et c’est tout le défi, il faut ajouter les dimensions gouvernance et avant-vente à cette casquette technique ! Les failles ne viennent généralement pas de la tech, c’est souvent un hacker qui envoi un mail et quelqu’un dans la boîte clique dessus…

Au moment du scale, il y a un siège manquant et tous les regards convergent naturellement vers le CTO. Compte-tenu des enjeux, la boîte ne peut pas ignorer le sujet et doit allouer un budget juste à la sécurité, donner les moyens au CTO de construire une culture sécu durable dans l’entreprise jusqu’au recrutement du premier profil sécurité, article coécrit avec Alexandre Menguy, CISO de ContentSquare dans la continuité de cet échange.