BLOG

Les trois règles gérées par le pare-feu d'application Web AWS que vous devez déployer maintenant

Miniature de Lori MacVittie
Lori MacVittie
Publié le 18 avril 2018

Un nombre ahurissant d’applications résident dans le cloud sans aucune protection. Pas de pare-feu d'application Web. Aucun contrôle d'identité ou d'accès. Rien. Ils sont juste là, exposés aux attaques.

C’est un cauchemar pour les entreprises et un rêve devenu réalité pour les attaquants.

C’est également imprudent compte tenu de l’attention croissante accordée aux applications en tant que cibles. Qu’il s’agisse de trouver un chemin vers des sources de données riches ou d’exploiter l’application comme point de distribution à d’autres fins malveillantes, les attaques d’applications sont en augmentation.

En fait, si nous examinons les principales violations, nous constatons que 30 % d’entre elles impliquaient des attaques sur des applications Web. Un nombre significatif de 62 % des cas ont fait état d'un piratage visant à exploiter une vulnérabilité. Et un pourcentage stupéfiant de 77 % d’entre elles ont été perpétrées par des botnets, et non par des individus.

Cela signifie que vous devez protéger vos applications des robots et des vulnérabilités, de peur de devenir une simple statistique.

Et quand je dis vos applications, je veux dire toutes vos applications. Toutes les applications sont critiques en matière de sécurité , même dans le cloud. Peut-être encore plus dans le cloud où les applications peuvent être déployées sans même les protections rudimentaires offertes par un pare-feu réseau.

Mais nous ne pouvons pas (et ne devons pas) ignorer que la complexité – en particulier des solutions de sécurité – peut parfois entraver la protection des applications dans le cloud. Un peu plus d’un tiers (34 %) des répondants à notre enquête sur l’état de la fourniture d’applications 2018 nous ont indiqué que « la complexité croissante des solutions de sécurité » était l’un des principaux défis de sécurité pour l’année à venir.

La sécurité peut être difficile. Mais ce n’est pas forcément le cas, surtout dans le cloud.

Sécurité des applications Web dans le Cloud


Pour ceux qui ne le savent pas, AWS fournit une plate-forme assez intéressante non seulement pour vous permettre de déployer vos applications, mais également pour permettre aux fournisseurs d'y ajouter des fonctionnalités. Dans le domaine de la sécurité, son pare-feu d'application Web natif fournit des règles gérées par des tiers pour augmenter ses fonctionnalités. Cela signifie que vous pouvez vous protéger contre les menaces à l'origine des principales violations sans avoir besoin d'apprendre tous les tenants et aboutissants d'un pare-feu d'application Web. Si vous débutez, les règles gérées par AWS WAF sont un bon point de départ pour vous familiariser avec la sécurité des applications Web et vous protéger contre les menaces les plus courantes qui affectent les applications (et les entreprises) aujourd'hui.

Les règles gérées par AWS WAF sont simplement cela : des règles de sécurité pour applications Web qui étendent les fonctionnalités d'AWS WAF et assurent la protection de n'importe quelle application. Elles sont gérées, ce qui signifie que des experts en sécurité les maintiennent et les mettent à jour afin que vous puissiez avoir l'assurance qu'elles sont toujours à jour et qu'elles protègent contre les dernières menaces. C'est la sécurité en tant que service, dans le cloud, pour n'importe quelle application. 

Pour protéger vos applications contre trois des menaces les plus courantes (les robots, les vulnérabilités connues et le piratage), vous devez envisager de déployer trois règles différentes dès maintenant. Réfléchissez bien cependant, car vous ne pouvez choisir qu’une seule règle gérée à la fois.

Top 10 de l'OWASP

Le Top Ten de l'OWASP est bien connu des développeurs, des DevOps et des professionnels de la sécurité. Vous connaissez plusieurs de leurs noms : SQLi, XSS, injection de commande, injection No-SQLi, parcours de chemin et ressource prévisible. Voici les dix vulnérabilités les plus courantes qui finissent par donner des maux de tête aux organisations (et parfois des gros titres indésirables) lorsqu’elles sont exploitées. Et c’est souvent le cas, surtout lorsqu’on les trouve dans des applications qui communiquent avec des sources de données contenant des données intéressantes sur les consommateurs ou les entreprises.

Idéalement, les développeurs devraient les aborder dans le code lorsqu’ils sont découverts. En réalité, nous savons qu’il faut des mois pour que cela se produise (si jamais cela se produit). C’est pourquoi un pare-feu d’application Web capable de traiter ces vulnérabilités courantes est si précieux, car il offre une protection instantanée contre l’exploitation. Qu'il s'agisse d'une solution permanente ou d'une mesure provisoire, il est logique d'utiliser un ensemble de règles incluant le Top Ten de l'OWASP.

Vulnérabilités et expositions courantes (CVE)

L’importance de se protéger contre les CVE connus ne peut être surestimée.

En 2015, Kenna Security a publié un rapport sur une étude menée sur un échantillon de 50 000 organisations présentant 250 millions de vulnérabilités et plus d'un milliard (MILLIARDS) d'événements de violation et a découvert deux points très intéressants concernant la correction des vulnérabilités :

  • En moyenne, il faut aux entreprises 100 à 120 jours pour corriger les vulnérabilités.
  • Dans un délai de 40 à 60 jours, la probabilité qu’un CVE soit exploité atteint plus de 90 %.
  • L’écart entre le moment où une vulnérabilité est susceptible d’être exploitée et celui où elle est fermée est d’environ 60 jours.

En d’autres termes, la plupart des organisations risquent de voir une CVE exploitée avant d’avoir eu la possibilité de remédier à cette situation. Si vous n’avez pas fait attention, un certain nombre de violations de données *très* importantes ont été attribuées aux CVE. Genre, super méga uber haut profil. Considérez certaines des plateformes et bibliothèques avec des CVE : Apache, Apache Struts, Bash, Elasticsearch, IIS, JBoss, JSP, Java, Joomla, MySQL, Node.js, PHP, PHPMyAdmin, Perl, Ruby On Rails et WordPress. Cela couvre la plupart des applications sur Internet de nos jours.

Vous devez donc absolument utiliser des règles qui peuvent virtuellement protéger votre application contre l’exploitation des CVE dès qu’elles sont divulguées. Vous devez toujours les corriger à la source (généralement la plateforme ou la bibliothèque tierce), mais en attendant, votre application sera protégée contre une violation.

C’est cette lacune en matière de remédiation – et le manque d’expertise en matière de sécurité – qui font des règles gérées dans le cloud une si bonne idée. Des experts les maintiennent et s'assurent qu'ils sont à jour et capables de protéger les applications contre les exploits, tout ce que vous avez à faire est de les déployer.  

Protection contre les robots

De nos jours, plus de la moitié des visiteurs d’applications sont des robots. Et pas le genre de robots araignées qui parcourent votre site pour l'indexer et le rendre disponible via les moteurs de recherche. Nous parlons d’un robot de type Decepticon qui recherche des vulnérabilités, envoie du SPAM dans vos communautés, détruit votre site ou participe à un projet DDOS basé sur un botnet.

Se défendre contre les robots n’est pas facile. Les captchas essaient constamment de nouvelles méthodes pour identifier et bloquer les robots, mais comme la grippe saisonnière, ces bestioles embêtantes continuent de s'adapter et de contourner les défenses.

Cependant, les robots malveillants présentent des comportements qui peuvent être détectés et identifiés comme indésirables. Les règles de défense des bots sont capables de surveiller les comportements et activités qui signalent des intentions malveillantes et de les empêcher d'interagir avec votre application. Nous avons constaté une augmentation du pourcentage d’organisations qui profitent des services de défense contre les robots au cours des deux derniers trimestres, et nous nous attendons à ce que cela continue compte tenu de l’état actuel des choses.

Le déploiement d’une règle de protection contre les robots pour les applications dans le cloud peut fournir une couverture aérienne qui arrête l’exploitation CVE avant qu’elle ne se produise.

Pare-feu d'application Web ou règles gérées


Il est important de noter que certaines applications auront besoin d’une protection contre les trois menaces. D'autres encore auront besoin d'une protection contre plus que les robots, les CVE et le Top Ten de l'OWASP. Certains auront besoin d'un nettoyage des données et d'une prévention des fuites, ainsi que de défenses plus spécifiques aux applications. La validation de schéma est un bon exemple, en particulier lors de l’acceptation de données provenant de sources inconnues. Le DDoS L7 (couche applicative) en est un autre. L’application du protocole est également précieuse pour se protéger contre les vulnérabilités basées sur TCP ou HTTP. Si vous avez besoin de plus d'une (1) règle ou de protections supplémentaires, vous souhaiterez explorer un WAF avancé complet. Et à mesure que votre application se développe en termes de capacités et de clients, vous devrez également veiller à renforcer vos protections.

Quoi qu’il en soit, les règles gérées constituent un excellent moyen de démarrer avec la protection des applications dans le cloud. Ils fournissent une base solide pour la sécurité des applications Web sans que vous ayez besoin de devenir vous-même un expert en sécurité. 

Rejoignez AWS et F5 pour découvrir comment le WAF F5 peut vous aider à protéger vos données, à respecter les réglementations de conformité et à établir une protection continue pour vos charges de travail cloud.

Rejoignez le webinaire pour apprendre :

  • Considérations clés en matière d'application et d'architecture pour choisir le bon WAF
  • Comment les solutions WAF de F5 aident à protéger vos données contre les menaces connues et inconnues
  • Comment exploiter les capacités d'apprentissage automatisé pour empêcher même les attaques les plus sophistiquées sur vos données


Date et heure du webinaire :
Mercredi 25 avril 2018 | 10h00 PT

Inscrivez-vous maintenant >