C’est une fusion de CSPM (Cloud Security Posture Management, alerte sur les configurations risqués), CWPP (Cloud Workload Protection Platform, alerte sur les containers et VM), CIEM (Cloud Infrastructure Entitlement Management, mutualise l’IAM) et bien plus (Infrastructure as Code scanning, secret discovery…). Il y a une petite quinzaine d’éditeurs qui indique fournir ce type de service.
Ayant participé à plusieurs RFI/RFP sur le sujet. Voici des points d’attention quand vous ferez votre choix.
Chaque héro à une « origin story »
CNAPP est le terme à la mode en matière de sécurité cloud (pour d’excellente raisons). Chaque fournisseur va dire qu’il est un CNAPP complet mais en réalité il va avoir une expertise sur un secteur particulier (CSPM, CWPP ou CIEM dépendant de la fonctionnalité du produit original) et les autres seront un peu moins pertinent. Si vous utilisez beaucoup de containers/kubernetes, prendre un CNAPP qui vient d’un CWPP reconnu sera une stratégie cohérente. Au contraire, si vous utilisez massivement des ressources cloud, un CSPM sera plus indiqué.
Connaitre l’histoire de son fournisseur est important !
Le marché est encore jeune
Le marché à 3 ans avec une quinzaine d’acteurs. Certains sont en litiges juridiques, Wiz et Orca pour vol de propriété intellectuelle ce qui leur coute des marchés malgré leur statut de challenger/licorne. Il y a peu de “pure player”, la plupart sont soutenus par une grande compagnie (Microsoft, Palo Alto). Deviner qui sera encore là d’ici 3 ans est une question difficile (exemple de la tentative de rachat de Lacework par Wiz).
Savoir avec qui forger une relation est important pour sa sécurité cloud sur le long terme (des fusions/liquidations sont à attendre dans les 3 ans) !
Effet Frankenstein
Plusieurs fournisseurs ont commencé par une fonctionnalité mais plutôt que de développer par eux-mêmes les autres, ils ont simplement procédé au rachat de produit les couvrant. Le résultat ? Une interface inefficace car l’intégration n’est pas faite entre les produits : dans les scans de CI/CD vous voyez le code et des vulnérabilités mais vous ne pouvez pas identifier les containers où il est déployé. Il faut aller dans la partie container pour voir lesquels sont concernés. Cela va certainement aller en s’améliorant mais l’intégration est un processus lent.
Avoir accès à l’information pertinente de partout est clé tout comme la capacité d’intégration du fournisseur.
La contextualisation des risques
Dès que vous allez connecter votre CNAPP à vos environnements cloud, il va lever des milliers d’alertes, de quoi mettre en PLS vos équipes DevOps et Cyber. Heureusement la fonctionnalité de contextualisation des risques est là pour trier et prioriser les alertes suivant leur criticité.
Lors d’un test d’une solution, une vulnérabilité du plus haut niveau a été identifiée dans ma souscription Azure. Un peu surpris, je vais l’investiguer. Le problème est qu’il existait un NSG (Network Security Group) qui autorisait le port 22 depuis internet mais il n’était relié à aucune instance/sous-réseau. Le risque était nul et j’ai perdu du temps sur une alerte non pertinente...
La pertinence de la priorisation des alertes doit être confirmé lors du POC avant de signer !
Couverture des CSP
Assez évident mais la liste des CSP couverts peu drastiquement réduire la liste. Quasiment tout le monde couvre AWS/Azure/GCP mais des besoins sur OCI, Alibaba et IBM peuvent faire la différence et réduire votre liste de choix.
Attention aussi à ce que veut dire couvrir : toutes les ressources sont-elles bien vues ? L'IAM est-t 'il géré ?
Vérifier que les capacités sont équivalentes entre les CSP que vous utilisez est primordial.
Agentless
La plupart des solutions sont sans agent, à moins que vous ayez besoin de la partie CWPP. Pour avoir la meilleure vue sur Kubernetes, vous allez avoir besoin d’installer l’agent sur les différents nœuds. C’est relativement aisé et les procédures sont bien guidées. Cependant, il faut prendre en compte le potentiel impact de cet agent sur les performances. Il peut utiliser entre 300-700 Mo de Ram et 3-7% de CPU. Certains fournissent la fonctionnalité d’arrêt automatique de l’agent lors des pics de charge même si je la déconseille d’un point de vue sécurité.
Vérifier la consommation de l’agent et son impact potentiel sur vos applications est clé lors du POC.
Intégration
Chaque fournisseur promet une intégration très rapide avec vos ressources cloud qui apparaissent en moins de 2 heures. C’est le cas mais la partie la plus importante va être l’intégration avec vos outils : SIEM pour l’envoie des vulnérabilités les plus critiques, Jira ou équivalent pour créer des tickets que les développeurs doivent traiter, CMDB si vous voulez que vos ressources remontent dans vos outils classiques.
Il faut également vérifier que l’enregistrement se fait au niveau du tenant/organisation pour qu’aucune souscription/compte/projet n’échappe à la surveillance.
La capacité à écrire ses propres règles/contrôles est également clé et peut être nécessaire pour des clients exigeants à voir si cela peut se faire facilement (certains sont allergiques au Regex).
Interface
UI/UX est bien évidement clé, la première approche est de penser que c’est un outil de sécurité qui doit être utilisé par les équipes cyber. Mais il est bien plus efficace s’il est également utilisé par les équipes DevOps avec un contenu clair et pragmatique.
Ci-dessous une CVE où le vendeur n’a pas encore sorti de fix.
Et ici une explication pas à pas sur comment remédier.
Cela facilitera l’adoption du produit par les équipes opérationnelles pour éviter que les équipes cyber ne soit un goulot d’étranglement.
Le graphique du chemin d’attaque est également très efficace pour présenter un problème au management (pour arbitrage ou expliquer un incident).
Concurrent indirect
Outils natifs des CSP
Les 3 hyperscalers proposent leurs propres outils cela est un bon point de comparaison lors du POC. Ils sont pertinents et s’intègrent très bien entre eux dans le cadre d’usage d'un seul CSP. Mais la fragmentation de l’information dans plusieurs outils fait perdre en efficacité si on utilise plusieurs CSP.
Open Source
Choisir une solution Open-Source est compliqué car il faut tenir le rythme de mise à jour des CSP et des menaces. Un client s’est équipé d’un CSPM open source et malgré une dizaine de personnes dédiées à sa maintenance, il n’était pas possible de produire des contrôles pour plusieurs CSP sur les ressources demandées.
A noter : une question à poser aux éditeurs de CNAPP sur le temps pour couvrir des nouvelles ressources cloud avec leur contrôle (Azure Open AI est un bon exemple récent).
Conclusion
Je n’ai pas écrit un article sur pourquoi vous devez choisir un CNAPP car chaque fois que je le démontre à des RSSI, DevOps j’ai un effet “Wahou”. La question n’est pas « Allez-vous avoir besoin d’un CNAPP pour améliorer votre sécurité cloud ? » mais plutôt : « Quel CNAPP choisir ? »
À noter qu’au-delà de l’outil, mettre en place un processus clair et suivi de gestion des vulnérabilités sera un facteur clé de réussite de ce type de projet !
J’espère que cet article vous permettra de faire un choix éclairé !
Matthieu GAILLARD-MIDOL
Practice Leader CloudSec & SecOps
