L'interview sécurité : la boîte à outils défensifs et offensifs de Franck Desert Blog Devoteam Revolve

Temps de lecture : 11 minutes

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 Franck Désert, également connu sous le nom de Phenix dans les CTF (Capture the Flag). Avec une expérience de 30 ans dans le développement et la sécurité, Franck s’est aujourd’hui spécialisé en sécurité Cloud (OffSec/DefSec), avec un focus sur le Cloud Azure. Au cours de cet entretien, Franck nous livre sa vision du Cloud et de la sécurité, de l’évaluation des menaces et la définition des bonnes pratiques en passant par le déploiement d’outils défensifs ou offensifs.

La philosophie derrière les outils

Assurer la sécurité d’un environnement, c’est comme une opération militaire : il faut connaître le terrain le mieux possible et se préparer en conséquence. Actuellement, il y a une tendance à utiliser des outils tiers plutôt que des outils natifs, personnellement j’utilise le plus possible les outils natifs du Cloud public. Quelles que soient les ressources qu’on protège, de l’infrastructure, des machines, du PaaS, du SaaS, il sera difficile de bien faire son travail si on n’a pas utilisé les bonnes pratiques et les bons concepts de déploiement. Le premier outil de base, c’est le manuel, donc RTFM !

Dans AWS vous avez CloudFormation, GuardDuty, le CDK… privilégiez les outils natifs autant que possible. Les Cloud providers sont comme les compagnies aériennes, les enjeux financiers en cas de problèmes sont tellement élevés qu’ils prennent leur sécurité interne très au sérieux et dépensent des milliards à l’année, impossible à battre. Plus on se repose sur les SLA du Cloud, plus la responsabilité de la sécurité repose sur le Provider. Microsoft Security Response Center, ce sont 3000 personnes dédiées 24/7 à la sécurité.

Un exemple : le lock de ressources sur Azure

Quand on crée un resource group sur Azure, on peut le locker pour qu’il ne soit ni modifié ni effacé. J’ai mis en place cette fonction dans de nombreuses missions, ça a évité bien de mauvaises manipulations de déploiement, ou de manipulations humaines. Ici, on n’est pas dans une problématique de hacking, mais on adresse des enjeux de sécurité internes à l’entreprise. Il suffit que les gens travaillent en silo, ne communiquent pas pas et cela suffit pour créer des oublis ou toutes autres « misconfiguration ».

Chaque ressource qui a un cycle de vie dans le Cloud public devient un asset de valeur qu’il faut protéger. Peu importe le type d’infrastructure installée, celle-ci devient une valeur à part entière autant que le service ou l’application que l’on met en place. C’est le fameux « IaC » Infrastructure As Code qui accompagne tout projet désormais.

Les frameworks de bonnes pratiques

Après plus de 10 ans d’expérience dans le Cloud public, je peux affirmer que si on prend le temps d’appliquer le framework du Cloud provider, on corrige d’emblée 70% des problèmes. Le reste, c’est comprendre le legacy, les droits d’accès, les accès AD, les fondations du Cloud public, et souvent de connaître le contexte de l’entreprise en question.

L’infrastructure as code et l’automatisation sont aussi des outils, des façons de penser qui permettent d’élever le niveau de sécurité d’un système afin de reduire au maximum l’interaction humaine et de construire ce qui est utile au service en question programmatiquement.

Dans ces conditions, il est essentiel de démarrer le plus tôt possible un pipeline de CI/CD, que cela soit sur Gitlab, Github, Azure DevOps ou autre. La mise en place est un peut-être plus longue, mais industrialiser ses déploiements est nécessaire. Moins il y a d’intervention humaine, moins il y aura d’erreurs. Le pipeline oblige à tout anticiper en amont, avec une vision de l’objectif final désiré : l’état du réseau, VNet (Azure Virtual Network) et policies, les rôles assumés, la logique “at least”, les variables automatisées, etc. Cela permet aussi d’avoir un backlog. Les outils CI/CD permettent aussi de conserver de la mémoire collective au fil du temps pour l’entreprise.

Hybride ou multi cloud ?

Je suis absolument contre l’idée d’outils multi cloud. Il n’y a pas de magie, les Cloud public existants (AWS, Azure et GCP) proposent plus ou moins les mêmes services, mais ils ne se gèrent pas de la même manière. Ce n’est pas parce qu’on utilise Pulumi ou Terraform qu’on est multi Cloud. Rien que pour la gestion des accès et autre RBAC, les trois Clouds Publics cités ont tous leurs méthodes bien à eux et leurs concepts respectifs. Cela sera contre-productif de croire que l’on peut être efficace dans les deux ou trois cités, c’est déjà tellement difficile d’être performant et sécuritaire seulement dans l’un d’entre eux.

Inventorier les ressources du Cloud public

Pour bien protéger le Cloud public, il faut connaître l’ensemble des ressources. Or les entreprises connaissent rarement l’ensemble de leurs ressources dans le Cloud : combien de bases de données, de services inbound ou outbound, de comptes de service, etc. Je ne peux pas donner une posture de sécurité sans disposer d’un état des lieux et d’un inventaire des ressources. J’en profite d’ailleurs pour rappeler qu’il faut supprimer les comptes orphans dès que possible, voire supprimer tous les comptes qui n’ont pas été utilisés depuis 90 jours. Et si c’est nécessaire, on pourra toujours le créer à nouveau et souvent avec les nouvelles règles que l’entreprise peaufine au fil des des mois.

Si le catalogue n’est pas fait, deux outils extraordinaires peuvent y pallier. Microsoft Defender inventorie plus de 31 480 appweb et non web, et les classe avec un score de 0 à 10. Ce type de scan peut révéler les situations de shadow IT, parfois il peut s’agir d’un service web utilisé par très peu de personnes dans l’entreprise.

Microsoft recommande de changer de service en dessous de 4/10, pour ma part je considère que 6 est un minimum. Mais ça se discute, selon l’usage de l’outil.

Ensuite, il y a Microsoft Sentinel, un SIEM qui se connecte en moins de 25 minutes. Faire la même chose “on premise” représenterait 6 mois de travail et un budget énorme. AWS, GCP, Google Works Suite, peuvent aussi être intégrés avec des connecteurs. Quoiqu’il en soit, et aussi importants que soient les outils natifs Cloud, ce ne sont que des outils et ils ne remplacent pas votre expérience et votre connaissance du contexte. Si vous déployez un S3, ce ne sont pas ces outils qui vous diront comment gérer l’organisation, les accès des rôles, la visibilité du S3, le VPC, la protection du VPC, etc.

Des menaces internes aux menaces externes

Globalement, si on suit les bonnes pratiques, on couvre une bonne partie des risques, hormis les problèmes de mauvaise configuration. Rappelons que 72% des menaces viennent de l’intérieur (ces dernières années, le chiffre oscille entre 68 et 72) alors il faut se protéger des risques internes, que cela soit de la négligence ou de la malveillance. Il peut s’agir d’un employé mécontent, d’un employé qui a des problèmes d’argent, des dettes de jeu, etc. Vous ne connaissez jamais assez bien vos salariés dans leur vie privée, et cela peut coûter cher si quelqu’un a beaucoup trop de droits dans l’entreprise, il devient plus qu’une cible potentielle.

Coup de gueule

Je voudrais tordre le coup à une idée reçue, celle que les attaques (intrusions) sur le Cloud sont faites en blackbox. Pour rappel, une intrusion en blackbox signifie qu’on a aucune information sur l’entreprise interne, aucun accès, aucune connaissance de l’AD, etc. Il faut alors tout faire de l’extérieur: reconnaissance, phishing, social engineering, brute force… jusqu’à trouver des failles. Cela demande beaucoup, beaucoup de travail, et des moyens considérables, dont seuls des groupes de hackers professionnels ou des États voyous disposent.

95% des hacks du Cloud public sont hors de ce contexte et les 5% restants ne concernent que quelques mais comme précisé plus haut cela viendra souvent de l’intérieur. Ceci n’est plus du blackbox. Certes, il y a énormément de leaks d’informations comme les mots de passe (Have i been pwned est un excellent service existant depuis des années), mais cela ne donne pas un accès pour autant sachant si le 2FA a été mis en place par exemple. Mais avec du phishing qui passe mettant en place par exemple une forwarding rules non monitorées…là par contre, on peut avoir une faille de sécurité exploitable tout en étant en blackbox. Cependant cela demande des efforts et du temps assez conséquent. Du phishing qui passe, c’est tous les jours sur avec ce genre de “repository” sur github clone-wars, qui permet de générer des fakes de réseaux sociaux incroyablement crédibles. Mais vous comprendrez alors que tout le reste est soit en mode Greybox ou Whitebox c’est-à-dire avec des accès et beaucoup d’informations pour permettre ces attaques en vu d’un rapport de pentest ou de revues de sécurité, etc.

Toolbox du Cloud public

En préalable à la présentation de cet arsenal d’outils rassemblés par la communauté sur Github, je rappelle que les services natifs Cloud sont la base d’une bonne défense, en plus des bonnes pratiques : rôles “at least”, conditional access, privileged identity management… Si tout cela est fait correctement, il devient très difficile d’entrer vous appliquez alors la règle des 80-20%, c’est à dire que vous couvrez plus que vous ne pourriez être vulnérable. Attention je ne dis pas que vous ne l’êtes pas mais c’est plus compliqué de le mettre en application et demande effort, temps et argent.

Ensuite, on peut faire de l’hardening. Être vigilant sur toutes les erreurs humaines de développement, qu’elles soient dûes à la paresse, à une mauvaise configuration, ou à une mauvaise compréhension de l’architecture.

La liste des outils de sécurité défensive (blue team) :

Prowler, CIS benchmark en Python qui checke toutes les bonnes pratiques sécurité sur AWS
CloudMapper, pour analyser les environnements AWS
ScoutSuite, de l’audit sécurité multi Cloud, un des meilleurs outils à date (par NCC Group et Thomas Pornin, l’un des meilleurs cryptologues au monde)
CloudCustodian, un moteur de règles de gouvernance en yaml
CloudSploit Scans, un scanner de sécurité pour les environnements AWS (NodeJS)
CloudTracker, pour trouver tous les IAM en over privilège
AWS public IP : surveillez vos IP publiques ! Et réglez vos NSG comme il le faut.
PMapper, pour effectuer une évaluation automatisée des rôles IAM
SkyArk de Cyberark, pour découvrir et se protéger des situations de “cloud shadow IT” (existence non maîtrisée d’entités détenant des privilèges élevés)
Trailblazer AWS, pour identifier les appels d’API enregistrés par CloudTrail
Lunar, une boîte à outils basée sur plusieurs framework de sécurité
Cloud reports, pour scanner des ressources AWS et générer des rapports d’audit
Pacbot, une plateforme de monitoring de compliance et automatisation de la sécurité (“Policy as code”)
Antiope, un très bon outil d’inventaire de ressources AWS
Terraform AWS Secure baseline, un module Terraform pour configurer un compte AWS en intégrant les bonnes pratiques de sécurité de base.
TrailScrapper, pour récupérer de l’info de cloudtrail
LambdaGuard, un outil d’audit pour gérer ses lambdas (j ne l’ai pas testé, mais j’ai eu beaucoup de bons retours)
Perimeterator, outil de monitoring des périmètres, qui scanne toutes les ressources AWS exposées sur Internet
Zeus, un très bon produit d’audit et de hardening
Aws-security-viz, pour visualiser ses security groups, voir si on a des groupes en boucle par exemple
S3 exif cleaner, pour enlever tous les exif des objets sur S3
AWS firewall factory, pour déployer, updater et stager ses WAF

Puis toute la contrepartie, les outils offensifs (red team) pour attaquer votre système :

WeirdAAL, une librairie d’attaques AWS
Cred_scanner, un outil en ligne de commande pour trouver les informations d’identification AWS dans des fichiers
AWS PWN, un ensemble de scripts pour mener des tests d’intrusion d’environnements AWS
CloudJack, pour détecter dans les comptes AWS les vulnérabilités de détournement de sous-domaines résultant de configurations découplées de Route53 et CloudFront
Gitleaks, un outil SAST pour détecter et empêcher les secrets codés en dur (mots de passe, clés d’API, jetons) dans les dépôts git.
Enumerate-iam, pour inventorier les permissions associées aux credentials AWS
Whispers, pour identifier tous les secrets et comportements dangereux dans le code

Il existe a aussi des outils dédiés à la Purple team :

Leonidas, pour simuler des attaques
Cyber Ranges, pour déployer automatiquement une infrastructure simulée, avec des mauvaises configurations,qu’il faut découvrir et corriger
Aws-least-privilege, un script pour collecter des informations sur l’utilisation des ressources à partir de X-Ray et se mettre en conformité avec les principes de « Least Privilege » pour une application donnée.

Dans la catégorie Digital Forensics, réponse aux incidents et investigation : AWS IR, fargate IR, etc.

On trouve aussi de nombreux outils pour scanner les buckets S3, comme mass3, bucket-stream, s3-buckets-finders, s3finds, etc. Rappelons qu’il y a quelques années, les mauvaises configurations de S3 publics ont entaché la réputation d’AWS.

Pour terminer, je rappelle que les points d’entrée par défaut étant toujours le DNS et l’AD, si on protège correctement ses DNS (avec Cloudflare, par exemple), on couvre déjà une bonne partie des risques. Puisque ce genre de service est là pour absorber les DDOS par exemple ou bien pour “proxyser” votre IP de vos DNSs en questions, vous démarrez sur de bonnes bases et surtout vous envoyez un message aux méchants: on sait ce que l’on fait !

A voir également :

Et pour finir : la formation

C’est peut-être le plus important des outils. Formez, formez, formez ! Il n’y a pas d’école Cloud, il faut alors faire en sorte que vos équipes disposent de temps pour se former, s’enrichir, tester des choses, installer des environnements simulés, faire des CTFs ou des Gamedays.

Déployer et tester : le hands on est la meilleure des préparations. En sécurité, si on ne fait pas ça, on est out ! On est très vite dépassé si on ne met pas les mains dans le code en parallèle des missions d’architecture. Cela permet aussi de mieux estimer la charge de développement sur un besoin.

Par ailleurs, plus on accompagne la montée en compétence, moins il y aura de frictions pour faire avancer les sujets, et plus il sera facile de se projeter dans l’avenir. Cela permet aussi de véhiculer un message dans l’entreprise : la sécurité est un effet pour tout le monde, ce n’est pas fait que pour les dev ou les experts sécurité. La sécurité a besoin de pédagogie, il faut expliquer pourquoi, expliciter les enjeux et gagner l’écoute de ceux qui tiennent le budget. Un projet sécurité peut prendre 4 mois au lieu de 2, certes il aura coûté plus cher, mais ce sont des économies faites sur l’avenir. Pour une entreprise cotée en bourse, une faille de sécurité peut coûter bien plus cher.

Arbitrer entre livrer rapidement ou se protéger est toujours un choix stratégique, cependant si le temps est compté, il faut déterminer le niveau minimum de sécurité acceptable, puis itérer après la mise en production pour élever le niveau de protection.

A voir également, la conférence Splinternet de Franck Desert :