Ma journée est remplie de questions de clients actuels et potentiels. J’adore répondre à ce qui rend notre application Web et notre protection API (WAAP) et nos jeux de règles de sécurité si précis. La précision est essentielle lorsque l’on considère les attaques de nouveaux vecteurs d’attaque et vulnérabilités survenues ces dernières années. En fait, la Cybersecurity and Infrastructure Security Agency (CISA) a récemment ajouté 66 nouvelles vulnérabilités à son Catalogue des vulnérabilités exploitées connues, et les nouveaux CVE ont augmenté de plus de 25 % en 2022. CISA n’est pas le seul à se préoccuper de la sécurité et des performances. Selon une étude récente, les entreprises veulent réduire les faux positifs, les faux négatifs, la fatigue liée aux alertes et améliorer la gestion de la sécurité.
Qu’est-ce qui rend Edgio WAAP Rules plus efficaces ? À un niveau élevé, cela concerne l’ordre spécial dans lequel nous exécutons nos règles WAAP et notre mode de signature hybride et de notation des anomalies avec les règles gérées. Nous effectuons ces processus en quelques millisecondes via notre moteur waflz développé en interne pour assurer la sécurité sans sacrifier les performances. Plongeons-y plus en détail.
Peler l’oignon
Avant de passer en revue le fonctionnement interne de nos règles gérées, examinons les différentes couches (jeu de mots prévu) des protections dans notre WAAP. Chaque niveau du WAAP joue un rôle important. Les informations ci-dessous donnent un aperçu de ses fonctions.
Règles de contrôle d’accès
Les règles de contrôle d’accès offrent la possibilité de créer des listes d’autorisation modulaires, des listes de dénégation et des listes d’accès à sécurité positive pour contrôler l’accès aux sites protégés par adresse IP, proxy anonyme, pays, ASN, code géo-région, agent utilisateur, cookie, référent, URL, méthode de requête HTTP, type de contenu, extension de fichier, taille de fichier et en-têtes de requête.
Règles de limitation des tarifs
Les règles de limitation de débit limitent le flux de requêtes HTTP vers une application protégée par le WAAP afin d’empêcher le trafic DDoS d’application malveillant ou non intentionnel et d’empêcher les serveurs d’applications d’un client d’être surchargés par des requêtes provenant d’attaques ou de pics de trafic non planifiés.
Règles du gestionnaire de bots
Le gestionnaire de bots détecte les bons et les mauvais bots. Il fournit plusieurs options pour atténuer l’automatisation indésirable ou les mauvais bots et les empêche d’atteindre vos applications. Cela protège votre site contre les bots malveillants qui effectuent du bourrage d’informations d’identification, grattent votre contenu, carding, spamming vos formulaires, lancent des attaques DDoS, et commettre une fraude publicitaire.
Règles personnalisées
Les règles personnalisées mettent notre puissant moteur WAAP entre vos mains pour créer vos propres règles de sécurité. Le trafic malveillant est identifié à l’aide d’une combinaison de variables (en-têtes de requête, corps, requête, méthode, URL, cookie, etc.). Cette méthode offre une plus grande flexibilité pour la détection des menaces et vous permet de filtrer les requêtes malveillantes spécifiques et de prendre des mesures pour les atténuer. L’identification personnalisée des menaces associée à des tests et à un déploiement rapides vous permet de traiter rapidement les vulnérabilités à long terme et zero-day en créant des correctifs virtuels.
Règles gérées
Les règles gérées d’Edgio identifient le trafic malveillant via un jeu de règles propriétaire géré par Edgio.
Les règles gérées se composent de plus de 500 règles réparties dans trois catégories :
-
Règles de propriété Edgio.
-
Règles avancées spécifiques aux applications.
-
Règles OWASP génériques.
Il rassemble de manière exhaustive diverses politiques et règles de sécurité pour différentes catégories d’attaques et applications. Lors de l’exécution d’une évaluation des menaces, chaque règle gérée peut être personnalisée pour éviter les faux positifs en excluant certaines variables (cookies, en-têtes et chaîne de requête/paramètre de requête).
Comme vous pouvez le voir, nos règles WAAP ont de nombreuses couches, et au sein de chaque couche, il peut y avoir des dizaines à des centaines de règles et de conditions que notre WAAP doit exécuter. Chaque règle présente une probabilité d’introduction de faux positifs et d’impact sur les performances. Ce qui complique les choses, c’est que Edgio WAAP offre des capacités uniques pour fonctionner en mode Dual WAAP, où vous pouvez exécuter simultanément deux versions des configurations de sécurité pour votre trafic de production pour les règles de contrôle d’accès, les règles personnalisées et les règles gérées. Nous ajouterons des couches de protection supplémentaires à mesure que nous continuerons à améliorer nos solutions de sécurité. Ce qui soulève la question : comment pouvons-nous nous assurer que notre système WAAP traite des millions de demandes avec précision et efficacité dans le chaos de toutes ces fonctionnalités et règles ?
Créer de l’ordre à partir du chaos
En plus de disposer d’un puissant moteur waflz développé en interne, spécialement conçu pour évoluer dans un environnement multi-tenant hautes performances, la clé est de créer un ordre d’opérations approprié pour exécuter le WAAP de la manière la plus efficace et efficace possible.
Pour ce faire, notre WAAP exécute ses différentes couches de modules de règles dans l’ordre suivant :
-
Règles de contrôle d’accès : toutes les demandes sont filtrées par un ensemble statique de listes Autoriser/refuser/accéder configurées par le client, comprenant les variables mentionnées précédemment. Le WAAP supprime toute demande correspondant à la liste de refus, empêchant ainsi le traitement du trafic indésirable.
-
Règles de limitation de débit : les demandes passant par les règles de contrôle d’accès sont ensuite suivies par les règles de limitation de débit, qui suivent la demande pour chaque client dans une fenêtre temporelle spécifiée par la configuration. Le WAAP supprime les demandes dépassant un seuil de débit de demande particulier, réduisant encore les volumes de demandes de passer à l’étape suivante.
-
Règles du gestionnaire de bots : chaque requête atteignant cette étape est inspectée par notre plateforme ML pour déterminer si elle est basée sur des bots en fonction d’une combinaison de signatures et de comportements de requête. Toutes les requêtes malveillantes de bot peuvent être atténuées ici par divers moyens, y compris le défi du navigateur, la réponse personnalisée ou le captcha. La plupart des attaques sont effectuées via des clients automatisés, ce qui fait du gestionnaire de bots une solution efficace pour atténuer ces attaques et réduire davantage le volume de requêtes qui doivent être traitées par les modules de règles suivants.
-
Règles personnalisées : à cette étape, le WAAP inspecte la demande à l’aide de divers filtres personnalisés créés par les clients pour détecter et atténuer les demandes indésirables. Cela peut inclure toutes les règles spécifiques aux applications que les clients peuvent déployer en temps réel pour atténuer les vulnérabilités zero-day sans attendre la mise à jour du jeu de règles WAAP géré. C’est un outil inestimable pour gagner en visibilité et en contrôle sur des attaques spécifiques. En raison de la spécificité des règles personnalisées, elles ont priorité sur les règles gérées par Edgio et traiteront les requêtes avant de les transmettre à la couche finale.
-
Règles gérées : toute demande atteignant ce stade est traitée par les règles gérées 500+ dans les catégories propriétaires Edgio, spécifiques aux applications avancées et génériques OWASP.
Figure 1 : flux de travail Edgio WAAP
Le traitement de chaque demande en séquence (comme illustré à la figure 1) garantit l’exécution de plusieurs couches de filtrage. Cela nous aide à capturer les attaques que nos clients recherchent (par exemple, IP/pays dénombrés, flood DDoS/HTTP d’application, clients automatisés et signatures de requêtes personnalisées spécifiques) avant que les requêtes n’atteignent les règles gérées.
Cependant, cela ne représente qu’une partie de l’histoire de la sécurité.
L’efficacité d’un WAAP n’est pas déterminée uniquement par sa capacité à atténuer les attaques (vrais positifs), mais aussi par sa capacité à empêcher le blocage du trafic légitime (faux positifs). Voyons comment nous capturons la plupart des attaques d’applications tout en réduisant les faux positifs.
Une plongée plus approfondie dans Edgio Managed Rules
Lorsqu’une requête atteint les règles gérées, elle est évaluée par notre jeu de règles Edgio propriétaire de plus de 500 règles créées pour atténuer un large éventail d’attaques d’applications. Cela présente une couche supplémentaire de complexité car il existe de nombreuses catégories de règles [par exemple, les injections SQL génériques (SQLi), le cross-site scripting (XSS) et les règles d’exécution de code à distance (RCE)] et les règles spécifiques à WordPress, Joomla et Apache Struts. Une hiérarchisation minutieuse est nécessaire pour s’assurer qu’ils se complètent mutuellement afin d’optimiser la précision.
Comme pour les modules de règles mentionnés précédemment, la clé est l’ordre des opérations entre chaque catégorie du jeu de règles géré.
Dans les règles gérées, la demande est traitée par différentes catégories de règles dans cet ordre : règles propriétaires Edgio > règles spécifiques à l’application avancées > règles OWASP génériques.
-
Les règles propriétaires Edgio et les règles spécifiques aux applications recherchent les signatures associées à une vulnérabilité spécifique d’un type d’application spécifique. Ces règles couvrent les applications (Apache Struts, WordPress, Joomla, Drupal, SharePoint, cPanel, etc.) et sont extrêmement précis dans la détection des attaques contre ces applications. Nous avons conçu ces règles pour qu’elles s’exécutent en mode Signature (alias binaire), ce qui signifie que toute requête déclenchant ces règles provoque une action. Ces règles fournissent une approche plus chirurgicale pour faire correspondre et filtrer des vecteurs d’attaque spécifiques à une application ; elles constituent donc la première couche du filtre Edgio Ruleset. Étant donné que les requêtes ne correspondant pas aux règles propriétaires et spécifiques à l’application peuvent toujours présenter un risque pour l’application du client, nous avons besoin d’une autre approche pour détecter les attaques potentielles dans la phase suivante.
-
Les règles OWASP génériques dans le jeu de règles Edgio recherchent une combinaison de signatures associées à différentes catégories communes d’attaques (par exemple, SQLi, XSS, RCE, violation de protocole, inclusion de fichier local (LFI), inclusion de fichier distant (RFI), et plus encore). Ces règles fonctionnent ensemble pour déterminer si une requête présente une combinaison de signatures correspondant à une catégorie d’attaque. Ces règles génériques s’exécutent en mode de notation d’anomalie qui permet aux clients de définir la sensibilité des règles en ajustant le seuil de notation d’anomalie pour contrôler le nombre de règles à déclencher pour que la demande soit considérée comme malveillante. Plus le seuil de score d’anomalie est bas, plus le jeu de règles générique devient sensible ou strict et plus il est facile pour une requête potentiellement malveillante de dépasser le seuil. Les clients ont la possibilité d’ajuster la sensibilité de leur WAAP en fonction du type d’application et de leur tolérance au risque. Les règles OWASP génériques servent de fourre-tout final pour les requêtes qui correspondent à une caractéristique d’attaque particulière, mais ne correspondent pas nécessairement à des vulnérabilités d’application spécifiques.
Figure 2 : nos règles gérées s’exécutent dans une séquence spécialement conçue pour optimiser la détection et minimiser les faux positifs.
Une autre caractéristique importante qui améliore la précision des règles gérées est la personnalisation des règles. Chacune des plus de 500 règles gérées peut être personnalisée pour ignorer des paramètres de requête spécifiques (par exemple, les paramètres d’en-tête de requête, de cookie, de requête et de corps). Cela permet aux clients de supprimer rapidement les faux positifs à l’aide d’une interface utilisateur simple ou d’une API.
Assembler toutes les pièces
Vous avez maintenant entrepris le parcours d’une requête HTTP via notre WAAP. Quelque chose qui se produit des milliards de fois par jour sur chaque serveur Edgio dans les 300 points de présence (POP) dans le monde entier, car notre WAAP haute performance fonctionne nativement sur la même pile que celle qui exécute nos services de diffusion de contenu. Au début de ce blog, j’ai mentionné que je reçois beaucoup de questions sur notre WAAP. J’espère que vous comprenez maintenant ce qui la distingue des autres solutions. Nous combinons un ordre d’opérations intelligent avec les différents modules de règles WAAP (de l’ACL à la limitation de débit en passant par les règles bots et personnalisées), les règles gérées (des règles spécifiques aux règles génériques) et le mode hybride signature et notation des anomalies pour une sécurité qui n’entrave pas les performances.
Considérez cette analogie : concevoir et assembler des composants WAAP, c’est comme fabriquer un hamburger. Il ne s’agit pas seulement d’avoir les bons ingrédients ; il s’agit de les combiner de la bonne façon pour faire un bon repas. Les mêmes ingrédients assemblés différemment peuvent avoir un impact considérable sur le goût et l’expérience du client.
