Lorsque l'on parle de pare-feu applicatifs, on a tendance à regrouper différentes choses sous une même appellation. Mais tous les pare-feu ne sont pas identiques, et il est important de comprendre leurs différences, surtout si vous essayez de déterminer la protection dont votre application a réellement besoin.
Décomposons cela. Il existe trois couches principales de sécurité applicative à connaître : les WAF, la sécurité in-app et la sécurité in-kernel. Les RASP et certains ADR sont in-app, tandis que les ADR basés sur eBPF de niveau inférieur sont in-kernel. Ils ont tous le même objectif général d'empêcher que de mauvaises choses n'arrivent à votre application, mais la manière dont ils s'y prennent est très différente. En bref, le WAF voit la requête, la sécurité in-app voit le code, et la sécurité in-kernel voit le système d'exploitation.
De laquelle avez-vous besoin ? Eh bien, si vous souhaitez la posture de sécurité la plus robuste possible, il est fort probable que vous ayez besoin de plus d'une. Dans cet article, nous expliquerons ce que sont les WAF, RASP, ADR et eBPF, à quoi chacun est le plus efficace, et vous aiderons à décider lesquels d'entre eux vous avez besoin.
WAF VS RASP VS ASP : Comment fonctionnent les trois couches de sécurité applicative ?
Les outils de sécurité applicative opèrent à trois niveaux différents, et chacun détecte des éléments que les autres ne peuvent pas.
WAF : sécurité en périphérie
Les WAF se situent entièrement en dehors de votre application, inspectant le trafic HTTP entrant avant qu'il n'atteigne votre application. Pas de contexte applicatif, mais excellent pour les menaces à fort volume.
Sécurité runtime in-app : à l'intérieur de l'application
Les instruments de sécurité in-app s'intègrent directement à votre application. Ils s'accrochent à l'exécution de votre code, tracent la manière dont les entrées utilisateur circulent dans votre application et peuvent bloquer les attaques au point précis où elles deviennent dangereuses, avant qu'une charge utile malveillante n'atteigne votre pilote de base de données ou ne génère un shell. Parce qu'il dispose d'un contexte applicatif complet, il est précis. Les outils RASP, une sous-catégorie d'ADR, entrent dans cette catégorie.
Sécurité runtime in-kernel : sous l'application
Les outils de sécurité runtime in-kernel se situent entièrement en dessous de votre application, au niveau de l'OS. Au lieu de s'accrocher au code de l'application, il surveille chaque appel système (syscall) effectué par chaque processus sur l'hôte. Il n'a aucune idée de ce que fait la logique de votre application, mais il voit tout au niveau de l'OS, y compris ce qui se passe après qu'un attaquant ait déjà pénétré. Les outils ADR basés sur eBPF entrent dans cette catégorie.
Nous examinerons d'abord les WAF, puis la sécurité in-app et in-kernel à travers le prisme des RASP et ADR.
Qu'est-ce qu'un WAF ?
Un WAF (Web Application Firewall) se positionne en périphérie de votre application. Avant même qu'une requête n'atteigne votre application, le WAF l'intercepte et la compare à une liste de modèles d'attaque connus, tels que les chaînes d'injection SQL, les en-têtes malveillants ou les URL suspectes. Si une correspondance est trouvée, la requête est bloquée.
Les WAF sont véritablement irremplaçables face aux attaques volumétriques, telles que le trafic DDoS, les inondations de bots et les scrapers. Ils sont conçus pour gérer des volumes élevés et des attaques par force brute. Cloudflare, par exemple, excelle à absorber les attaques à grande échelle avant qu'elles n'interagissent avec votre infrastructure. Ils sont également faciles à déployer. Il s'agit principalement d'une modification DNS ou de proxy, sans code à écrire ni installation à effectuer au sein de votre application. Les WAF sont aussi très configurables avec des règles personnalisées, des listes d'autorisation (allowlists) et un ajustement des règles, et vous pouvez décider de bloquer un élément suspect ou simplement de le détecter.
L'inconvénient est qu'un WAF n'a aucune idée de ce qui se passe une fois qu'une requête a franchi la porte. Il peut repérer une charge utile (payload) suspecte, mais il ne peut pas vous dire si cette charge utile va réellement faire quelque chose de dangereux, car il ignore ce que votre application va faire de la requête. Il voit le trafic entrant, effectue une correspondance de motifs (pattern-matching) avec ce qu'il a été configuré pour bloquer, et décide s'il doit le bloquer.
En conséquence, les faux positifs sont un réel problème, et il peut facilement bloquer excessivement des requêtes. Un utilisateur peut rechercher quelque chose qui ressemble à du SQL et être bloqué, tandis qu'un attaquant astucieux encode sa charge utile différemment et passe au travers. Et si un WAF veut arrêter un utilisateur malveillant, il bloque son adresse IP. Un attaquant peut alors simplement utiliser un VPN pour contourner cette mesure. Mais si vous tentez ensuite de bloquer tout le trafic provenant du VPN, vous bloquez également des utilisateurs légitimes.
Par conséquent, l'ajustement (tuning) d'un WAF est un processus continu où vous resserrez les règles, surveillez les faux positifs et les assouplissez si nécessaire. C'est l'une des raisons pour lesquelles les WAF peuvent être exigeants en maintenance par rapport au RASP, qui nécessite beaucoup moins d'ajustements continus car il dispose du contexte applicatif pour prendre de meilleures décisions sans intervention manuelle.
Exemples : Cloudflare, AWS WAF, Imperva
Open source : ModSecurity (via OWASP)
Qu'est-ce qu'un RASP ?
Le RASP (Runtime Application Self-Protection) et l'ADR in-app sont des solutions de sécurité runtime qui résident à l'intérieur de votre application et la surveillent de l'intérieur pendant son exécution, au lieu de se positionner en dehors de votre application pour inspecter le trafic entrant comme un WAF.
Pour comprendre l'importance de cela, il faut connaître les "sinks" (puits de données). Un "sink" est une fonction — dans votre code, une bibliothèque ou un module intégré — où l'entrée utilisateur cesse d'être une simple donnée pour être exécutée comme quelque chose de significatif. Prenons l'exemple d'une injection SQL. Un attaquant insère du code malveillant dans un champ de formulaire, lequel traverse votre application, atteint votre pilote de base de données (certains db.query()), et à ce moment-là, elle cesse d'être du texte pour devenir une commande. Cette fonction de requête est le "sink". Ce que font les outils de sécurité in-app comme le RASP, c'est de s'accrocher à ces "sinks" et d'observer le mouvement des entrées à travers l'application, en les traçant jusqu'à la fonction dangereuse.
Parce que ces outils in-app s'exécutent, eh bien, à l'intérieur de votre application, ils savent ce qu'est l'entrée, d'où elle vient et où elle va. Au lieu de deviner si ' OR 1=1-- est une attaque ou une chaîne de recherche légitime, un outil in-app sait que cette chaîne spécifique provient de req.body.user, a été concaténée sans assainissement, et est sur le point d'atteindre un pg.query() appel. Bloquez-le !
Les taux de faux positifs sont bien inférieurs à ceux des WAF et des ADR basés sur eBPF, car il ne s'agit pas d'une simple correspondance de motifs aveugle. Il peut bloquer un ID utilisateur plutôt qu'une simple adresse IP, de sorte qu'un attaquant ne peut pas simplement utiliser un VPN. Et parce qu'il trace le flux de données plutôt que de faire correspondre des signatures connues, il peut détecter de nouvelles charges utiles d'attaque que personne n'a jamais vues auparavant. Une couverture solide contre les attaques de type injection de type "zero-day" !
Le RASP et les ADR in-app couvrent également les dépendances tierces. Vous pouvez assainir parfaitement votre propre code, mais si une bibliothèque que vous utilisez présente une vulnérabilité, cela échappe à votre contrôle (si votre scanner SCA ne l'a pas non plus détectée). Le RASP opère au niveau du "sink", quelle que soit l'origine du code.
La principale limitation de la sécurité in-app est que si un attaquant contourne entièrement le runtime, via un addon natif ou un appel système direct (syscall), les hooks ne se déclenchent jamais. Et une fois qu'un shell est généré, le RASP voit l'appel initial mais pas ce qui se passe à l'intérieur de ce shell par la suite. C'est là qu'intervient la troisième couche.
Exemples : Aikido Zen (open source et version payante)
Qu'est-ce que l'ADR ?
L'ADR (Application Detection and Response) est la catégorie moderne plus large dans laquelle s'inscrit le RASP. Tout RASP est de l'ADR, mais tout ADR n'est pas du RASP. Le terme ADR couvre tout outil qui surveille et répond aux attaques en temps d'exécution, que ce soit depuis l'intérieur de votre application ou entièrement en dessous.
En pratique, les outils ADR se divisent en deux catégories. L'ADR in-app (ce que le RASP a toujours été) s'intègre directement dans votre application et dispose d'un contexte complet au niveau du code. Tout ce qui a été abordé dans la section RASP ci-dessus concernant la sécurité in-app s'applique ici. L'ADR implique également une portée plus large que le RASP ; tandis que le RASP est principalement un outil de blocage, l'ADR englobe également des capacités de détection, de visibilité et de réponse aux incidents. Tous les outils ADR ne font pas tout cela, mais c'est la direction dans laquelle évolue cette catégorie.
L'autre type d'ADR, l'ADR in-kernel, ou ADR basé sur eBPF, adopte une approche différente pour protéger les applications. Au lieu de s'accrocher à votre application, il se situe au niveau du noyau Linux et surveille chaque syscall effectué par chaque processus sur l'hôte. Il ne connaît rien de la logique de votre application, mais il voit tout au niveau de l'OS.
Une fois qu'un attaquant a généré un shell, l'ADR in-kernel offre le niveau de visibilité post-exploitation que l'ADR in-app ne peut pas voir. L'ADR in-kernel voit chaque commande exécutée à l'intérieur de ce shell, comme les lectures de fichiers, les appels réseau et les mouvements latéraux. Si un attaquant contourne entièrement le runtime, l'ADR voit toujours le execve quelle que soit la manière dont il a été déclenché. En pratique, le scénario le plus courant pour les applications Node.js est l'insertion d'un addon natif malveillant via une attaque de la chaîne d'approvisionnement (une dépendance compromise qui inclut du code natif que votre runtime n'inspecte pas).
eBPF (Extended Berkeley Packet Filter) est la technologie de noyau sous-jacente qui alimente les outils ADR in-kernel. eBPF permet d'attacher un programme de surveillance sécurisé au noyau Linux qui peut observer des événements spécifiques se produisant au niveau de l'OS, sans toucher au noyau lui-même. Normalement, si vous souhaitez ajouter une surveillance ou une logique personnalisée au niveau du noyau, vous devriez soit modifier directement le code source du noyau (risqué, complexe), soit écrire un module de noyau (également risqué car un bug peut faire planter tout le système). eBPF contourne cela en permettant d'injecter de petits programmes dans le noyau qui s'exécutent dans un environnement sandboxé. Ces programmes observent des syscalls spécifiques et les signalent à l'outil ADR, qui décide ensuite d'autoriser ou de bloquer l'action.
Le compromis avec l'ADR in-kernel, comme le WAF, est qu'il n'a aucun contexte applicatif. Il voit des appels système bruts, comme "le processus 4821 a exécuté un programme", mais n'a aucune idée de la requête HTTP ou de l'utilisateur qui l'a déclenché. Sans ce contexte, la sécurité in-kernel doit fonctionner sur la base de politiques, qui sont des règles telles que "ce processus ne devrait jamais générer de shell" ou "ce conteneur ne devrait jamais écrire dans ce répertoire". Cela fonctionne pour détecter les violations claires, mais cela le rend assez binaire, il manque donc de nuance.
Pour les attaques de type injection, comme l'injection SQL, l'ADR in-kernel est pratiquement aveugle. Au moment où l'attaque atteint la couche des syscalls, la charge utile SQL n'est que des octets bruts à l'intérieur d'un tampon réseau. Les exploits en runtime sont un autre angle mort. Certaines attaques se déclenchent entièrement à l'intérieur du runtime du langage, de sorte qu'elles ne créent jamais d'opération inhabituelle au niveau de l'OS avant qu'il ne soit trop tard.
Contrairement aux outils RASP traditionnels, ce type d'ADR ne nécessite pas de modifications du code de votre application pour être configuré. Cependant, sa configuration et ses exigences sont plus importantes que celles d'un WAF ou d'un RASP, car les outils ADR nécessitent généralement un noyau Linux relativement moderne et des privilèges système élevés.
Exemples : Tetragon, Falco, KubeArmor (open source)
Oligo ADR (commercial)
WAF, RASP, ADR, eBPF : Lequel me faut-il ?
Nous avons maintenant passé en revue de nombreux termes : WAF, RASP, ADR, eBPF, in-app, in-kernel. La réponse courte est que vous voulez une protection à plus d'une couche. La réponse plus longue dépend des couches. Quand il s'agit de RASP vs ADR, le RASP est une sous-catégorie de l'ADR, donc la question devient : voulez-vous une sécurité in-app, une sécurité in-kernel, ou les deux ?
Les différentes couches sont complémentaires et non concurrentes, car chacune détecte des éléments que les autres ne peuvent pas. C'est pourquoi la réponse à "WAF ou RASP ?" est généralement "les deux", et l'ajout d'un ADR in-kernel en plus vous apporte la couverture post-exploitation et au niveau du noyau qui complète le tableau.
Les trois couches posent des questions fondamentalement différentes :
- WAF : "Cette requête HTTP correspond-elle à un modèle d'attaque connu ?"
- Sécurité in-app (RASP et ADR) : "Cette entrée utilisateur est-elle sur le point d'atteindre une fonction dangereuse dans mon application ?"
- Sécurité in-kernel (ADR) : "Ce processus vient-il de faire quelque chose qu'il n'aurait pas dû faire au niveau du système d'exploitation ?"
TL;DR : Obtenez d'abord un WAF et un outil de sécurité in-app. Procurez-vous un ADR basé sur eBPF plus tard si vous avez besoin d'un traitement spécifique au niveau du noyau.
La sécurité in-app, comme le RASP, est la seule couche qui dispose d'un contexte sur la manière dont les données interagissent avec l'application spécifique, c'est donc la seule couche capable d'effectuer un blocage vraiment précis. Naturellement, elle présente donc le moins de faux positifs par rapport aux deux autres. Alors que la protection en temps d’exécution in-app peut gérer la plupart des attaques au niveau de l'application ou par injection, un WAF est nécessaire pour les attaques à fort volume, comme les DDoS. Parce que les WAFs se situent en dehors de l'application, ils peuvent gérer des milliers de requêtes de bots avant qu'elles n'atteignent votre application et ne touchent ces ressources, et cela ne nécessite pas beaucoup de contexte pour fonctionner. Ensemble, la sécurité in-app comme Aikido Zen combinée à un WAF couvrira la grande majorité des problèmes que vous rencontrerez.
Si vous en êtes au point où vous avez besoin d'une visibilité complète post-exploitation, êtes préoccupé par le mouvement latéral, ou avez besoin d'une application de politiques au niveau du noyau sur plusieurs processus, c'est le moment d'envisager d'ajouter un ADR in-kernel. C'est l'outil idéal pour une configuration de sécurité plus mature, bien que ce ne soit pas nécessairement la première chose à envisager. Certains outils ADR in-app couvrent plus de choses que d'autres. Aikido Zen, par exemple, surveille l'activité sortante (requêtes SQL, commandes shell, lectures de fichiers et appels HTTP sortants) effectuée par votre application. Et comparé à une configuration ADR in-kernel plus complexe, les équipes peuvent configurer Zen avec un simple npm install et une seule ligne de code.
La seule chose que l'ADR in-kernel couvre au-delà de Zen est ce qui se passe après qu'un shell a déjà été généré et que l'attaquant opère au niveau du système d'exploitation. Ainsi, Zen ne remplacera pas eBPF si vous avez besoin de cette visibilité complète post-exploitation et de l'application de politiques au niveau du noyau sur tous les processus. Cependant, pour la plupart des équipes, il couvre la surface d'attaque la plus critique (attaques par injection, zero-days et logique d'autorisation). Néanmoins, si vous utilisez un RASP différent qui ne couvre pas l'activité sortante et les injections SQL, vous pourriez avoir besoin d'eBPF plus tôt.
Zen d'Aikido : L'ADR moderne intégré à l'application
Bien qu'ils partagent des objectifs similaires, tous les outils de sécurité intégrés à l'application ne sont pas identiques. Les nouveaux ADR, tels que Zen, le pare-feu intégré à l’application open source d'Aikido, se situent dans le domaine de la sécurité intégrée à l'application, mais couvrent un périmètre qu'un outil RASP standard ne prend pas en charge.
Zen offre le contexte applicatif complet des RASP traditionnels, comme le taint tracing, le blocage au niveau du sink, la prise en compte des ID utilisateur et un faible taux de faux positifs. Mais en tant qu'ADR moderne, Zen surveille également l'activité sortante, à l'instar de l'ADR in-kernel. Cela inclut chaque requête SQL, commande shell, lecture de fichier et appel HTTP sortant effectué par votre application. Son algorithme de vulnérabilité est déterministe dès la première requête, éliminant ainsi le problème de démarrage à froid et la maintenance continue des règles que d'autres RASP exigent.
Zen va également au-delà des attaques de type injection. Il analyse chaque requête SQL à l'exécution à l'aide d'un analyseur SQL complet (développé en Rust) et applique le cloisonnement des tenants automatiquement. Si une requête manque d'un filtre de tenant ou utilise le mauvais ID de tenant, Zen génère une erreur avant son déploiement. Les IDOR (références d'objets directs non sécurisées) sont la cause la plus fréquente de fuites de données inter-tenants dans les SaaS multi-tenants, et elles sont notoirement difficiles à détecter lors des code reviews. Zen rend leur déploiement accidentel impossible.
Pour en savoir plus : Prévention des attaques zero-day pour Node.js avec Aikido Zen
Questions fréquentes
Qu'est-ce qu'un WAF ?
Un WAF (Web Application Firewall) se situe en dehors de votre application et inspecte le trafic HTTP entrant à la recherche de modèles d'attaque connus. Il est particulièrement efficace pour gérer les menaces volumétriques comme les attaques DDoS et le trafic de bots, mais il n'a aucune visibilité sur ce que votre application fait réellement d'une requête.
Qu'est-ce que la sécurité RASP ?
Le RASP (Runtime Application Self-Protection) est un outil de sécurité qui s'exécute à l'intérieur de votre application. Il surveille la manière dont les entrées utilisateur circulent dans votre code et bloque les attaques au point où elles deviennent dangereuses : le sink. Parce qu'il dispose d'un contexte applicatif complet, il est bien plus précis qu'un WAF pour les attaques de type injection.
Quelle est la différence entre un WAF et un RASP ?
Un WAF se situe en dehors de votre application et bloque le trafic en fonction de modèles. Un RASP se situe au sein de votre application et bloque les attaques en fonction de ce que votre code est réellement sur le point de faire avec les entrées utilisateur. Les WAF sont plus faciles à déployer et excellents pour les menaces volumétriques. Les RASP ont des taux de faux positifs plus faibles et une meilleure couverture pour les attaques par injection et les zero-days.
Ai-je besoin à la fois d'un WAF et d'un RASP ?
Oui, ils sont complémentaires, pas concurrents. Un WAF gère la protection au niveau de la périphérie et le trafic volumétrique. Un RASP gère les attaques de type injection et les zero-days que les WAF manquent régulièrement. La plupart des configurations de sécurité matures utilisent les deux.
Qu'est-ce que l'ADR vs RASP ?
En général, l'ADR couvre les outils qui fournissent une sécurité in-app ou in-kernel. Le RASP fait référence aux outils in-app, et ils sont un sous-ensemble de l'ADR. Le RASP et l'ADR in-app sont techniquement la même approche, juste des étiquettes différentes au fil du temps. L'étiquette ADR est plus récente et plus large. Parfois, l'ADR est utilisé comme raccourci ou de manière interchangeable avec eBPF, les outils ADR basés sur le noyau. Les termes pour RASP et ADR varient légèrement selon l'interlocuteur. Gardez cela à l'esprit lorsque vous ferez d'autres recherches sur le sujet.
Qu'est-ce que l'ADR / eBPF dans la sécurité des applications ?
L'ADR (Application Detection and Response) couvre la sécurité intégrée à l'application et au niveau du noyau. Les outils ADR in-kernel comme Tetragon ou Falco opèrent au niveau du noyau Linux, surveillant chaque appel système (syscall) sur chaque processus de l'hôte. Ils sont performants en matière de visibilité post-exploitation et de détection des contournements au niveau du noyau, mais n'ont aucun contexte applicatif, ce qui les rend complémentaires au RASP plutôt qu'un remplacement. eBPF (Extended Berkeley Packet Filter) est la technologie de noyau sous-jacente qui alimente les outils ADR in-kernel.
Si vous assainissez toutes les entrées correctement, ai-je toujours besoin d'un RASP ?
Oui. L'assainissement est difficile à réaliser parfaitement en permanence. Surtout si les outils SAST et de qualité de code sont absents pendant le développement, des failles de sécurité peuvent se glisser dans la base de code. Considérez-le moins comme un remplacement des bonnes pratiques de codage sécurisé et davantage comme un garde-fou à l'exécution lorsque ces pratiques ne sont pas parfaites (ce qui, en pratique, n'est jamais le cas). Le RASP arrête également les problèmes provenant des dépendances tierces.
