Après la revue de presse sécurité Revolve Job Zero, nous vous proposons un nouveau format régulier sur la sécurité Cloud. Dans cette série d’interviews, nous allons à la rencontre de spécialistes sécurité qui travaillent sur le Cloud pour faire un état des lieux des tendances et des pratiques : boîte à outils sécurité dans le Cloud, évolutions de fond, impacts de la crise sanitaire, transformation du métier de la sécurité…

Notre invité aujourd’hui est Nicolas Béguier, architecte sécurité chez leboncoin depuis 6 ans. Au cours de cet entretien, Nicolas partage avec nous sa vision du métier : le périmètre de l’architecte sécurité, son évolution face aux menaces changeantes, les outils, mais également les aspects humains de la mise en oeuvre d’une politique de sécurité.

Nous revenons également sur l’outil AWS Tower, développé en interne chez leboncoin, pour identifier les problèmes de configuration et de sécurité, tout en faisant abstraction de la complexité du Cloud.

Peux-tu te présenter ?

Je suis architecte sécurité chez leboncoin depuis 6 ans. Mon métier, c’est de concevoir des architectures sécurisées. On aide le RSSI à prioriser les chantiers de sécurité, et pour cela on doit bien connaître le périmètre, savoir où chercher les risques, les évaluer, et identifier ceux qui sont les plus importants. L’architecte sécurité est le garant technique de ce qui se passe sur le terrain. 

Chez leboncoin, j’écris également des politiques de sécurité, des bonnes pratiques  destinées à sensibiliser les développeurs et les nouveaux arrivants. Par exemple, l’application de la politique de logs, ou comment faire du zero trust.

Il faut sensibiliser les développeurs, et les différents intervenants techniques, et rendre la sécurité suffisamment intéressante pour qu’ils l’intègrent dans leur quotidien. En contrepartie, il faut s’intéresser à leur code, à ce qu’ils font sur le terrain, et leur donner des exemples issus de leur quotidien, des outils qu’ils utilisent, etc.

Quels sont les risques adressés ?

Le premier risque est commun à toutes les entreprises : on veut empêcher l’accès à notre SI et à nos données. Comme nous avons beaucoup de données personnelles, nous devons respecter les règles de la CNIL et faire attention à ce qu’on manipule.

Nous essayons aussi de protéger nos utilisateurs du phishing et de la fraude. J’interviens à la fois sur le périmètre applicatif et sur l’infrastructure. L’infrastructure a tendance à intéresser un peu moins les RSSI, c’est aussi dû au fait qu’on a naturellement plus confiance dans l’infrastructure que dans l’application.

Comment la menace cyber a évolué ces dernières années ?

Comme la majorité des acteurs français nous avons connu de nombreuses attaques durant le Covid en 2020. On a vraiment eu de tout, même des deepfakes. Ca s’est un peu calmé depuis, mais globalement les attaques sont plus nombreuses. On ne s’en rend pas toujours compte, car nous sommes maintenant mieux préparés.

C’est un cycle : on prend des mesures pour lutter contre les attaques, elles diminuent car nos mesures fonctionnent, et de nouvelles attaques apparaissent. Nous avons par exemple subi plusieurs attaques DDOS assez volumineuses, et ça c’est nouveau. Ces attaques viennent de l’étranger, et si nous avons des rate limiter pour privilégier le trafic en provenance de la France, certains groupes d’attaquants achètent des infrastructures partout dans le monde. Les attaques sont dans ce cas plus difficiles à bloquer si elles viennent d’infras situées en France.

Quels sont les outils qui te semblent indispensables ?

Aujourd’hui on ne peut plus se passer de supervision réseau. Côté OS, les EDR, c’est la base de ce qu’on déploie. Côté applicatif, les anti DDoS deviennent incontournables. A ce titre, CrowdSec propose une approche collaborative basée sur l’identification des IP d’attaquants DDoS par la communauté. L’intérêt d’un outil collaboratif, c’est qu’on est toujours meilleurs à plusieurs.

Au quotidien, j’utilise beaucoup Python. Il n’y pas vraiment d’outil prêt à l’emploi pour identifier les problèmes, il faut s’adapter à l’ensemble des technos dans l’entreprise, et pour cela Python est très pratique.

Pour l’applicatif, j’utilise Burp pour faire du micro pentest et titiller les applications. Sur l’analyse statique, je prends le parti de l’open source plutôt que les gros soft propriétaires. Chez leboncoin, on a beaucoup de Go, donc on utilise gosec, mais du grep sémantique comme semgrep qui permet de comprendre la syntaxe et identifier s’il y a des problèmes dans le code, quelque soit le langage.

Des outils natifs Cloud ?

A part Guard Duty, que nous utilisons, et Trusted Advisor, il y a assez peu d’outils AWS dédiés à la sécurité, la plupart sont plutôt orientés conformité. Guard Duty nous lève des alertes plutôt bonnes sur la base de nos logs réseau et Cloudtrail. Cela ne nous empêche pas d’avoir un autre SIEM.

Quelles sont les raisons qui vous ont poussé à développer votre propre outil, AWS Tower ?

Quand nous avons migré sur le Cloud en 2019, tout le monde déployait beaucoup sur AWS. Nous nous sommes posé la question du suivi, comment se rendre compte de ce qui est déployé, et identifier les problèmes de configuration et de sécurité ? A l’époque, il y avait peu d’outils sur le marché, ils étaient assez opaques. Je voulais une vision simplifiée de l’infrastructure, qui fasse abstraction de la complexité du Cloud pour donner des notions plus claires : parler d’une instance avec un port ouvert sur Internet, plutôt que d’une EC2 dans un VPC… Aujourd’hui encore, on manque d’outils pour rendre l’audit et la sécurité sur le Cloud plus accessibles.

AWS Tower analyse des metadata pour donner des informations qui sont simples à comprendre, et faire l’inventaire de ressources nombreuses, en présentant l’ensemble des services AWS utilisés, et ceux qui ont des problèmes de sécurité. C’est-à-dire, ceux qui sortent des règles que nous avons définies, comme une exposition publique, un moteur déprécié, etc.

Au départ, nous avons développé un script Python avec la librairie Boto3 d’AWS. Petit à petit, le script a pris de l’importance, on l’a branché sur du monitoring, sur de l’alerting et nous avons intégré de plus en plus de services. L’outil fonctionne bien, il détecte les erreurs et évite que l’état de notre sécurité ne dérive trop.

En tant qu’architecte sécurité, as-tu besoin de prendre plus en main le code (via l’IaC, outils d’analyse, …), afin de garder le contact avec l’implémentation opérationnelle ?

J’ai un peu fait le chemin inverse. J’ai pas mal développé, j’ai été SRE pendant quelques années. Je suis donc assez familier avec les sujets d’infrastructure, j’ai beaucoup codé, et mon métier m’a amené à savoir lire et comprendre du Javascript, du PHP, du Go…

Si j’échange avec des développeurs PHP, je dois connaître leur framework, Symfony, ce qu’il propose en termes de sécurité, voire leur proposer des exemples de code dans le dépôt et leur montrer ce qui aurait pu être fait différemment. J’aime le développement, je dois mettre les mains dedans pour mon métier. Si je ne le faisais pas, je passerai à côté de beaucoup de choses.

Quels sont les outils qui te manquent ?

Il existe de nombreuses méthodologies aujourd’hui, mais je trouve qu’elles sont trop souvent soumises à interprétation. Pour protéger les applications et les infrastructures, il n’y a pas de checklist technique. C’est ce qui manque principalement aujourd’hui, une sorte de cheat sheet qui serait validée par un comité de sécurité, pas juste une méthode issue d’une entreprise. Il devrait y avoir plus de collaboration entre les entreprises pour créer des listes et du scoring.

Quels sont les principaux challenges de sécurité sur le Cloud AWS ?

Passer sur le Cloud AWS nous a surtout soulagé de pas mal de challenges. L’inventaire est devenu simple, et ça nous a facilité la vie. Le challenge principal est surtout de changer sa façon de penser la sécurité, le Cloud c’est très peu de VM et beaucoup de services.

Chaque application est une nouvelle surface d’attaque, donc on doit faire beaucoup de contrôle d’accès. Comme chaque emplacement a une porte d’entrée sur Internet, on doit comprendre l’ensemble des briques, comment elles communiquent entre elles, et plus généralement que le Cloud est une infrastructure publique, où la seule protection est un login/mot de passe. Mais globalement, le fait de déléguer une partie de la gestion à un tiers (routeurs, OS, etc.), fait qu’on est beaucoup plus sereins sur le Cloud.

La souveraineté des données est-elle un enjeu pour vous ?

Ce n’est pas vraiment un enjeu pour la moitié de nos clients qui sont des particuliers. Cependant pour nos clients professionnels, comme les concessions automobiles, savoir que leurs données sont hébergées en France est un argument de vente. Sur ce sujet, nous avons choisi de prendre de l’avance et de stocker toutes les données sur Paris.

Comment vois-tu l’évolution du métier de la sécurité ?

J’ai beaucoup subi le zero trust comme un buzzword. J’ai essayé de vraiment m’y intéresser, comprendre ce qu’il y a derrière. En fait, on tend vers un monde où on n’a plus confiance, il faut tout vérifier, et c’est sur ce point qu’il faudrait pousser la réflexion.

Arrêter de se limiter à son périmètre par exemple : on ne peut pas occulter les endroits qui ne nous intéressent pas, de la caméra à l’entrée de l’entreprise au système de production. Même si aujourd’hui il y a beaucoup de Cloud, on aura toujours du physique, des bureaux, etc. On ne devrait pas voir les choses sous l’opposition Cloud/On premise, mais voir comment décomposer ses assets entre systèmes réseau, OS, IoT, et pour chacun d’entre eux définir des règles. Certaines de ces règles seront plus faciles à appliquer dans le Cloud, d’autres on premise.

Est-ce que le Cloud est un accélérateur des enjeux de sécurité ?

Tout simplement oui.

Quand on migre vers le cloud, on doit se poser beaucoup plus de questions. Ce sont des nouvelles problématiques, et pour y répondre on augmente le niveau de sécurité de l’entreprise. Migrer dans le Cloud demande un certain effort, mais permet d’avoir une meilleure vision sur l’infra et de mieux la sécuriser. On a jamais été aussi sécurisés que depuis qu’on est sur le Cloud.

Est-ce que tu as l’impression que l’acculturation sur les sujets de sécurité progresse dans les entreprises ?

La sécurité n’est plus une ligne budgétaire qu’on veut effacer à la fin de l’année. Et dans beaucoup d’entreprises, une sécurité accrue est une demande des actionnaires. Tout le monde sait maintenant que la sécurité est indispensable, et même si c’est essentiellement pour répondre à des enjeux business, les gens sont globalement plus ouverts à la sécurité.

Ceci étant dit, je trouve aussi qu’on essaie d’en faire trop (FUD). Dans le monde de la sécurité, la moitié des intervenants sont des RSSI, et les attentes des entreprises sont trop ambitieuses. On veut tout faire, tout de suite, avec des profils super expérimentés. Commencer petit, ce serait peut-être tout aussi bien. Cela explique aussi la pénurie de talents dans la cybersecu, et le fait qu’il y a ait très peu de postes proposés en sortie d’école. Avoir des profils DevSecOps qui implémentent du tooling de sécurité dans l’entreprise, c’est déjà une bonne première étape.

Pour terminer, quel conseil donnerais-tu à un jeune référent sécurité ?

La base, c’est d’avoir un inventaire. Si tu commences dans un poste, on ne te donnera pas un inventaire de machines à sécuriser. Il faut s’intéresser aux briques du SI, et ensuite apprendre à générer des inventaires. Aller à la recherche de l’information, ne pas compter uniquement sur les autres équipes pour nous la donner, c’est formateur. Il y a beaucoup à découvrir en s’intéressant au métier des autres et à leurs périmètres.

Quelqu’un dans la sécurité qui s’entend avec les développeurs et l’infrastructure identifiera plus facilement les problèmes potentiels. Et plus on connaît les gens, plus il est simple de faire des concessions. Or, faire des concessions est important dans la sécurité, c’est ce qui est le plus difficile dans notre métier : on sait qu’il y a un problème, on doit y trouver une solution humaine. Faciliter la vie de ses collègues est un bon moyen de faire de la sécurité, si on est trop restrictif, les gens cherchent des portes dérobées.