Automatisez la sécurité avec F5 NGINX App Protect et F5 NGINX Plus pour réduire le coût des violations

Vous pourriez être surpris d’apprendre que l’argent que vous dépensez pour améliorer votre posture de sécurité grâce à l’automatisation et à l’intelligence artificielle (IA) finit par vous faire économiser des sommes bien plus importantes. Dans son rapport Cost of a Data Breach 2021 , l'équipe IBM Security révèle qu'une faille de sécurité coûte aux organisations sans automatisation de la sécurité et sans IA 80 % de plus en moyenne que les organisations avec automatisation et IA entièrement déployées - 6,71 millions de dollars contre 2,90 millions de dollars , soit une différence de 3,81 millions de dollars . En donnant la priorité à l’automatisation de la sécurité et à l’IA, les organisations peuvent identifier et contenir plus rapidement une violation, économisant ainsi de l’argent et du temps.

Cependant, lorsque vous intégrez la sécurité dans votre pipeline CI/CD, il est important de ne pas surcharger vos outils. Moins vous inspectez le trafic, moins vous introduisez de latence. Le corollaire commercial est que la complexité technique est l’ennemi de l’agilité.

Chez F5 NGINX, nous proposons une plateforme de sécurité unique dans son intégration transparente et sa capacité à aider les équipes à « déplacer la sécurité vers la gauche » pendant le cycle de vie du développement logiciel. Lorsque les organisations intègrent la « sécurité en tant que code » dans leur pipeline CI/CD, elles permettent l’automatisation de la sécurité et l’IA, ce qui conduit aux énormes économies décrites par IBM. La sécurité étant intégrée à chaque étape du développement des applications et des API, les fichiers de configuration et de politique de sécurité sont consommés sous forme de code et votre équipe SecOps peut créer et maintenir une politique de sécurité déclarative que DevOps peut utiliser lors de la création d'applications. Ces mêmes politiques peuvent être appliquées de manière répétée à de nouvelles applications, automatisant ainsi votre sécurité dans le pipeline CI/CD.

Commençons par éplucher l’oignon et examinons trois phases du traitement du trafic où F5 NGINX App Protect et F5 NGINX Plus vous aident à automatiser les protections de sécurité :

• Phase 1 – F5 NGINX App Protect DoS détecte et protège contre les attaques par déni de service (DoS)
• Phase 2 – F5 NGINX App Protect WAF protège contre les 10 principales attaques OWASP et les robots malveillants
• Phase 3 – F5 NGINX Plus authentifie les clients d'applications et d'API et applique les exigences d'autorisation à l'aide de fonctionnalités natives et d'intégrations avec des solutions d'authentification unique (SSO) tierces

Cette solution de sécurité en trois parties vous permet d'économiser de l'argent de deux manières, en particulier dans un environnement de cloud public :

1. Seul le trafic légitime atteint vos applications, car NGINX App Protect DoS filtre le trafic des attaques DoS, puis NGINX App Protect WAF élimine plusieurs vecteurs d'attaque comme le Top 10 de l'OWASP .
2. La conception hautement efficace et pilotée par les événements de NGINX Plus signifie qu'il peut traiter un grand nombre de requêtes par seconde avec une faible consommation de processeur. Traiter uniquement le trafic d'application légitime sur une plate-forme hautement efficace nécessite beaucoup moins de ressources de calcul, ce qui vous permet d'économiser du temps et de l'argent et de garantir une protection contre plusieurs vecteurs d'attaque sans surcharger vos outils.

Si vous utilisez actuellement F5 BIG-IP Advanced WAF pour sécuriser les applications exécutées dans votre centre de données, il est simple d'ajouter NGINX Plus comme contrôleur d'entrée pour Kubernetes avec NGINX App Protect Dos et WAF comme solution complète pour faire évoluer et sécuriser vos applications modernes et orchestrer les applications Kubernetes dans le cloud. En utilisant l'approche de sécurité en tant que code de F5, vous pouvez définir des contrôles d'infrastructure et de politique de sécurité sous forme de code via une API déclarative ou des définitions déclaratives au format JSON dans un fichier, et vous pouvez également convertir des fichiers XML BIG-IP en fichiers JSON. Vos politiques (les contrôles de sécurité d’entreprise standard détenus et maintenus par SecOps) peuvent résider dans un référentiel de code à partir duquel elles sont extraites et intégrées dans votre pipeline de développement comme n’importe quel autre élément de code. Cette approche aide DevOps et SecOps à combler les lacunes opérationnelles et à mettre les applications sur le marché plus rapidement, avec un coût moindre et une meilleure sécurité.

F5 intègre la construction et l'établissement de la politique WAF dans le processus de développement, un élément important du « déplacement de la sécurité vers la gauche » dans le pipeline de développement d'applications et de l'automatisation du déploiement des applications.

Les outils de visibilité de BIG-IP et NGINX se complètent et permettent à SecOps d’intégrer des processus d’automatisation dès le début de votre cycle de vie DevOps. BIG‑IP permet aux équipes de convertir des fichiers XML en fichiers JSON utilisés par NGINX pour maintenir vos politiques de sécurité cohérentes. NGINX permet aux équipes d’affiner les applications déjà en place, tout en apportant une automatisation moderne de la sécurité des applications pour aider à compenser les violations futures et le coût de ces attaques potentielles.

Phase 1 : NGINX App Protect DoS protège contre les attaques DoS

La première étape de notre parcours de gestion sécurisée du trafic consiste à éliminer les attaques par déni de service (DoS) . Mettre fin à ces abus dès le début est une première ligne de défense nécessaire.

Nous avons déjà constaté que les attaquants passent de plus en plus des attaques volumétriques traditionnelles à l’utilisation de requêtes HTTP et HTTPS ou d’appels API pour attaquer au niveau de la couche 7. Pourquoi? Ils suivent le chemin de moindre résistance. Les ingénieurs en infrastructure ont passé des années à créer des défenses efficaces contre les attaques de couche 3 et de couche 4, les rendant plus faciles à bloquer et moins susceptibles de réussir. Les attaques de couche 7 peuvent contourner ces défenses traditionnelles.

Toutes les attaques DoS ne sont pas volumétriques. Les attaques conçues pour consommer les ressources du serveur via des méthodes « lentes et lentes » comme Slow POST ou Slowloris peuvent être facilement cachées dans le trafic légitime. Et bien que les frameworks d'appel de procédure à distance HTTP/2 open source comme gRPC offrent la vitesse et la flexibilité nécessaires aux applications modernes, leur nature ouverte les rend potentiellement plus vulnérables aux attaques DoS que les protocoles propriétaires.

Contrairement aux protections DoS traditionnelles, NGINX App Protect DoS détecte les attaques actuelles en exploitant l'analyse automatisée du comportement des utilisateurs et des sites, les contrôles de santé proactifs et la configuration sans contact. Il s'agit d'une solution à faible latence pour arrêter les attaques courantes, notamment HTTP GET flood, HTTP POST flood, Slowloris, Slow read et Slow POST .

Pour lutter contre ces attaques, les équipes SecOps et DevOps doivent intégrer l’automatisation de la « sécurité en tant que code » dans leur flux de travail CI/CD, ce qui fait partie de l’état d’esprit shift-left. NGINX App Protect DoS permet cela. Il sécurise les applications et API modernes et distribuées avec une protection avancée contre les menaces DoS et aide à aligner les priorités parfois contradictoires de SecOps et DevOps en facilitant ce modèle avec un progiciel léger, une boucle de rétroaction continue d'atténuation des menaces et une intégration avec des outils DevOps familiers via des API RESTful.

NGINX App Protect DoS intègre la technologie d'apprentissage automatique (ML) que le rapport IBM Security met en évidence comme étant essentielle pour réaliser d'importantes économies de coûts. Il analyse le comportement du client et la santé de l'application pour modéliser les modèles de trafic normaux, utilise des algorithmes uniques pour créer un modèle statistique dynamique qui fournit les protections les plus précises et déploie des signatures dynamiques pour atténuer automatiquement les attaques. Il mesure également en permanence l’efficacité de l’atténuation et s’adapte aux changements de comportement ou aux conditions de santé. Ces fonctionnalités permettent à NGINX App Protect DoS de bloquer les attaques DoS où chaque demande d'attaque semble totalement légale, et un seul attaquant peut même générer moins de trafic que l'utilisateur légitime moyen.

Phase 2 : NGINX App Protect WAF protège contre le Top Ten de l'OWASP

Bien que la protection DoS empêche clairement le trafic malveillant de pénétrer dans votre infrastructure, les attaques peuvent toujours y parvenir. C'est pourquoi vous avez besoin d'un pare-feu d'application Web (WAF) pour la prochaine phase de défense réussie, où il se concentre sur le trafic provenant d'acteurs malveillants masqués comme légitimes.

Léger et performant, NGINX App Protect WAF offre une protection de sécurité complète qui inspecte les réponses, applique la conformité du protocole HTTP, détecte les techniques d'évasion, masque les numéros de carte de crédit et autres informations personnelles sensibles avec Data Guard, et vérifie les métacaractères et types de fichiers non autorisés, les JSON et XML mal formés et les paramètres sensibles. Il protège également contre le Top 10 OWASP mis à jour :

Contrôle d'accès brisé
Défaillances cryptographiques
Injection
Conception non sécurisée
Mauvaise configuration de sécurité
Composants vulnérables et obsolètes
Échecs d'identification et d'authentification
Défaillances en matière d'intégrité des logiciels et des données
Journalisation de sécurité et échecs de surveillance
Falsification de requête côté serveur

Il n’est pas surprenant que les cyberattaques contre les 10 principales vulnérabilités de l’OWASP telles que l’injection A03:2021 restent populaires. En juillet 2021, le site de commerce électronique open source WooCommerce a annoncé que plusieurs de ses plug-ins étaient vulnérables à l’injection SQL , et plusieurs attaques se produisaient à ce moment-là. Les entreprises et les clients opérant principalement en ligne, il est logique que les attaquants se concentrent sur les applications Web, qui sont souvent complexes, composées de microservices et s'étendent sur des environnements distribués avec de nombreuses API communiquant entre elles, augmentant ainsi le nombre de points de terminaison vulnérables à l'exploitation.

Les attaques modernes évoluent et s’adaptent également rapidement. C’est là qu’intervient l’IA et c’est pourquoi IBM a souligné son importance. Comme dans NGINX App Protect DoS, le système ML riche de NGINX App Protect WAF permet aux équipes Platform Ops, DevOps et SecOps de partager facilement les tendances et les données d'attaque. Une nouvelle fonctionnalité – la fonctionnalité d’évaluation adaptative des violations – permettra d’exploiter davantage le ML en détectant quand le comportement d’une application change. Grâce à cette capacité ML, NGINX App Protect WAF évalue en permanence le comportement prédictif de chaque application. Sur la base de cet apprentissage, il peut répondre aux demandes des clients qui seraient autrement bloquées, réduisant ainsi le score de violation d'une application et réduisant considérablement les faux positifs pour une meilleure expérience utilisateur avec des coûts de gestion inférieurs.

NGINX App Protect WAF fournit également une protection contre les robots. Aujourd’hui, près de 50 % du trafic Internet provient de robots . En éliminant en amont le trafic malveillant connu, NGINX App Protect WAF peut rapidement bloquer le trafic de robots à l'aide de sa base de données Bot Signature.

L’introduction de WAF comme couche de sécurité au début de votre pipeline CI/CD permet d’atténuer les risques de sécurité. Étant donné que NGINX App Protect WAF est compatible CI/CD, vous pouvez intégrer et automatiser la sécurité en tant que code dès le début de votre processus de développement d’applications. Grâce à une sensibilisation précoce à la sécurité et à une bonne collaboration entre les équipes, vous éliminez également les goulots d’étranglement tels que le risque de livraison. La protection DoS et WAF à plusieurs étapes crée de nombreux points d'inspection, offrant aux équipes de sécurité une visibilité sur l'utilisation des applications et aux équipes d'application une connaissance de la manière dont elles sont maintenues.

Phase 3 : NGINX Plus authentifie et autorise les clients d'applications et d'API

Même après que NGINX App Protect Dos et NGINX App Protect WAF ont éliminé le trafic malveillant, vous devez toujours vérifier que les clients sont légitimes et autorisés à accéder aux ressources qu'ils demandent. C'est là que NGINX Plus entre en scène, en gérant l'authentification et l'autorisation, puis en acheminant les demandes vers les serveurs appropriés. En déployant NGINX Plus en tant que passerelle API , vous pouvez fournir un point d’entrée cohérent pour plusieurs API et, encore une fois, simplifier votre pile.

L’authentification et l’autorisation peuvent également être automatisées avec l’authentification unique (SSO) pour permettre aux équipes DevOps de conserver l’agilité souhaitée. NGINX Plus prend en charge OpenID Connect (OIDC), une couche d'identité au-dessus du protocole OAuth 2.0 . Dans la documentation NGINX, nous expliquons comment utiliser OIDC pour activer SSO pour les applications proxyées par NGINX Plus .

Compte tenu de leur nature ouverte caractéristique, les API sont des cibles vulnérables. Dans son rapport annuel, Gartner Research a prédit que les API deviendraient le vecteur d'attaque le plus courant en 2022, provoquant d'innombrables violations de données pour les applications Web d'entreprise. Cette prédiction se révèle vraie alors que nous avançons en 2022 et observons que la surface d’attaque des API continue de croître dans les organisations.

Incidents d'authentification de l'API : Le rapport 2020 sur la protection des applications de F5 Labs met en évidence trois raisons courantes d'incidents d'API :

1. Aucune authentification aux points de terminaison de l'API
2. Authentification API interrompue
3. Autorisation API rompue

Aucune authentification aux points de terminaison de l'API

Lorsque vous implémentez l’authentification du trafic API, les clients qui prouvent avec succès leur identité reçoivent un jeton d’un fournisseur d’identité de confiance. Le client présente ensuite le jeton d’accès à chaque requête HTTP. Avant que la demande ne soit transmise à l'application, NGINX Plus assure l'authentification et l'autorisation du client en validant le jeton et en extrayant l'identité et d'autres données (appartenance à un groupe, par exemple) codées dans le jeton. En supposant que le jeton est validé et que le client est autorisé à accéder à la ressource, la demande est transmise au serveur d’applications. Il existe plusieurs méthodes pour réaliser cette validation, mais OpenID Connect (construit sur le protocole OAuth 2.0) est un moyen populaire d’activer l’authentification tierce des requêtes API.

Cependant, de nombreuses API sur le marché ne sont pas protégées au niveau de la couche d’authentification. En 2021, la plateforme de fitness interactive Peloton a révélé qu'elle avait une API non sécurisée . Un chercheur en sécurité a découvert qu'il était possible d'effectuer des requêtes non authentifiées auprès de l'API de Peloton, récupérant ainsi facilement les données des utilisateurs sans authentification. Bien que Peloton ait corrigé le code avant toute violation majeure, cet incident montre à quel point une approche monolithique de la sécurité ne prend pas en compte la multiplicité inhérente aux structures d'API et le besoin conséquent d'agilité pour les défendre.

Authentification API interrompue

Les API sont conçues pour connecter un ordinateur à un autre. De nombreuses équipes DevOps supposent donc que les humains ne communiquent pas avec le point de terminaison de l'API. Un exemple dans le rapport de F5 Labs concerne un chercheur qui a enchaîné plusieurs requêtes API pour « gagner » des centaines de milliers de dollars en crédits sur une application mobile. L’application générait en continu des jetons conçus pour empêcher les abus, mais ne leur fixait pas de date d’expiration, ce qui permettait de les utiliser à l’infini.

Si vous ne validez pas correctement les jetons d’authentification API, les attaquants peuvent exploiter les vulnérabilités de l’API. Si ce type de vulnérabilité est découvert par un mauvais acteur, plutôt que par un chercheur, il peut compromettre une entreprise entière.

Autorisation API rompue

Une authentification API infructueuse conduit naturellement à une autorisation API interrompue. Les rapports de F5 Labs décrivent également un incident au cours duquel un bug dans le système d'exploitation a permis des requêtes HTTP malveillantes vers l'API, donnant aux mauvais acteurs un accès facile aux jetons d'autorisation. Une fois que les attaquants ont acquis ce jeton d’autorisation, ils disposaient d’autorisations d’administrateur.

NGINX propose plusieurs approches pour protéger les API et authentifier les clients API. Pour plus d’informations, consultez la documentation relative aux listes de contrôle d’accès (ACL) basées sur les adresses IP , à l’authentification par certificat numérique et à l’authentification HTTP de base . De plus, NGINX Plus prend en charge nativement la validation des jetons Web JSON (JWT) pour l'authentification API. Pour en savoir plus, consultez Authentification des clients API avec JWT et NGINX Plus sur notre blog.

Commencez dès aujourd'hui

L’automatisation de la sécurité en fait la responsabilité de tous. En donnant la priorité à l’automatisation de la sécurité, votre organisation peut créer des applications plus fiables, atténuer les risques, réduire les dépenses d’exploitation et accélérer la vitesse de publication. Cela signifie que vos microservices, applications et API bénéficient d’une sécurité agile, évolutive et suffisamment rapide pour suivre le rythme de la concurrence actuelle.

Cette structure de sécurité en trois phases offre également le meilleur flux, car vous ne souhaitez pas paralyser votre WAF en inspectant le trafic provenant d'une attaque DoS ou gaspiller des ressources précieuses en essayant d'authentifier et d'autoriser les acteurs malveillants. En éliminant rapidement les attaques facilement identifiables, vous pouvez économiser du temps, de l’argent et accélérer les performances de votre application.

Prêt à essayer NGINX Plus et NGINX App Protect par vous-même ? Commencez un essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation .