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 : boite à 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 Toufik Airane, Product, Cloud & Application Security Engineer dans le secteur de la Health Tech. Il a notamment travaillé chez Doctolib, et il vient de rejoindre la start-up Zoī.

Comment vois-tu le DevSecOps et le partage des responsabilités de sécurité ?

Je pense que le DevSecOps est une forme d’idéal de collaboration entre les équipes de développement du produit (Dev), de mise en œuvre opérationnelle sur le Cloud (Ops), et de Cybersécurité (Sec).

L’idée est de développer une synergie dans le but de livrer un logiciel en tant que service fonctionnel, hautement disponible, et répondant à des standards de cybersécurité.

En tant que référent sécurité applicative, quelles sont les interactions avec les équipes chargées de la sécurité de la plateforme ?

L’équipe cybersécurité adopte souvent un rôle de “chef de projet” car nous sommes l’autorité de savoir, en mesure d’identifier et de classifier les risques.

Dans ce contexte, nous collaborons avec les équipes de développement pour traiter ou atténuer les risques, comme par exemple fixer des vulnérabilités identifiées par un programme de bug bounty. Mais nous sommes aussi capables de nous mobiliser pour répondre à des besoins comme de la modélisation des menaces ou de l’investigation numérique.

Pour répartir les domaines de compétence, l’équipe cybersécurité est elle-même organisé en trois squads autour des composants qu’elles protègent :

• Product and Application Security, chargé de la sécurité du produit et du code
• Cloud Security, chargé de la sécurité de l’infrastructure Cloud
• Data Security, chargé de maintenir les exigences de sécurité des données et de vie privée de nos clients

La collaboration au sein même de l’équipe cybersécurité se fait naturellement grâce à la proximité des thèmes. Cependant, le Cloud Security a l’avantage de travailler sur des éléments tangibles comme de l’infrastructure alors que l’AppSec est une matière beaucoup plus évanescente car on s’appuie beaucoup sur l’humain, du coup l’automatisation est complexe car on ne sait pas toujours décrire ce qui doit être testé.

Les revues de sécurité manuelles ou semi-automatiques laissent passer certains bugs. Pour atténuer ce risque, il faut créer ou renforcer des règles personnalisées, grâce à l’expérience des incidents passés. Donc l’AppSec est une course incessante derrière les ingénieurs pour encapsuler leurs projets.

C’est peut-être la raison d’une frustration qui pousse parfois certains AppSec à envier le Cloud Security. Cela explique aussi les difficultés à recruter, d’ailleurs il n’y a pas de certifications purement AppSec, alors qu’on en trouve pour le Pentest (OSCP, OSWE, etc.) et le Cloud Security (CKS).

Quel est le périmètre de la sécurité applicative ? 

En tant que AppSec, on touche un peu à tous les sujets, de la construction d’un cycle de développement sécurisé (SSDLC), à la recherche de vulnérabilité en passant par la gestion des secrets. L’AppSec est une activité très généraliste, et plus l’entreprise dispose de moyens, plus elle peut recruter de spécialistes pour renforcer les squads évoqués tout à l’heure.

Au sein des équipes de Doctolib, il y a plus de 28 ingénieurs en cybersécurité. C’est une belle équipe, avec chacun ses spécialités. Pour ma part, j’ai travaillé sur la sécurité du code. J’ai donc une vision du produit, et de son implémentation dans le code. Je m’intéresse aux fonctionnalités (feature), et je dois m’assurer qu’elles répondent au besoin du client final, tout en étant préservées des externalités négatives, c’est-à-dire des vulnérabilités, qui peuvent peser une menace contre notre organisation. Mon travail consiste à corriger ces vulnérabilités, sur le plan fonctionnel et technique.

A quelles menaces devez-vous répondre ?

En résumé, il y a deux types de menaces sur le périmètre de l’organisation, ceux qui viennent de l’intérieur vers l’extérieur et de l’extérieur vers l’intérieur.

De l’extérieur vers l’intérieur, ce sont les agents qui veulent se frayer un chemin dans nos infrastructures ou les risques liés à la régulation. Il peut s’agir de groupes de hackers, sponsorisés ou pas, de script kiddies (des ados qui s’ennuient) ou des hacktivistes, qui reviennent en force depuis la crise sanitaire. Par exemple, la campagne de vaccination à redonner un souffle de motivation aux hacktivismes en Europe. Enfin, il y a les risques liés à la régulation, notamment sur les sujets de la RGPD et du HDS.

De l’intérieur vers l’extérieur, c’est principalement la menace interne, par exemple des employés malveillants ou des accidents. On est aussi responsable de mettre à niveau la sécurité des applications internes avec le même niveau d’exigence que les applications exposées aux utilisateurs finaux.

Est-ce que tu utilises des outils de sécurité natifs Cloud ?

En AppSec, pas vraiment, la plupart des outils que je préconise sont des outils open-source à orchestrer dans une intégration continue (CI).

Dans le modèle de responsabilité partagée du Cloud, les entreprises ont la responsabilité de la partie software, mais à mesure que le Cloud gagne en maturité et que les outils deviennent plus puissants, je pense que les Cloud providers vont aussi proposer des services de sécurité pour la partie applicative. On le voit arriver avec des services intégrés de source code management, pour gérer les dépendances, analyser le code, détecter les secrets, etc. Nous ne sommes qu’aux débuts de cette croissance.

Par exemple, Vault représente la jonction parfaite entre Cloud Sec et Dev Sec : il est déployé par les équipes infrastructure, et maintenu par les équipes applicatives, car ce sont elles qui gèrent la logique de gestion d’identité. C’est un très bon exemple de collaboration AppSec au sens large.

Quels sont les outils qui te manquent ?

J’observe avec beaucoup d’envie les dashboards des ingénieurs Cloud. J’ai récemment essayé de créer des dashboards sur Datadog, avec la feature security qui permet de créer ses règles et de les matcher avec les logs. J’ai essayé de créer un système qui centralise toutes les alertes liées aux incidents de sécurité sur l’application en mode ChatOps. La plupart du temps, la digestion des données est à développer soi-même, car mon objectif est d’avoir une vue globale et de tout reporter sur un orchestrateur.

Avoir des dashboards multiples (SonarQube, Github alerts, etc.), sans un accès centralisé, ça complique vraiment le travail. Il existe des initiatives open source comme Defect Dojo, mais personnellement je n’ai pas été convaincu.

Autre chose : le pentesting. Ce sont les équipes AppSec qui traitent les vulnérabilités identifiées, qui gèrent le ticketing et travaillent avec les développeurs pour les corriger. Et pourtant, en termes de communication, les entreprises de pentesting nous envoient encore leurs rapports au format PDF. Nous devons alors faire des copier-coller pour les mettre dans un ticket, cela rend le métier compliqué et laborieux.

Globalement, il y a donc un manque d’outils adaptés. Mais c’est aussi une question d’état d’esprit : nous sommes tout juste en train de découvrir ce qu’est le DevSec, au sens de la sécurité du software et du produit.

Si tu devais citer un outil qui t’es vraiment utile ?

Si je devais garder un outil, ce serait Nuclei de Project Discovery. C’est un scanner de vulnérabilités à la sauce GitOps, ça change tout ! On est plus sur un outil opaque comme le sont la plupart des scanners de vulnérabilités.

Nuclei est open source est permet de versionner ses propres tests grâce à son DSL. Il y a trois couches de règles : celles créées par les développeurs, celles faites par la communauté, et enfin celles spécifiques à l’entreprise. Et la communauté est très réactive quand une nouvelle vulnérabilité est découverte. J’essaie de tendre vers ce type de solutions, scalables et totalement intégrables.

Quel a été l’impact de la crise sanitaire sur ton métier ?

En premier lieu, je dirai qu’elle a mis en lumière le métier d’ingénieur App Sec. Il y a beaucoup plus d’opportunités d’emploi, la demande a explosé et les profils d’ingénieur en sécurité applicative manquent.

En contrepartie, les attaques ont été multipliées. Il y a de nouvelles motivations pour les  hacktivistes, les menaces sont plus nombreuses, mais il y a peu de personnes curieuses de ce métier. Peut-être est-il mal décrit ? Les fiches de poste n’ont pas de cohérence d’une entreprise à l’autre, pour le même poste on trouve plein de titres différents (SecOps, AppSec, etc.). Il y a de vrais besoins sur le marché, mais les entreprises manquent encore de maturité pour bien décrire le métier et attirer les bons profils.

Et la diversité ? Quelle est la place des femmes dans l’App Sec ?

La cybersécurité est un métier d’anticipation qui nécessite des opinions variées. Malheureusement, je vois peu de femmes dans certaines équipes. J’ai eu l’occasion de travailler dans une entreprise où il y avait presque 50% de parité, mais j’ai aussi connu des équipes sans minorité dans l’équipe. Ce que j’ai constaté, c’est que la parité amène une vraie diversité dans les idées et la méthodologie, car sans diversité, il y’a une tendance à siloter les idées et devenir une chambre d’écho, donc je pense que la diversité est vitale pour une équipe de cybersécurité pour éviter ces biais cognitifs.

Enfin, je pense qu’il y a un vrai effort à faire dans l’intégration. Quand il y a une seule femme dans l’équipe, il est du ressort du manager de pousser des initiatives pour que tout le monde soit inclus. Que toutes et tous se sentent à l’aise, et concernés. C’est difficile quand il y a une majorité écrasante.

La souveraineté des données, c’est un sujet ?

C’est un prérequis, une contrainte que l’on prend en compte dans le choix stratégique des prestataires, on travaille principalement avec des fournisseurs conformes avec les standards européens, et de préférence avec des datacenters situés en Europe. Après, on peut se poser la question dans un contexte de guerre économique, dans ce cas, la seule réponse valable est le chiffrement. On utilise certains Cloud providers pour leur qualité de service, et nous sommes d’autant plus rassurés s’ il y a une couverture contractuelle, mais la confiance n’exclut pas le chiffrement. Le chiffrement permet de mitiger ce risque sur le long terme, même si l’évolution de la puissance de calcul fait que les solutions de chiffrement actuelles seront certainement obsolètes un jour.

Pour terminer, quels conseils donnerais-tu à un jeune référent sécurité applicative ?

Un conseil pour les jeunes ingénieurs en cybersécurité, soyez patient et concentré. Les opportunités vont se présenter à vous, alors soyez prêt et présent le moment venu.

Ayez un esprit holistique, ne soyez pas que dans la technique. On peut être très bon techniquement, mais sous-estimer l’importance de la communication et de la gestion de projet. Ce ne sont pas des soft skills, ce sont des compétences indispensables à la gestion de projet. Pour proposer une solution, il faut être capable de la vendre, de faire du storytelling, savoir convaincre ses collègues comme son manager. Également, savoir donner du feedback, communiquer autour de son projet et le documenter pour que les autres puissent le prendre en main. C’est quelque chose que j’ai mis du temps à comprendre. Quand je l’ai compris, ça m’a beaucoup aidé.

Le mot de la fin ?

J’aimerais parler de l’avenir de l’AppSec, que j’imagine se développer autour d’un langage commun, une sorte de langage dédié (DSL) entre toutes les parties prenantes et exécutable par une machine. J’aimerais construire un écosystème autour de cette idée, avec l’objectif que ce langage soit utilisé par tous les acteurs. Un espéranto de l’App Sec, en quelque sorte !