Protection des applications – 5 pièges courants

This post is also available in: Anglais Allemand Italien Portugais - du Brésil Espagnol Russe

Les entreprises dépensent chaque année beaucoup d’argent pour acquérir les technologies de sécurité les plus récentes en vue de protéger la confidentialité de leurs données et l’expérience de leurs utilisateurs. Les RSSI se tournent vers l’apprentissage automatique, l’automatisation et l’orchestration de l’analyse des événements et des mesures de remédiation. Ils font confiance aux fournisseurs de Cloud public et à leurs intégrateurs de systèmes. Malgré cela, des violations de données sont encore à déplorer.

1^er piège – « Je pensais qu’un WAF suffisait »

Les menaces supplémentaires pour les applications dépassent depuis longtemps les exploits tirant parti des 10 principaux risques pour les applications Web répertoriés par l’OWASP. Oui, les injections, les scripts intersites, les CSRF, les détournements de session, les empoisonnements de cookies, etc. sont toujours d’actualité, d’autant plus que de nombreux systèmes vieillissants n’ont pas reçu de correctifs. Les équipes de développement mettent davantage l’accent sur l’agilité que sur la sécurité. Pourtant, la surface d’attaque, et donc l’exposition aux risques, est beaucoup plus grande aujourd’hui.

Trois autres menaces doivent être affrontées :

1. Bots malveillants – un quart du trafic Internet est généré par des bots malveillants [CB1]. Face à la forte sollicitation des réseaux et aux tentatives persistantes de prise de contrôle des comptes d’utilisateur, de manipulation des transactions en ligne et d’extraction des données sensibles, les entreprises ne peuvent plus se contenter de leur WAF – et encore moins perdre du temps à créer des scripts maison sur mesure –, elles commencent à envisager une technologie dédiée à la gestion des bots qui laisse entrer les bons bots et repousse les mauvais.

2. Protection des API – des systèmes et des applications interconnectés qui échangent des données via des API. On leur fait généralement confiance et ils peuvent donc facilement être négligés. Le vol de données par le biais d’API insuffisamment protégées a déjà défrayé la chronique à plusieurs reprises (PaneraBread, Venmo, Boots, etc.). Les entreprises ne savent pas toujours de quelles API elles disposent, quels types de données traitent ces API et qui peut y accéder. Elles ont besoin d’un outil efficace pour découvrir, classer et sécuriser tous leurs points de terminaison d’API.

3. Déni de service – cela fait belle lurette que ce problème ne concerne plus seulement les opérateurs de réseau. Les serveurs Web et les ressources numériques sont désormais fréquemment pris pour cible par des agresseurs désireux de perturber les services ou de mettre hors service un site Web. Il est parfaitement judicieux d’intégrer la protection contre les attaques DDoS à haut volume dans la stratégie de sécurité des applications.

2^e piège – « J’ai été tenté de combiner mon WAF avec le service CDN »

Oui, cela semble logique. Si vous vous préoccupez davantage des performances que des données sensibles de vos clients, c’est sans doute la voie à suivre. Mais si vous vous souciez de protéger les données de l’entreprise et des utilisateurs, vous devez reconsidérer ce compromis. Par la nature de son architecture, un WAF en périphérie de réseau ne voit pas le trafic lié à chaque application, il ne peut donc pas appliquer de mécanismes d’apprentissage, de détection d’anomalies et de sécurité positive, ce qui fait qu’il n’y a pas de protection « zero-day ». Ces applications sont susceptibles de provoquer des fuites de données car elles ne sont pas protégées contre les techniques d’attaque inconnues.

Dans les environnements de Cloud public, le problème est encore plus sérieux car la technologie WAF proposée par le fournisseur IaaS – et non par un fournisseur spécialisé – est généralement mal classée dans les rapports des analystes. Plus d’informations sur le sujet dans notre blog précédent

3^e piège – « Je peux instaurer la même sécurité sur toutes les plateformes »

C’est en effet un vrai casse-tête. Les entreprises, qui aimeraient appliquer la même politique de sécurité des applications à tous les environnements – centre(s) de données, Cloud privé, Azure, AWS, GCP, et Alibaba ou Tencent – sont obligées de trouver un compromis. Cela tient au fait que chaque environnement et chaque fournisseur requièrent des ajustements particuliers, par exemple en matière d’autorisations d’accès, de protection de l’infrastructure, de mécanismes d’authentification et d’autorisation, de contrôle du trafic de bots, d’outils de sécurité des API au niveau back-end, etc.

Si l’on privilégie la cohérence (par exemple un service Cloud géré), l’expérience utilisateur (latence) et la sécurité (voir le point 2 ci-dessus) font forcément l’objet d’un compromis. Si l’on choisit d’optimiser la sécurité, il faudra concevoir des solutions adaptées à chaque environnement, puis consacrer le temps et les ressources nécessaires à leur mise à jour régulière et à l’application de la politique de sécurité souhaitée par le RSSI.

Cette situation peu recommandable conduit à une posture de sécurité à failles multiples, dont les conséquences potentielles sont facilement imaginables. Voici quelques pratiques recommandées.

[Vous avez aimé cet article ? Abonnez-vous et recevez chaque semaine dans votre boîte de réception les derniers contenus Radware, ainsi qu’un accès exclusif aux contenus Radware Premium.]

4^e piège – « Je pensais pouvoir gérer moi-même toutes les exceptions »

Les WAF avaient autrefois mauvaise réputation, et ceci pour une bonne raison. Trop de règles légitimes étaient entravées par des règles et des configurations qui ne correspondaient pas aux besoins des entreprises. Les coûts pouvaient alors être considérables, une mauvaise expérience utilisateur entraînant une attitude négative à l’égard de la marque et une baisse des taux de conversion. Le coût total de gestion d’un WAF en interne peut être très élevé en raison de la main d’œuvre supplémentaire requise. Il s’agit d’une tâche de spécialistes, surtout si l’on considère toutes les menaces de sécurité mentionnées précédemment. Un œil peu averti se perd dans la multitude d’alertes provenant des différentes solutions ponctuelles. Une stratégie de sécurité des applications unifiée, gérée par des experts, assortie d’une automatisation avancée et d’analyses pertinentes, réduit considérablement le coût total de possession tout en apportant rapidement un bon niveau de sécurité.

[Sur le même thème : Comment assurer la protection des applications derrière AWS/Azure CDN].

5^e piège – « Je pensais que le DevOps serait à l’écoute »

Certaines attaques profitent d’une posture de sécurité faible et disparate, due à des processus défaillants et à des conflits internes. La dynamique actuelle en matière de développement et de sécurité des applications est telle que les solutions de sécurité, et surtout le personnel, ne peuvent pas suivre. Du point de vue du développeur, il existe tant de ressources permettant de concevoir le pipeline CI/CD idéal, et notamment des outils de configuration, de test et d’orchestration automatisés. L’agilité consiste à aller de l’avant, à passer à la prochaine version, au prochain correctif, à la prochaine correction de bug – et non à ralentir pour inspecter chaque transaction et chaque module. Comme la productivité prime toujours, la sécurité doit suivre. Il s’agit toutefois d’un équilibre fragile que chaque entreprise gère différemment. Le DevOps ayant de plus en plus d’influence sur les décisions liées à la sécurité, le personnel chargé de la sécurité de l’information doit prendre en compte le fait qu’une solution de sécurité des applications ne se limite pas à bloquer les attaques. Une telle solution doit s’intégrer parfaitement à l’écosystème SDLC et être adaptative. Il est également nécessaire d’affiner la politique chaque fois qu’une modification est apportée à l’application. Une solution de sécurité doit offrir à l’équipe DevOps une bonne visibilité sur les indicateurs de performance et l’automatisation dans les différents environnements. Ainsi, le processus satisfait tout le monde.

En évitant ces pièges, vous disposerez d’une stratégie de sécurité applicative qui présente les caractéristiques suivantes :

• Cohérence

• Transparence

• Adaptation

• Efficacité

Téléchargez le Hacker’s Almanac 2021 de Radware.