Lorsque les gens parlent de pare-feu applicatifs, ils ont tendance à regrouper sous une même appellation toute une série d'éléments différents. Mais tous les pare-feu ne sont pas identiques, et il est important de comprendre les différences qui les distinguent, en particulier si vous essayez de déterminer la protection dont votre application a réellement besoin.
Voyons cela plus en détail. Il existe trois niveaux principaux de sécurité des applications que vous devez connaître : les WAF, les applications intégrées et les noyaux. Les RASP et certains ADR sont intégrés aux applications, tandis que les ADR de niveau inférieur basés sur eBPF sont intégrés aux noyaux. Ils ont tous le même objectif général, qui est d'empêcher que des événements indésirables ne se produisent dans votre application, mais leur mode de fonctionnement est très différent. En bref, le WAF voit la requête, l'application interne voit le code et le noyau interne voit le système d'exploitation.
Lequel vous faut-il ? Si vous souhaitez bénéficier d'une sécurité maximale, vous aurez probablement besoin de plusieurs solutions. Dans cet article, nous vous expliquons ce que sont les WAF, les RASP, les ADR et les eBPF, leurs domaines d'application respectifs, et nous vous aidons à choisir ceux qui vous conviennent le mieux.
WAF VS RASP VS ASP : comment fonctionnent les trois couches de sécurité des applications ?
Les outils de sécurité des applications fonctionnent à trois niveaux différents, chacun détectant des éléments que les autres ne peuvent pas détecter.
WAF : sécurité périphérique
Les WAF sont entièrement externes à votre application et inspectent le trafic HTTP entrant avant même qu'il n'atteigne votre application. Ils ne prennent pas en compte le contexte de l'application, mais sont très efficaces pour les menaces à haut volume.
Sécurité d'exécution dans l'application : à l'intérieur de l'application
Les instruments de sécurité intégrés à l'application s'intègrent directement à votre application. Ils s'intègrent à l'exécution de votre code, suivent le flux des entrées utilisateur dans votre application et peuvent bloquer les attaques au moment 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. Comme ils disposent d'un contexte d'application complet, ils sont précis. Les outils RASP, une sous-catégorie de l'ADR, entrent dans cette catégorie.
Sécurité d'exécution dans le noyau : sous l'application
Les outils de sécurité d'exécution intégrés au noyau se trouvent entièrement sous votre application, au niveau du système d'exploitation. Au lieu de s'accrocher au code de l'application, ils surveillent chaque appel système effectué par chaque processus sur l'hôte. Ils n'ont aucune idée de ce que fait la logique de votre application, mais ils voient tout au niveau du système d'exploitation, y compris ce qui se passe après qu'un pirate ait déjà pénétré dans le système. Les outils ADR basés sur eBPF entrent dans cette catégorie.
Nous examinerons d'abord le WAF, puis les applications et le noyau à travers le prisme du RASP et de l'ADR.
Qu'est-ce que le WAF ?
Un WAF ( pare-feu applicatif web) se trouve à l'extérieur de votre application, à la périphérie. Avant même qu'une requête n'atteigne votre application, le WAF l'intercepte et la compare à une liste de modèles d'attaques connus, tels que les chaînes d'injection SQL, les en-têtes malveillants ou les URL suspectes. Si quelque chose correspond à un modèle, il est bloqué.
Les WAF sont vraiment irremplaçables dans le cas d'attaques volumétriques, telles que le trafic DDoS, les inondations de bots et les scrapers. Les WAF sont conçus pour les attaques de force brute à haut volume. Cloudflare, par exemple, est extrêmement efficace pour absorber les attaques à grande échelle avant même qu'elles n'interagissent avec votre infrastructure. Ils sont également faciles à déployer. Il s'agit principalement d'un changement de DNS ou de proxy, sans code à écrire ni installation à effectuer dans votre application. Les WAF sont également très configurables avec des règles personnalisées, des listes d'autorisation et des réglages de règles. Vous pouvez également décider de bloquer ou simplement de détecter un élément suspect.
Le problème, c'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 détecter une charge utile suspecte, mais il ne peut pas vous dire si cette charge utile va réellement faire quelque chose de dangereux, car il n'a aucune idée de ce que votre application va réellement faire avec une requête. Il voit le trafic entrant, compare les modèles à ceux qu'il a été configuré pour bloquer et décide s'il faut le bloquer ou non.
Par conséquent, les faux positifs constituent un véritable problème et peuvent facilement entraîner un blocage excessif des requêtes. Un utilisateur peut rechercher quelque chose qui ressemble à du SQL et se faire bloquer, tandis qu'un pirate intelligent encode sa charge utile différemment et passe à travers les mailles du filet. Et si un WAF veut arrêter un utilisateur malveillant, il bloque son adresse IP. Le pirate peut alors simplement utiliser un VPN pour contourner le blocage. Mais si vous essayez ensuite de bloquer tout le trafic provenant du VPN, vous bloquez également les utilisateurs légitimes.
Par conséquent, le réglage du WAF est un processus continu qui consiste à renforcer les règles, à surveiller les faux positifs et à assouplir les règles si nécessaire. C'est l'une des raisons pour lesquelles les WAF peuvent nécessiter beaucoup d'entretien par rapport aux RASP, qui nécessitent beaucoup moins de réglages continus car ils disposent du contexte de l'application pour prendre de meilleures décisions sans intervention manuelle.
Exemples : Cloudflare, AWS WAF, Imperva
Open source : ModSecurity (via OWASP)
Qu'est-ce que le RASP ?
RASP (Runtime Application Self-Protection) et ADR intégré à l'application sont des dispositifs de sécurité d'exécution qui résident dans votre application et la surveillent de l'intérieur pendant son exécution, au lieu de se trouver à l'extérieur de votre application et d'inspecter le trafic entrant comme un WAP.
Pour comprendre pourquoi cela est important, vous devez connaître les sinks. Un sink est une fonction — dans votre code, une bibliothèque ou un module intégré — où les données saisies par l'utilisateur cessent d'être des données et sont exécutées comme quelque chose de significatif. Prenons l'exemple d'une injection SQL. Un pirate insère un code malveillant dans un champ de formulaire, qui circule dans votre application, atteint votre pilote de base de données (certains db.query()), et à ce moment-là, cela cesse d'être du texte et devient une commande. Cette fonction de requête est le collecteur. Les outils de sécurité intégrés aux applications, tels que RASP, se connectent à ces collecteurs et surveillent le passage des entrées dans l'application, en les suivant jusqu'à la fonction dangereuse.
Comme ces outils intégrés à l'application fonctionnent, eh bien, à l'intérieur même de votre application, ils connaissent la nature des données saisies, leur provenance et leur destination. Au lieu d'essayer de deviner si ' OU 1=1-- est une attaque ou une chaîne de recherche légitime, un outil intégré à l'application sait que cette chaîne spécifique provient de req.body.utilisateur, a été concaténé sans être nettoyé, et est sur le point d'atteindre un pg.query() Appelez. Bloquez-le !
Les taux de faux positifs sont bien inférieurs à ceux des solutions ADR basées sur WAF et eBPF, car il ne s'agit pas simplement d'une comparaison aveugle de modèles. Cette solution peut bloquer un identifiant utilisateur plutôt qu'une simple adresse IP, ce qui empêche les pirates d'utiliser un VPN. Et comme elle suit le flux de données plutôt que de comparer des signatures connues, elle peut détecter de nouvelles charges utiles d'attaque que personne n'a encore jamais vues. Une couverture zéro jour solide pour les attaques de type injection !
Le RASP et les ADR intégrés aux applications couvrent également les dépendances tierces. Vous pouvez parfaitement assainir votre propre code, mais si une bibliothèque que vous utilisez présente une vulnérabilité, cela échappe à votre contrôle (à moins que votre scanner SCA l'ait également détectée). Le RASP fonctionne au niveau du récepteur, quelle que soit la provenance du code.
La principale limite de la sécurité intégrée à l'application est que si un pirate contourne complètement le runtime, via un module complémentaire natif ou un appel système direct, les hooks ne se déclenchent jamais. Et une fois qu'un shell est généré, RASP voit l'appel initial, mais pas ce qui se passe ensuite à l'intérieur de ce shell. C'est là qu'intervient la troisième couche.
Exemples : Aikido ( versionopen source et version payante)
Qu'est-ce que l'ADR ?
L'ADR (Application Detection and Response, ou détection et réponse aux applications) est la catégorie moderne plus large dans laquelle s'inscrit le RASP. Tous les RASP sont des ADR, mais tous les ADR ne sont pas des RASP. Le terme ADR couvre tout outil qui surveille et répond aux attaques lors de l'exécution, qu'elles proviennent de l'intérieur de votre application ou d'un niveau inférieur.
Dans la pratique, les outils ADR se divisent en deux catégories. L'ADR intégré à l'application (ce qu'a toujours été le RASP) se trouve 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é intégrée à l'application s'applique ici. L'ADR implique également un champ d'application plus large que le RASP. Alors 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 que prend cette catégorie.
L'autre type d'ADR, l'ADR intégré au noyau ou ADR basé sur eBPF, adopte une approche différente pour protéger les applications. Au lieu de se connecter à votre application, il se situe au niveau du noyau Linux et surveille chaque appel système 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 du système d'exploitation.
Une fois qu'un attaquant a généré un shell, l'ADR intégré au noyau offre un niveau de visibilité post-exploitation supérieur à celui de l'ADR intégré à l'application. L'ADR intégré au noyau voit toutes les commandes exécutées dans ce shell, telles que 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 exécuter quelle que soit la manière dont elle a été déclenchée. En pratique, le scénario le plus courant pour les applications Node.js est celui d'un module complémentaire natif malveillant s'introduisant par le biais d'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 sous-jacente du noyau qui alimente les outils ADR intégrés au noyau. eBPF vous permet d'associer un programme de surveillance sécurisé au noyau Linux afin d'observer des événements spécifiques se produisant au niveau du système d'exploitation, sans toucher au noyau lui-même. Normalement, si vous souhaitez ajouter une surveillance ou une logique personnalisée au niveau du noyau, vous devez soit modifier directement le code source du noyau (ce qui est risqué et complexe), soit écrire un module de noyau (ce qui est également risqué, car un bug peut planter tout le système). eBPF contourne ce problème en vous permettant d'injecter de petits programmes dans le noyau qui s'exécutent dans un environnement sandboxé. Ces programmes observent des appels système spécifiques et envoient un rapport à l'outil ADR, qui décide alors d'autoriser ou de bloquer l'action.
Le compromis avec l'ADR intégré au noyau, comme le WAF, est qu'il n'a pas de contexte d'application. Il voit les 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é intégrée au noyau doit plutôt fonctionner à partir de politiques, qui sont des règles telles que « ce processus ne doit jamais générer un shell » ou « ce conteneur ne doit jamais écrire dans ce répertoire ». Cela permet de détecter les violations évidentes, mais cela rend le système assez binaire, sans nuances.
Pour les attaques de type injection, telles que les injections SQL, l'ADR intégré au noyau est pratiquement aveugle. Lorsque l'attaque atteint la couche syscall, la charge utile SQL n'est plus qu'une série d'octets bruts dans un tampon réseau. Les exploits en temps réel constituent un autre angle mort. Certaines attaques se déclenchent entièrement dans le runtime du langage, de sorte qu'elles ne génèrent aucune opération inhabituelle au niveau du système d'exploitation avant qu'il ne soit trop tard.
Contrairement aux outils RASP traditionnels, ce type d'ADR ne nécessite aucune modification du code de votre application pour être configuré. Cependant, sa configuration et ses exigences sont plus nombreuses 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 ?
À ce stade, nous avons passé en revue de nombreux termes : WAF, RASP, ADR, eBPF, in-app, in-kernel. En bref, vous souhaitez bénéficier d'une protection à plusieurs niveaux. La réponse plus détaillée dépend des niveaux concernés. En ce qui concerne RASP vs ADR, RASP est une sous-catégorie d'ADR. La question est donc la suivante : souhaitez-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'entre elles détecte des éléments que les autres ne peuvent pas détecter. C'est pourquoi la réponse à la question « WAF ou RASP ? » est généralement « les deux », et l'ajout d'un ADR dans le noyau vous offre une 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é intégrée à l'application (RASP et ADR) : « Cette saisie utilisateur est-elle susceptible d'affecter une fonction dangereuse de mon application ? »
- Sécurité intégrée au noyau (ADR) : « Ce processus vient-il d'effectuer une action qu'il n'aurait pas dû effectuer au niveau du système d'exploitation ? »
TL;DR : Procurez-vous d'abord un WAF et un outil de sécurité intégré à l'application. Procurez-vous ensuite un ADR alimenté par eBPF si vous avez besoin d'un traitement spécifique au niveau du noyau.
La sécurité intégrée à l'application, comme RASP, est la seule couche qui dispose d'informations contextuelles 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. Elle présente donc naturellement le moins de faux positifs par rapport aux deux autres. Alors que protection en temps d’exécution intégrée à l'application protection en temps d’exécution gérer la plupart des attaques au niveau de l'application ou des attaques par injection, le WAF est nécessaire pour les attaques à haut volume, comme les attaques DDoS. Comme les WAF se trouvent en dehors de l'application, ils peuvent traiter des milliers de requêtes de bots avant d'atteindre votre application et d'accéder à ces ressources, et cela ne nécessite pas beaucoup de contexte pour fonctionner. Ensemble, la sécurité intégrée à l'application comme Aikido et un WAF couvriront la grande majorité des problèmes que vous rencontrerez.
Si vous avez besoin d'une visibilité complète après l'exploitation, si vous êtes préoccupé par les mouvements latéraux ou si vous devez appliquer des politiques au niveau du noyau sur plusieurs processus, c'est le moment d'envisager l'ajout d'un ADR dans le noyau. C'est l'outil idéal pour une configuration de sécurité plus mature, même s'il ne s'agit pas nécessairement de la première solution à adopter. Certains outils ADR intégrés aux applications couvrent plus de fonctionnalités que d'autres. Aikido , par exemple, surveille les activités sortantes (requêtes SQL, commandes shell, lectures de fichiers et appels HTTP sortants) effectuées par votre application. Et par rapport à une configuration ADR au niveau du noyau plus complexe, les équipes peuvent configurer Zen à l'aide d'un seul npm install et une ligne de code.
La seule chose que l'ADR intégré au noyau couvre au-delà de Zen est ce qui se passe après qu'un shell a déjà été lancé et que l'attaquant opère au niveau du système d'exploitation. Zen ne remplacera donc pas eBPF si vous avez besoin d'une visibilité complète après l'exploitation et d'une application des politiques au niveau du noyau pour tous les processus, mais pour la plupart des équipes, il couvre la surface d'attaque la plus importante (attaques par injection, zero-days et logique d'autorisation). Cependant, si vous disposez d'un autre RASP qui ne couvre pas les activités sortantes et les injections SQL, vous pourriez avoir besoin d'eBPF plus rapidement.
Le zen issu de Aikido: l'ADR moderne intégré à l'application
Bien qu'ils aient des objectifs similaires, tous les outils de sécurité intégrés aux applications ne sont pas identiques. Les nouveaux ADR tels que Zen, pare-feu intégré à l’application open source pare-feu intégré à l’application Aikido, s'inscrivent dans le domaine de la sécurité intégrée aux applications, mais couvrent des aspects que les outils RASP standard ne prennent pas en charge.
Zen fournit le contexte complet des applications des RASP traditionnels, comme le traçage des contaminations, le blocage au niveau du récepteur, la reconnaissance des identifiants utilisateur, le faible taux de faux positifs, mais en tant qu'ADR moderne, Zen surveille également les activités sortantes comme le fait l'ADR intégré au noyau. Cela inclut toutes les requêtes SQL, les commandes shell, les lectures de fichiers et les appels HTTP sortants effectués par votre application. Son algorithme de vulnérabilité est déterministe dès la première requête, il n'y a donc pas de problème de démarrage à froid ni de maintenance continue des règles comme c'est le cas avec les autres RASP.
Zen va également au-delà des attaques de type injection. Il analyse chaque requête SQL lors de l'exécution à l'aide d'un analyseur SQL complet (intégré à Rust) et applique automatiquement la portée des locataires. Si une requête ne comporte pas de filtre de locataire ou utilise un identifiant de locataire incorrect, Zen génère une erreur avant son envoi. Les IDOR (références directes non sécurisées à des objets) sont la cause la plus fréquente de fuites de données entre locataires dans les SaaS multi-locataires, et elles sont réputées difficiles à détecter lors des revues de code. Zen rend leur déploiement accidentel impossible.
Pour aller plus loin : Prévention des attaques zero-day pour Node.js avec Aikido
Questions fréquentes
Qu'est-ce qu'un WAF ?
Un WAF ( pare-feu applicatif Web) se trouve à l'extérieur 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 telles que les attaques DDoS et le trafic des bots, mais il n'a aucune visibilité sur ce que votre application fait réellement avec une requête.
Qu'est-ce que la sécurité RASP ?
RASP (Runtime Application Self-Protection) est un outil de sécurité qui s'exécute au sein même de votre application. Il surveille la manière dont les données saisies par l'utilisateur transitent dans votre code et bloque les attaques au moment où elles deviennent dangereuses : au niveau du collecteur. Comme il dispose d'un contexte applicatif complet, il est beaucoup plus précis qu'un WAF pour les attaques de type injection.
Quelle est la différence entre WAF et RASP ?
Un WAF se trouve à l'extérieur de votre application et bloque le trafic en fonction de modèles. Un RASP se trouve à l'intérieur de votre application et bloque les attaques en fonction de ce que votre code est sur le point de faire avec les entrées utilisateur. Les WAF sont plus faciles à déployer et sont parfaits 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, ils ne sont pas en concurrence. 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 par rapport au RASP ?
En général, l'ADR couvre les outils qui fournissent une sécurité intégrée à l'application ou au noyau. Le RASP fait référence aux outils intégrés à l'application, qui constituent un sous-ensemble de l'ADR. Le RASP et l'ADR intégré à l'application sont techniquement la même approche, mais avec des appellations différentes au fil du temps. Le terme ADR est plus récent et plus large. Parfois, ADR est utilisé comme abréviation ou de manière interchangeable avec eBPF, les outils ADR basés sur le noyau. Les termes RASP et ADR varient légèrement selon les personnes. Gardez cela à l'esprit lorsque vous approfondirez vos 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 fois la sécurité dans les applications et dans le noyau. Les outils ARD intégrés au noyau, tels que Tetragon ou Falco, fonctionnent au niveau du noyau Linux et surveillent chaque appel système dans tous les processus de l'hôte. Ils offrent une excellente visibilité post-exploitation et détectent les contournements au niveau du noyau, mais ne disposent d'aucun contexte d'application, ce qui les rend complémentaires au RASP plutôt que de le remplacer. eBPF (Extended Berkeley Packet Filter) est la technologie de noyau sous-jacente qui alimente les outils ADR intégrés au noyau.
Si vous désinfectez correctement toutes les entrées, ai-je encore besoin de RASP ?
Oui. Il est difficile de toujours effectuer une désinfection parfaite. En particulier si les outils SAST de qualité du code font défaut pendant le développement, des failles de sécurité peuvent s'introduire dans le code source. Considérez-le moins comme un substitut à de bonnes pratiques de codage sécurisé et davantage comme un filet de sécurité lors de l'exécution lorsque ces pratiques ne sont pas parfaites (ce qui, dans la pratique, n'est bien sûr jamais le cas). Le RASP empêche également les problèmes provenant de dépendances tierces.
