Un nombre ahurissant d’applications sont hébergées dans le cloud sans la moindre protection. Aucun pare-feu pour applications web. Aucun contrôle des identités ni des accès. Rien. Elles sont simplement là, exposées aux attaques.
C’est un cauchemar pour les entreprises, et un rêve devenu réalité pour les cyberattaquants.
C’est également peu judicieux compte tenu de l’intérêt croissant que suscitent les applications en tant que cibles. Qu’il s’agisse d’accéder à de précieuses sources de données ou d’utiliser l’application comme point de diffusion à d’autres fins malveillantes, les attaques visant les applications sont en hausse.
En fait, si l’on examine les principales violations de données, on constate que 30 % d’entre elles impliquaient des attaques contre des applications web. Dans 62 % des cas, des pirates ont exploité une vulnérabilité. Et pas moins de 77 % ont été perpétrées par des botnets, et non par des individus.
Cela signifie que vous devez protéger vos applications contre les bots et les vulnérabilités afin de ne pas devenir une statistique de plus.
Et quand je parle de vos applications, je veux dire toutes vos applications. En matière de sécurité, toutes les applications sont critiques – même dans le cloud. Peut-être plus encore 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 devrions pas) ignorer que la complexité, notamment celle des solutions de sécurité, peut parfois entraver la protection des applications dans le cloud. Un peu plus d’un tiers (34 %) des personnes interrogées dans le cadre de notre enquête State of Application Delivery 2018 nous ont indiqué que « l’accroissement de la complexité des solutions de sécurité » constituait l’un des principaux défis en matière de sécurité pour l’année à venir.
La sécurité peut être complexe. Mais elle ne doit pas nécessairement l’être, surtout dans le cloud.
Sécurité des applications web dans le cloud
Pour ceux qui ne le savent pas, AWS propose une plateforme plutôt intéressante qui vous permet non seulement de déployer vos applications, mais aussi à des fournisseurs d’y ajouter des fonctionnalités. Dans le domaine de la sécurité, son pare-feu pour applications web natif permet d’ajouter des règles gérées par des tiers afin d’en étendre les fonctionnalités. Vous pouvez ainsi vous protéger contre les menaces à l’origine des principales violations de données sans avoir à maîtriser tous les tenants et aboutissants d’un pare-feu pour applications web. Si vous débutez, AWS WAF Managed Rules constitue un bon point de départ pour vous familiariser avec la sécurité des applications web et vous prémunir contre les menaces les plus courantes qui pèsent aujourd’hui sur les applications — et les entreprises.
Les règles gérées AWS WAF sont exactement cela : des règles de sécurité pour applications web qui étendent les fonctionnalités d’AWS WAF et protègent 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 la certitude qu’elles sont toujours à jour et qu’elles vous protègent contre les menaces les plus récentes. C’est la sécurité en tant que service, dans le cloud, pour toutes les applications.
Pour protéger vos applications contre trois des menaces les plus courantes — les bots, les vulnérabilités connues et le piratage — vous devez envisager de déployer dès maintenant trois règles différentes. Réfléchissez bien, toutefois, car vous ne pouvez choisir qu’une seule règle gérée à la fois (une, pas plus).
Top 10 de l’OWASP
Le Top 10 de l’OWASP est bien connu des développeurs, des équipes DevOps et des professionnels de la sécurité. Vous connaissez bon nombre de ces vulnérabilités : injection SQL (SQLi), XSS, injection de commandes, injection NoSQL (NoSQLi), traversée de répertoires et ressources prévisibles. Il s’agit des dix vulnérabilités les plus courantes, qui finissent par donner bien des maux de tête aux organisations — et parfois leur valent une couverture médiatique peu flatteuse — lorsqu’elles sont exploitées. Et elles le sont souvent, en particulier lorsqu’elles sont découvertes dans des applications qui communiquent avec des sources de données contenant de précieuses données sur les consommateurs ou les entreprises.
Dans l’idéal, les développeurs devraient corriger ces vulnérabilités dans le code dès qu’elles sont découvertes. Dans les faits, nous savons que cela prend des mois (quand cela finit réellement par arriver). C’est pourquoi un pare-feu d’applications web capable de traiter ces vulnérabilités courantes est si précieux : il offre une protection immédiate contre leur exploitation. Qu’il s’agisse d’une solution permanente ou d’une mesure provisoire, il est judicieux d’utiliser un ensemble de règles couvrant le Top 10 de l’OWASP.
Vulnérabilités et expositions courantes (CVE)
On ne saurait trop insister sur l’importance de se protéger contre les CVE connues.
En 2015, Kenna Security a publié les résultats d’une étudemenée sur un échantillon de 50 000 organisations, portant sur 250 millions de vulnérabilités et plus d’un milliard (UN MILLIARD) d’incidents de sécurité. Deux constats très intéressants concernant la correction des vulnérabilités en sont ressortis :
- En moyenne, les entreprises mettent entre 100 et 120 jours pour corriger les vulnérabilités.
- Au bout de 40 à 60 jours, la probabilité qu’une CVE soit exploitée dépasse 90 %.
- Le délai entre le moment où une vulnérabilité est susceptible d’être exploitée et celui où elle est corrigée est d’environ 60 jours.
En d’autres termes, la plupart des organisations risquent de voir une CVE exploitée avant même d’avoir la possibilité d’y remédier. Si vous n’avez pas suivi l’actualité, plusieurs failles de sécurité *très* médiatisées ont été attribuées à des CVE. Et pas qu’un peu : elles ont fait énormément parler d’elles. Voici quelques-unes des plateformes et bibliothèques concernées par 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 aujourd’hui la plupart des applications présentes sur Internet.
Vous devez donc absolument mettre en place des règles permettant d’appliquer des correctifs virtuels à votre application afin de la protéger contre l’exploitation des CVE dès leur divulgation. Vous devez tout de même appliquer les correctifs à la source (généralement au niveau de la plateforme ou de la bibliothèque tierce), mais entre-temps, votre application sera protégée contre toute compromission.
Ce délai de remédiation, associé à une pénurie d’expertise en sécurité, explique tout l’intérêt des règles gérées dans le cloud. Des experts les maintiennent et veillent à ce qu’elles soient à jour et capables de protéger les applications contre les tentatives d’exploitation. Il ne vous reste plus qu’à les déployer.
Protection contre les bots
De nos jours, plus de la moitié des visiteurs des applications sont des bots. Et pas de gentils robots d’indexation qui parcourent votre site pour le référencer et le rendre accessible via les moteurs de recherche. Nous parlons ici de bots malveillants, dignes des Decepticons, qui recherchent des vulnérabilités, inondent vos communautés de SPAM, extraient les données de votre site ou participent à des attaques DDoS orchestrées par un botnet.
Se défendre contre les bots n’est pas chose facile. Les CAPTCHA testent sans cesse de nouvelles méthodes pour identifier et bloquer les bots, mais, comme le virus de la grippe saisonnière, ces nuisibles continuent de s’adapter et de contourner les défenses.
Néanmoins, les bots malveillants adoptent des comportements qui peuvent être détectés et permettre de les identifier comme indésirables. Les règles de protection contre les bots peuvent surveiller les comportements et les activités révélant des intentions malveillantes, puis empêcher ces bots d’interagir avec votre application. Au cours des deux derniers trimestres, nous avons constaté une hausse du pourcentage d’organisations qui utilisent des services de protection contre les bots, et compte tenu de la situation actuelle, nous nous attendons à ce que cette tendance se poursuive.
Le déploiement d’une règle de protection contre les bots pour les applications dans le cloud peut offrir une couverture qui empêche l’exploitation des CVE avant même qu’elle ne se produise.
Pare-feu d’application web ou règles gérées
Il est important de noter que certaines applications devront être protégées contre ces trois menaces. D’autres auront besoin d’une protection allant au-delà des bots, des CVE et du Top 10 de l’OWASP. Certaines nécessiteront un nettoyage des données et une prévention des fuites, ainsi que des défenses plus spécifiques à l’application. La validation des schémas en est un bon exemple, notamment lors de l’acceptation de données provenant de sources inconnues. Les attaques DDoS de couche 7 (couche applicative) en sont un autre. L’application stricte des protocoles est également essentielle pour se protéger contre les vulnérabilités liées à TCP ou HTTP. Si vous avez besoin de plus d’une (1) règle ou de protections supplémentaires, envisagez une solution WAF avancée complète. À mesure que votre application gagne en fonctionnalités et en utilisateurs, veillez également à renforcer les protections dont elle bénéficie.
Quoi qu’il en soit, les règles gérées constituent un excellent point de départ pour protéger les applications dans le cloud. Elles offrent 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 de F5 peut vous aider à protéger vos données, à respecter les exigences réglementaires et à assurer une protection continue de vos charges de travail dans le cloud.
Participez au webinaire pour découvrir :
- Principaux critères liés aux applications et à l’architecture pour choisir le WAF adapté
- Comment les solutions WAF de F5 contribuent à protéger vos données contre les menaces connues et inconnues
- Comment exploiter les capacités d’apprentissage automatisé pour protéger vos données contre les attaques les plus sophistiquées
Date et heure du webinaire :
Mercredi 25 avril 2018 | 10 h 00 (heure du Pacifique)
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.