10 ans de sécurité applicative Rétrospective et Perspectives
Transcription
10 ans de sécurité applicative Rétrospective et Perspectives
10 ans de sécurité applicative Rétrospective et Perspectives LIVRE BLANC Octobre 2011 1 Sommaire Introduction _____________ 1 Quand l’IT s’ouvre à l’Internet 2 Les pionniers de l’eBusiness Conformité PCI DSS Frontaux Web d’applications d’entreprises Mobilité et Internet L’ère des Web Services Prise en compte des risques Connaître son ennemi 2 3 4 4 4 5 5 Une lutte sans répit 7 e L’aube du XXI siècle 7 Les firewalls réseau Les scanners de vulnérabilité 7 8 Code Red : le choc 8 Les IDS Filtrage applicatif 8 9 L’ère du eBusiness 10 Modèle négatif Accélération et haute-disponibilité 10 11 Première sommation : injections et 0-days 11 Honeypots Evolution des WAFs 11 12 Retour aux sources : évasion, botnets et APT 13 Anti-Evasion Protection contre un client compromis Scanners intrusifs 13 14 15 La sécurité applicative passe par l’innovation 16 La sécurité applicative dans une politique globale 16 Enterprise Security Intelligence (ESI) Une sécurité individuelle 16 17 De nouveaux standards de sécurité 17 Comprendre pour apprendre Comprendre pour détecter 17 18 Automatisation et précision 19 Automatisation des configurations Détection des failles 19 20 CONCLUSION______ A PROPOS DE DENY ALL _________ ___ _________________ _________ ______________ ____ _ __21 23 Introduction Introduction Depuis 10 ans, les systèmes informatiques des entreprises et des gouvernements ont beaucoup évolué. Cette évolution se caractérise par l’adoption massive des technologies Internet, l’interopérabilité entre systèmes hétérogènes, le partage d’informations dans un contexte de connectivité quasi-permanente, avec l’avènement des smart phones et autres tablettes, et la virtualisation des ressources avec le phénomène du cloud computing. Les applications Web et les applications d’entreprise, s’appuyant désormais sur les mêmes protocoles relativement simples de l’Internet, sont devenues depuis 10 ans les cibles principales des malveillants en tout genre. Car la menace aussi a évolué. Tant sur le plan technique, avec la primauté des attaques applicatives (injections, etc.) et la mise à disposition d’outils très automatisés ; que sur le plan des motivations, avec l’émergence d’une économie souterraine du crime informatique. Cette industrie nouvelle, basée sur l’exploitation des vulnérabilités des infrastructures informatiques, a tôt fait de se focaliser sur les failles qui touchent la couche applicative, car ce sont les plus faciles à exploiter. Redoublant d’ingéniosité pour tenter de garder un temps d’avance sur les criminels, des professionnels de la sécurité innovent pour assurer la sécurité de vos sites Web statiques et transactionnels, des frontaux Web de vos applications critiques et de vos outils de collaboration « Web 2.0 ». C’est le cas des équipes de Deny All depuis plus de 10 ans. Ce livre blanc retrace les principales étapes de l’évolution parallèle des besoins des entreprises, des menaces qui pèsent sur la sécurité de leurs applications et des outils à leur disposition pour contrôler les risques. Cette rétrospective achevée, ce sont les grandes lignes de l’évolution nécessaire des outils dédiés à la sécurité de vos applications, qui seront présentés. 1 Quand l’IT s’ouvre à l’Internet De nos jours, la très grande majorité des entreprises privées et des organismes publics ont une présence sur le Web. Celleci a évolué depuis 10 ans, passant d’une présence institutionnelle assez statique à une approche plus interactive, permettant aux visiteurs de consulter des données dynamiques, de passer commande ou encore de payer en ligne. Les pionniers de l’eBusiness De plus en plus de banques réalisent une part croissante de leur chiffre d’affaires via le Web. Le marché a même vu naître des établissements aux activités 100% dématérialisées, tout leur business se faisant dans le monde virtuel. Même constat pour le commerce en ligne, qui prend de plus en plus de poids dans l’économie. Evoluer sur Internet présente de nombreux avantages : coûts moindres en termes d’infrastructure et de ressources humaines, adaptation très rapide aux tendances et exigences des clients. Le modèle du e-Business aurait tout pour séduire, si l’ombre de la cybercriminalité ne rodait pas. En outre, grandes entreprises et PME, services de l’Etat et collectivités locales ont ouvert leur système informatique sur l’extérieur, rendant certains de leurs systèmes internes accessibles via l’Internet pour échanger des données avec leurs fournisseurs, partenaires et clients. Ce faisant, ces structures s’adaptent aux besoins modernes de mobilité car les employés veulent pouvoir consulter leurs emails depuis leur smart phone et accéder aux données de l’entreprise à tout moment, y compris en déplacement. Cependant, ouvrir ses applications à un public plus large que le cercle de ses collaborateurs pose un problème évident de confidentialité des données. En effet, sites d’e-Banking et d’e-Commerce furent parmi les premières cibles des cybercriminels. Les principaux risques qu’ils encourent sont les suivants : Vandalisme : les premières attaques de sites Web consistaient à substituer tout ou partie d’une page web par un contenu détourné. Manifestant initialement la virtuosité des hackers, ces attaques sont encore utilisées par certains « hacktivistes » pour exprimer leurs opinions politiques. Les entreprises entendent aussi exploiter le potentiel énorme du commerce en ligne, devenu un canal de vente à part entière : il a totalisé en France un CA de 31 milliards d’euros en 2010 contre un peu plus de 7 millions en 2001 (Source : Fédération du eCommerce et de la vente à distance). Enfin, elles misent sur la nécessaire interopérabilité entre leur système d’information et celui des membres de leur écosystème. Déni de service : ces attaques visent à bloquer l’accès aux serveurs et peuvent aller jusqu’à rendre indisponible un site Web et donc impacter l’activité de la société dont tout ou partie du chiffre d’affaires dépend de la disponibilité et de la performance de son site Internet. 2 Vol de données : en pénétrant dans données, serveurs applicatifs, d’authentifications, etc.). une application, un pirate peut récupérer des informations sensibles, telles que des données personnelles d’identification ou des numéros de cartes bancaires. Les conséquences les plus préjudiciables sont donc à prévoir pour l’activité de la société, pour son image mais, évidemment, aussi pour ses clients. serveurs A partir d’un poste client, un hacker peut manipuler n’importe quelle partie des requêtes HTTP(S), que ce soit les en-têtes, les urls, les paramètres passés en « query string » (dans l’url) ou dans le corps des requêtes. Conformité PCI DSS L’interactivité croissante des applications offre aux hackers de multiples possibilités de manipulations. Initialement, les sites fournissaient aux utilisateurs des pages statiques. Les fournisseurs de serveurs Web ont ensuite défini le standard CGI (Common Gateway Interface) pour rendre les applications transactionnelles et dynamiques. Dans le cadre du système bancaire international, le standard PCI DSS (Payment Card Industry Data Security Standard), a été créé afin de renforcer les bonnes pratiques en matière de sécurité des données de comptes de paiement : protéger les informations confidentielles des titulaires de carte, réduire la fraude et identifier les problèmes de sécurité susceptibles d'être exploités par des utilisateurs malveillants. Ainsi, toutes les sociétés dont les activités consistent à traiter, stocker et transmettre des données de transactions et des cartes bancaires (commerçants, banques, opérateurs ou points de vente par exemple) doivent se conformer à la norme PCI DSS afin de conserver leur statut de membre et être habilité à accepter les cartes bancaires. Le CGI permet de transmettre des données entrées par les internautes à des programmes externes afin de personnaliser les pages Web retournées aux internautes par l’application. Même si le CGI est progressivement remplacé par des langages de scripts (php, asp, cold fusion, etc.), des frameworks de développement applicatif (J2EE, ASP.NET) ou des services Web, le principe d’interaction entre utilisateurs et applications reste le même : interroger des utilisateurs via des formulaires, pop-up, listes de choix, etc., traiter les données fournies par les utilisateurs ou par des programmes tiers, La conformité au standard PCI DSS est donc obligatoire pour les sites Internet des sociétés dont les activités impliquent l’existence de données de transactions bancaires, des données sensibles s’il en est. Elle implique la mise en place d’un certain nombre d’audits et de contrôles, dont les Web Application Firewalls font partie. puis construire et renvoyer les pages Web dynamiques résultantes. En devenant transactionnel, le Web offre aux hackers des possibilités de manipuler les données soumises aux applications. Les données saisies par les utilisateurs sont transmises à tous les éléments de la chaîne applicative. Les requêtes Web dynamiques permettent ainsi aux criminels d’exploiter les vulnérabilités des serveurs Web mais également de tous les composants qui y sont rattachés (bases de 3 Frontaux Web d’entreprises premier temps, puis des mêmes frontaux Web dont nous venons de parler. Désormais, l’information est littéralement à la portée de nos doigts. Bien entendu, le risque sur la pérennité des données s’en trouve décuplé : il est tellement facile d’oublier un téléphone portable dans un avion ou sur la banquette d’un taxi. Sans compter que ces outils, dont la puissance de traitement est désormais comparable à celle des PC, hébergent de nombreuses applications qui échappent au contrôle des équipes IT. d’applications Pendant que les sites Web évoluent vers un modèle plus dynamique, la fin des années 90 voit aussi un grand nombre d’applications d’entreprise s’ouvrir pour faciliter l’accès à l’information aux utilisateurs en situation de mobilité et de télétravail. Les technologies de l’Internet permettent en effet aux organisations de mettre en place à moindre coût des accès distants sécurisés à leur système d’information. C’est l’époque où l’on parle d’Intranet pour les utilisateurs internes et d’Extranet pour les personnes qui, n’appartenant pas à l’entreprise mais étant membres de son écosystème, sont habilitées par elle à échanger avec cette dernière des données électroniques. Les applications client-serveur des années 90 s’ouvrent rapidement aux frontaux Web, qui permettent à un simple navigateur d’accéder à la même application, du côté serveur, tout en faisant l’économie du déploiement et de la maintenance d’un client dit « lourd ». Cette évolution s’opère rapidement, sous la pression combinée des utilisateurs mobiles, qui veulent accéder aux systèmes depuis leurs PC portables, mais aussi des besoins d’interopérabilité avec partenaires, fournisseurs et clients. L’ère des Web Services L’interopérabilité entre systèmes d’information est l’un des « graals » poursuivis de longue date par les entreprises dont la performance dépend de leur capacité à automatiser le flux de données avec leurs partenaires industriels, financiers et commerciaux. Celles-ci cherchent en permanence à optimiser leurs coûts et à renouveler leur avantage concurrentiel, en proposant à leur clientèle de nouveaux produits et services s’appuyant sur l’échange en quasi temps réel d’informations, nouvelle « denrée » primaire de l’économie du 21e siècle. Les échanges entre systèmes d’informations partenaires et membres d’un écosystème a longtemps été compliqué par le caractère hétérogène des composants utilisés par les différents acteurs. L’avènement des Web Services, au début du 21e siècle, a grandement simplifié la mise en œuvre d’applications automatisant ces échanges. Distribuées parfois à l’échelle même de l’Internet, elles s’appuient sur de nouveaux standards, tels que XML et SOAP, pour assurer la communication entre composants disparates, mis en œuvre par l’un ou l’autre membre dudit écosystème. Ces architectures orientées services (SOA), tendent à être complexes, ce qui génère des défis supplémentaires en terme de sécurité. Mobilité et Internet En quelques années, l’avènement du smart phone révolutionne les usages en matière de mobilité, tant dans le cadre du travail que dans celui de la vie privée. Désormais connectés en permanence à l’Internet, les utilisateurs ont pris l’habitude de disposer d’un accès immédiat et facile à l’information, quelle que soit son origine. Il en va de même des données de l’entreprise. Les équipes informatiques ont dû s’adapter pour les rendre accessibles aux utilisateurs de smart phones, par l’intermédiaire de la messagerie dans un 4 L’implication de plusieurs équipes différentes en interne, en soustraitance, ou en intégration de logiciels tiers, représente un facteur de complexité additionnel. Le recours croissant au développement off-shore augmente la difficulté à contrôler la qualité du code. Prise en compte des risques Si Internet a révolutionné l’informatique, et permis notamment de simplifier l’accès aux applications d’entreprise, ou encore de faciliter l’émergence du travail collaboratif et de nouvelles applications « Web 2.0 », le revers de la médaille est connu de tous : une exposition accrue aux risques de vandalisme, d’intrusion, de vol et d’espionnage. Depuis 10 ans, nous avons assisté en effet à un renversement de tendance : désormais, vulnérabilités et attaques concernent en majorité les couches applicatives, et non plus les couches réseau ou les systèmes d’exploitation. Malgré cette prise de conscience et les attaques récentes qui illustrent la gravité des conséquences, beaucoup d’organisations n’ont pas encore pris la mesure du défi. A cela, plusieurs raisons : Ces obstacles sont levés progressivement par les entreprises qui, conscientes des risques, investissent dans des programmes de formation de leurs équipes de développement, implémentent des procédures et des outils de test du code de leurs applications, et déploient des Web Application Firewalls, ou WAF, pour protéger leurs applications et contrôler la bonne exécution de leur politique de sécurité applicative. Elles font bien d’ailleurs, car les attaquants, quant à eux, ne désarment pas. Les objectifs fixés aux équipes de développement des applications ont souvent consisté à délivrer le plus rapidement possible les fonctionnalités avec les performances désirées, sans qu’aucune attention particulière ne soit portée à la sécurité. Connaître son ennemi Si les premiers pirates informatiques semblaient motivés surtout par le défi technique et l’aspect « ludique » du piratage, ce n’est plus le cas que pour une minorité. Les menaces modernes sont complexes, industrialisées et ciblées. Les cyber-criminels se professionnalisent. Ils cherchent avant tout à s’enrichir, même si certains se cachent derrière des motivations politiques. Ils adoptent des stratégies de plus en plus ciblées. Une véritable économie souterraine s’est développée, avec des acteurs aux rôles différents : Les applications Web sont complexes. Par conséquent, les possibilités d’erreurs lors du développement ou des tests sont multiples, y compris dans le cadre d’un développement spécifiant des normes strictes de sécurité. En effet, les applications intègrent plusieurs composants logiciels – serveurs Web, module de contrôle d’accès, couche de présentation, logiciel métier, interface au back office et aux bases de données – certains utilisant des technologies tierces (serveurs IIS, Apache, etc.), d’autres ayant été développés spécifiquement pour l’entreprise. Ceux qui développent les outils de création de malware (exploit kits), Ceux qui les utilisent pour prendre au piège des utilisateurs et ajouter ainsi leurs ordinateurs à leurs réseaux de PC esclaves (botnets), Ceux qui louent les postes de commandement de ces réseaux aux attaquants, 5 Ceux qui leur louent aussi éventuellement des données volées (identités, cartes bancaires), Et ceux qui attaquent, bien entendu. Tous s’ingénient à déjouer les défenses mises en place par les entreprises pour protéger leurs « actifs informationnels ». Ils ont toujours l’avantage de l’initiative, mais pas le monopole de la créativité, comme précisé dans la partie suivante. 6 Une lutte sans répit Les firewalls stateful sont des composants réseau effectuant une analyse du trafic à partir des informations des couches réseau (couche 3 du modèle OSI / IP) et transport (couche 4 / TCP et UDP), et à même de comprendre, de suivre et de filtrer les connexions. Les performances atteintes par les équipements implémentant cette technologie ainsi que leur capacité à gérer tout type de flux ont largement contribué à la conquête du marché et à l’élimination des firewalls mandataires. Le fer de lance de cette conquête était Firewall-1 de Checkpoint, dont le succès à l’époque explique encore aujourd’hui une part de marché considérable. Alors que les infrastructures informatiques évoluaient, il en a été de même des solutions dédiées à leur sécurisation. Elles ont évolué selon différents axes afin, d’une part, de répondre aux menaces croissantes qui pèsent sur les applications Web et, d’autre part, de s’intégrer dans une démarche rationnelle, cohérente et globale de sécurité du système d’information. L’aube du XXIe siècle Les firewalls réseau Les premiers éléments de sécurité mis en œuvre dans les infrastructures informatiques ont été des composants de sécurité périmétriques, commun à l’ensemble des flux entrants et sortants des réseaux de l’entreprise : les « pare-feux » réseau (ou firewall, en anglais). Successeurs des mécanismes de filtrages élémentaires fournis par les routeurs, les firewalls réseaux ont représenté la première ligne de sécurité réellement mise en œuvre dans les architectures réseau. Ces firewalls implémentaient une technologie consistant à apparaître comme le service cible et à effectuer un filtrage basé sur des paramètres réseaux ainsi que des critères de conformité protocolaire. Ce dernier point apparaissait alors comme le niveau de sécurité maximal pouvant être obtenu. Il garantissait non seulement que les flux étaient bien autorisés par la politique de sécurité mais également que ces derniers étaient bien de la nature attendue et conformes à la norme. Cependant, cette technologie présentait deux défauts majeurs : la dégradation des performances, liée à une analyse au niveau des couches applicatives, et la nécessité de développer un agent spécifique par application susceptible d’être protégée. Le rôle des firewalls réseau est simple : autoriser uniquement certains flux en fonction de leur source et/ou de leur destination. Ainsi, il est possible de restreindre l’accès à un serveur en n’autorisant que les flux web depuis Internet, ce qui, par exemple, interdit de facto l’accès aux services d’administration du serveur en question. Bien que les firewalls mandataires aient disparu en tant qu’éléments de sécurité périmétrique, ils peuvent être considérés comme les ancêtres des firewalls applicatifs. Le firewall Open Source TIS, Gauntlet de McAfee ou Raptor de Symantec ont été les représentants malheureux de cette catégorie. Ces produits ont depuis été abandonnés. Ces firewalls peuvent être classés dans deux catégories distinctes : les firewalls stateful et les firewalls mandataires. 7 Les scanners de vulnérabilité Code Red : le choc Si les premiers outils permettant de tester automatiquement la sécurité des serveurs datent du milieu des années 90, ils restaient l’apanage d’une minorité d’utilisateurs avertis et gardaient une image sulfureuse. Ainsi, l’ancêtre de ces outils était nommé SATAN (officiellement acronyme de Security Administrator Tool for Analyzing Networks), écrit en 1995 et dont le développement a été poursuivi en 1998 dans le cadre de l’outil SAINT (officiellement System Administrator’s Integrated Network Tool). Deux phénomènes majeurs ont ébranlé le monde de la sécurité au début des années 2000. Le premier est le vers Code Red, qui exploitait une vulnérabilité sur les serveurs Web IIS de Microsoft et qui s’est propagé à plusieurs centaines de milliers de serveurs en l’espace de quelques jours. Le second est l’apparition d’un phénomène particulier : le mass-hacking, c’est-à-dire l’attaque simultanée de dizaines de sites Web via l’exploitation de failles applicatives sur des serveurs mutualisés. Ces deux phénomènes ont clairement démontré que les éléments de sécurité périmétriques mis en œuvre dans les infrastructures n’étaient plus suffisants et qu’il était nécessaire de faire évoluer la sécurité des applications Web. Ces outils se sont toutefois démocratisés en évoluant selon deux axes majeurs : L’amélioration de leur interface et du reporting, La couverture d’un spectre système et applicatif plus large, les « ancêtres » étant essentiellement orientés vers le test de systèmes Unix. Les IDS Le premier défaut dans la sécurité des infrastructures qui ont été compromises est l’absence de visibilité. En effet, dans bien des cas aucune information n’était relevée quant à l’attaque qui avait été lancée. Les conséquences d’un tel manque ont été doubles. D’une part, un système pouvait être compromis et le rester et servir de relais à un attaquant pendant une durée considérable, et d’autre part, quand bien même l’intrusion aurait été identifiée, l’absence d’information concernant la vulnérabilité exploitée ne permettait pas de corriger la faille. Les fers de lance de cette ouverture à un public plus large sont l’outil Open Source Nessus, écrit par Renaud Deraison, et ISS (Internet Security Scanner), commercialisé par la société éponyme, achetée depuis par IBM. Bien qu’essentiellement axés sur des tests de vulnérabilité système et réseau, ces scanners intégraient déjà quelques tests applicatifs élémentaires. Ces tests ont été les premiers éléments de sensibilisation des responsables de la sécurité aux vulnérabilités applicatives. Les IDS (Intrusion Detection Systems) sont la réponse à cette problématique. Positionnés en écoute sur le réseau (NIDS – Network IDS) ou directement sur les serveurs (HIDS – Host IDS), ces contrôles de sécurité analysent le trafic et tentent d’identifier toute anomalie dans le contenu des paquets à destination de la ou des ressources surveillées. Toutefois, les problématiques de filtrage et de sécurité élémentaire au niveau des serveurs étaient telles à l’époque que la majorité des alertes remontées par les tests applicatifs sont restées lettres mortes car considérées (et souvent à juste titre) comme de sévérité plus faible. 8 Leur objectif est double : détecter toute tentative d’intrusion et identifier de manière passive les faiblesses de sécurité potentielles de l’infrastructure. Ainsi, l’utilisation de protocoles de communication non chiffrés pour l’administration des serveurs générera une alerte au même titre que l’identification d’une requête Web contenant une injection SQL. exemple, pour une page article.php d’un site Web, il était possible d’imposer que le paramètre id soit uniquement une série de 4 chiffres. L’URL « http://www.site.com/article.php?id=12 34 » est alors valide quand l’URL « http://www.site.com/article.php?id=1’ OR 1=1 # » est rejetée. Idéalement, ces filtres devaient être intégrés à l’application lors de sa conception. En effet, de tels filtres sont pertinents s’ils sont cohérents avec les paramètres de l’application. Ces paramètres étant connus des développeurs, ces derniers devraient avoir la responsabilité de leur mise en place directement dans le code de l’application. Cependant, l’absence de prise en compte de la sécurité dès les spécifications de l’application ainsi que le manque de sensibilisation des développeurs aux problématiques associées ont toujours été un frein à la mise en place de filtres au niveau de l’application. Techniquement, les premiers IDS se basaient sur une liste de signatures, c’està-dire de chaînes de caractères (ou plus exactement d’octets) caractéristiques de différentes attaques potentielles ou de probables violations des règles de l’art de la sécurité. L’exhaustivité (toujours relative) et la précision de ces règles étaient les principaux critères de qualité d’un IDS. Très rapidement démocratisés par l’IDS Open Source Snort, écrit par Martin Roesch, et par l’outil commercial DragonIDS de Ron Gula ; transparents en termes de déploiement et sans impact sur les performances des serveurs, les NIDS ont toujours été les seuls IDS réellement mis en production. Il s’est donc avéré nécessaire de déployer les filtres applicatifs en amont de l’application elle-même, que ce soit au niveau du serveur Web, avant que ce dernier ne serve la requête à l’application, ou sur un équipement tiers positionné « avant » le serveur Web dans la chaine applicative. Cependant, les administrateurs ont rapidement été débordés, non seulement par la quantité d’informations remontées par ces équipements, mais également – et surtout – par la très importante proportion de fausses alertes (faux-positifs). Ainsi, le travail d’investigation est devenu indissociable de l’analyse des données remontées par les IDS, induisant des délais de réaction souvent trop longs à l’échelle d’une intrusion. Dans le premier cas, les différents serveurs Web du marché ont proposé des solutions, telles que les filtres ISAPI sur IIS. Cependant, le déploiement et la maintenance de filtres sur chaque serveur se sont avéré des opérations particulièrement lourdes. Ce type de solution a, par conséquent, été abandonné au profit des reverse-proxy. Filtrage applicatif Une solution complémentaire de celle fournie par les IDS consiste à mettre en place des filtres analysant les données soumises aux applications. Ces filtres se basaient sur un modèle des données autorisées, toute donnée ne correspondant pas à ce modèle étant rejetée. Par Les reverse-proxy sont des équipements tiers identifiés par le client Web comme la ressource cible. La requête leur est donc adressée et ils la transmettent à la ressource réelle, c’est-à-dire le serveur 9 hébergeant l’application Web. Les fonctions de filtrage ont été greffées sur ce mode opératoire, les requêtes ne répondant pas au format défini dans les filtres n’étant simplement pas transmises au serveur. Client Firewall Réseau ReverseProxy Filtrant L’ère du eBusiness Le modèle du eBusiness ayant été validé par les pionniers, tels qu’Amazon et eBay, les applications de commerce en ligne se multiplient et s’enrichissent considérablement de fonctions visant à attirer et à fidéliser la clientèle. Modèle négatif Serveur Web Les applications deviennent de plus en plus complexes. Parallèlement, la liste des pages et paramètres devant être autorisés par les filtres s’accroit de manière considérable, au point que le paramétrage manuel des filtres n’est plus une opération concevable. Il devient alors nécessaire de mettre en place des mécanismes d’apprentissage souvent lourds et toujours imparfaits. En outre, aucune protection n’est apportée à l’application lors de la phase d’apprentissage, laquelle doit être renouvelée à chaque modification de l’application. Figure 1: Chaine applicative avec filtrage sur un équipement tiers Le déploiement de filtres sur un reverseproxy présente deux avantages. Le premier est la capacité de mutualiser l’ensemble des opérations de filtrage sur un unique équipement. Ce dernier reçoit l’ensemble des requêtes à destination des différentes applications de l’infrastructure et les redirige vers les serveurs appropriés à l’issue du filtrage. Dans ce cadre, l’exploitation de la sécurité applicative est réalisée à partir d’un point unique. Ces limitations des filtres applicatifs tels qu’ils ont été initialement conçus ont imposé la définition et la mise en œuvre d’un nouveau modèle de sécurité : le modèle négatif. Inspiré du modèle de sécurité mis en œuvre dans les IDS, ce modèle consiste à définir une liste la plus exhaustive possible des modèles de données caractéristiques d’attaques. IDS et systèmes de filtrages applicatifs évoluent donc avec pour objectif de fournir une solution de sécurité active. Le second avantage du déploiement d’un reverse-proxy est la distribution et le masquage de l’architecture applicative. En effet, les serveurs Web étaient jusqu’alors directement accessibles depuis Internet. Un intrus était donc à même d’identifier les différents serveurs et de construire une cartographie réseau, système et applicative de l’infrastructure. La mise en place d’un reverse-proxy a rendu possible le déport de ces serveurs vers d’autres zones de l’infrastructure et par conséquent le masquage des composants réels de la chaine applicative, localisés en dehors de la DMZ publiquement accessible. Ainsi les IDS deviennent IPS (Intrusion Prevention Systems), déployés en ligne, et capables de bloquer une transaction réseau lorsque cette dernière contient une donnée correspondant à une signature d’attaque. Les acteurs historiques du monde de la sécurité évoluent rapidement dans ce sens, alors que de nouveaux éditeurs spécialisés, tels que Tippingpoint, racheté depuis par HP, font leur apparition. rWeb et sProxy, les reverse-proxy filtrants de Deny All, restent les précurseurs en la matière et apparaissent déjà à l’époque comme des références en termes de sécurité. 10 Efficaces pour des attaques au niveau réseau, les IPS restent très limités dans leur capacité d’analyse des menaces applicatives. En effet, l’absence de maîtrise du contexte applicatif limite notablement leur compréhension des transactions et les cantonne dans un spectre de détection sommaire. En revanche, l’implémentation d’un modèle de sécurité négatif dans les systèmes de filtrage applicatif offre une alternative cohérente et popularise rapidement ces solutions, nouvellement baptisées Web Application Firewall. accélération et performances deviennent alors des critères de poids égal dans la sélection des solutions de « sécurité » applicative. Première sommation : injections et 0-days C’est dans ce contexte que deux menaces font leur apparition : La première est l’injection de code de toutes sortes dans les applications Web. Ces attaques prennent rapidement le devant de la scène dans la mesure où elles permettent de prendre le contrôle de différents composants de la chaîne applicative, du client (Cross-Site Scripting) à la base de données (SQL Injections), en passant par le serveur lui-même (Command Injections). La cible n’est donc plus le programme serveur lui-même (Apache, IIS, etc.), ni le système d’exploitation, mais les applications qu’ils hébergent, rarement développées avec des contraintes de sécurité suffisantes. Accélération et haute-disponibilité L’activité des entreprises dépend de plus en plus des plates-formes applicatives dont les performances et la disponibilité deviennent des critères de plus en plus importants, parfois vitaux dans le cadre d’entreprises de e-business. Le marché des Load Balancers observe alors une croissance exponentielle, dominé par trois acteurs historiques : F5 Networks, Radware et Alteon, lequel fut ensuite racheté par Nortel, puis finalement par Radware. Puis, c’est l’arrivée des attaques dites « 0day ». Basées sur des vulnérabilités découvertes et diffusées dans des milieux restreints, les 0-day ne sont pas publiées mais exploitées, ne laissant ainsi aucune opportunité aux éditeurs de corriger les failles ou de définir une signature efficace. Les besoins d’accélération sont également mis en évidence par l’impact des solutions de sécurité sur les performances des applications. En effet, le transit des informations par plusieurs niveaux de filtrage – firewalls, IPS et / ou WAF – induit une latence supplémentaire dont l’impact devient visible pour les utilisateurs des plates-formes soumises à des charges grandissantes. Des solutions de « cache » sont alors implémentées pour servir le contenu statique, la charge est répartie sur différents serveurs et les flux sont compressés afin de réduire l’utilisation de la bande passante des accès Internet. Honeypots La menace des 0-day devient un sujet de préoccupation croissant dans la mesure où peu de solutions cohérentes sont proposées. La nécessité d’identifier au plus tôt l’apparition d’une nouvelle faille ainsi que son mode d’exploitation devient impérieuse afin de permettre le déploiement de filtres dans des délais appropriés. Conscients de l’impact de leurs produits sur les performances et soucieux d’offrir une solution intégrée, les éditeurs de WAF implémentent également des solutions d’accélération et de répartition de charge dédiées au trafic Web. Sécurité, Longtemps restés dans le domaine de la recherche et sans implémentation industrielle, les « honeypots » ont alors connu un soudain regain d’intérêt. En effet, 11 ces systèmes ont pour fonction de simuler le comportement d’applications afin d’inciter un individu malicieux à lancer une attaque. Les transactions sont enregistrées et il est ainsi possible d’identifier une attaque nonréférencée. Evolution des WAFs La parade face aux 0-days et aux injections viendra donc des WAFs, qui évoluent en conséquence. Les injections sont en très grande majorité le fait d’applications spécifiques, développées pour un besoin unique. Les équipes en charge de ces développements, souvent externalisées, ne sont souvent pas au fait des contraintes de sécurité qui devraient être imposées à des applications Web, publiquement accessibles. Le principal « produit » de cette catégorie était le programme Open Source honeyd, développé par Niels Provos, enrichi et promu par la communauté du « Honeynet Project », qui a alors connu son heure de gloire avec des ramifications dans la plupart des pays industrialisés. Cette soudaine promotion a été rapidement suivie d’une vague de déploiements de ce type de solutions. La sécurisation de telles applications ne peut alors plus reposer sur des modèles génériques. Elle impose non seulement la mise en place de filtres à même de s’adapter à l’application, mais également de techniques de contrôle des différents aspects logiques dont les failles pourraient être exploitées. Si le principe était approprié et que quelques résultats se sont avérés probants, les « honeypots » ont en revanche montré de nombreux revers. Les WAF s’enrichissent ainsi de fonctions d’analyse comportementale, de contrôle protocolaire, de suivi ou de chiffrement des éléments d’états (cookies, paramètres, liens) et de validation des données envoyées au navigateur. Le premier était dû à la génération d’une très grande quantité d’informations inutiles, les systèmes d’enregistrement étant saturés par le trafic de menaces connues, voire obsolètes. Par conséquent, la quantité de ressources et les délais nécessaires à la recherche et au traitement des 0-day se sont avérés inacceptables. Cette évolution a deux conséquences : La première est un développement rapide et souvent incohérent de nouvelles fonctions de sécurité mal intégrées dans l’architecture logicielle ainsi que dans les interfaces d’administration. Il en résulte des solutions instables et parfois complexes à configurer. Le second était lié à la nature même du « honeypot ». Ce dernier n’était autre qu’un système vulnérable, volontairement mis en place dans l’infrastructure informatique. Ainsi, en cas d’erreurs dans la configuration ou de failles dans l’architecture globale de la plate-forme, il devenait trivial pour un attaquant d’utiliser le « honeypot » comme plate-forme de rebond vers le système d’information de l’entreprise. Le « piège » se retourne alors contre ceux qui l’ont mis en place et devient un véritable cheval de Troie. Ces différents inconvénients ont largement contribué à l’abandon de ces technologies. La seconde est un niveau de sécurité très variable et rarement évalué de manière appropriée. En effet, s’agissant de composants très spécifiques et applicables à des contextes applicatifs particuliers, les fonctions en question sont rarement 12 « testées » et plus rarement encore mises en production. implémenter de technique d’évasion (contournement des systèmes de sécurité). Les résultats obtenus sont par conséquent décorrélés de la réalité et ne reflètent pas la capacité d’un système de sécurité à effectivement protéger une plate-forme d’attaques réelles. Ainsi, et bien que les WAF disposent d’un arsenal complet de fonctions à même de bloquer la majorité des menaces d’injection, ces derniers restent souvent configurés de manière trop générique et n’offrent pas le niveau de protection dont ils sont capables. Dans ces conditions, les acteurs dont la sécurité n’est pas le cœur de métier ne considèrent pas comme prioritaire la nécessité de mettre à niveau leur solution, exposant ainsi les systèmes protégés à de nombreuses formes d’attaques nouvelles. Retour aux sources : évasion, botnets et APT Alors que les Web Application Firewalls se remettent à niveau afin de traiter de manière appropriée la menace croissante des injections, les techniques de contournement se multiplient. En parallèle, les codes malicieux se perfectionnent afin de travailler de manière coordonnée au sein de « botnets » sophistiqués et de pénétrer plus profondément les systèmes d’information. On parle alors d’APT (Advanced Persistent Threat), c’est-à-dire de malwares furtifs et agissant en tâche de fond sur les serveurs et stations de travail compromis. Inversement, certains spécialistes développent des solutions de plus en plus évoluées afin, non seulement, de prendre en compte de manière unitaire les différentes techniques d’évasion mais, également, de gérer de manière globale les éléments contextuels fournissant le socle technologique exploité par ces techniques. Ainsi, l’analyse des langages tels que JavaScript ou SQL permet d’identifier les tentatives de contournement basées sur la substitution des commandes ou des expressions communes recensées dans les signatures. Anti-Evasion La prévention des menaces, c’est-à-dire leur identification et leur éradication avant qu’elles n’atteignent leurs cibles, reste la méthode la plus efficace pour préserver l’intégrité des systèmes d’information. Cependant, l’évolution des techniques « d’obfuscation » (qui rendent l’attaque indétectable par les systèmes de sécurité), visant à échapper à la détection des Web Application Firewalls et des IPS rend inefficace la majorité des techniques de comparaison avec des signatures. Par exemple, une expression aussi simple que « 1=1 » est équivalent d’un point de vue logique à « char(32)=’ ’ » ou encore à « position (0x63 in ‘abcdef’) = 3 ». Lorsque la première est détectée par l’ensemble des signatures visant à protéger des attaques contre les injections SQL, aucune signature n’est à même de détecter les deux autres. Les nouvelles structures de données telles que JSON, largement exploitées dans les applications Web 2.0, participent également à la confusion. Les données soumises aux applications (et contenant potentiellement les instructions malicieuses) ne sont plus situées dans des champs bien définis mais peuvent être intégrées à un Cette problématique se trouve accrue par le fait que les techniques d’évaluation du niveau de sécurité ne prennent pas en compte ce nouveau critère. En effet, les tests ne valident que le blocage d’attaques communes (et parfois obsolètes) sans 13 ensemble complexe dont la structure n’est ni normalisée, ni définie. Aujourd’hui, deux implémentées pour méthodes d’évasion. techniques détecter de Cependant, un poste client infecté par un malware à même de « s’injecter » dans le navigateur (une menace nommée « man-inthe-browser »), devient un vecteur d’entrée et de manipulation des données de l’application. En effet, un tel programme est à même d’intercepter et de manipuler l’ensemble des données reçues et transmises par le navigateur. Toute transaction peut ainsi être compromise à l’insu de l’utilisateur et dans le cadre d’échanges de données entièrement légitimes du point de vue du Web Application Firewall. sont telles La première consiste en une analyse agnostique des données, basée sur un calcul de poids. A l’instar des premiers systèmes d’anti-spam, ces techniques (dites de scoring) analysent les différents composants d’une requête (URL, en-têtes, données, etc.) et calculent un poids global en fonction de la présence de caractères ou de chaînes atomiques. Au-delà d’un certain score, une requête est considérée comme suspecte et est rejetée. La protection vis-à-vis de ce type de menaces est rendue complexe par deux facteurs. La technique repose sur des analyseurs syntaxiques dont la fonction est de « réduire » les expressions à leur valeur canonique. Ainsi l’expression « char(32) » vue dans nos exemples précédents sera canonisée sous la forme « ‘ ‘ », et l’égalité « ‘ ‘ = ‘ ‘ », résultant de la première opération de canonisation sera elle-même réduite à l’expression booléenne « TRUE », caractéristique de certaines opérations d’injection SQL. Le premier est qu’il est parfois impossible de maîtriser la sécurité du poste client. Cela est particulièrement vrai dans le cadre d’applications Web grand public. Imposer un logiciel de sécurité, en considérant qu’il en existe un approprié et efficace, n’est pas envisageable dans un tel schéma. Le second est un obstacle technique. En effet, les malwares de type « man-in-thebrowser » utilisent des fonctions standard offertes par le système d’exploitation et largement utilisées par les programmes légitimes. Bloquer leur utilisation rend l’ensemble du poste de travail quasiment inopérant. La complexité de conception de ces techniques en fait l’apanage de quelques éditeurs spécialisés comme Deny All, dont le focus demeure, par choix, la sécurité des applications Web. La solution consiste donc à ne se focaliser que sur le client de l’application, plus précisément sur son navigateur, via un programme chargé depuis le Web Application Firewall au moment de la connexion du client au serveur. Ainsi, la sécurité est maîtrisée par le propriétaire de l’application et le blocage de fonctions spécifiques devient possible dans la mesure où le spectre d’actions reste limité à un logiciel et non plus à l’intégralité du poste de travail. Protection contre un client compromis Une autre menace pour laquelle la prise de conscience par les entreprises reste marginale est l’impact d’une attaque menée depuis un client compromis. En effet, en considérant que les flux entre le client et le serveur sont chiffrés et qu’une sécurité adéquate a été mise en place afin de protéger l’application des intrusions, il est généralement admis que la chaîne applicative est convenablement protégée. 14 Enfin, la mise en œuvre d’une telle solution de « sanitisation du poste client » à partir d’un WAF permet un mode de déploiement première barrière franchie. L’évaluation du niveau de sécurité est ainsi complète, intégrant les vulnérabilités des composants internes de l’architecture dans des scénarii d’intrusion beaucoup plus réalistes. transparent vis-à-vis de l’application dont le code ne doit pas nécessairement être modifié. Canvas et CoreImpact, édités respectivement par les sociétés Immunity et CoreSystems, sont les précurseurs et les principaux acteurs d’un marché auquel peu d’éditeurs accèdent compte tenu de la complexité technique et de l’expertise nécessaire pour la réalisation de tels outils. Scanners intrusifs Les nouvelles menaces telles que les APT (Advanced Persistent Threats) consistent à compromettre des composants internes aux systèmes d’information via des mécanismes de rebond entre les éléments de l’infrastructure. Par conséquent, les outils de tests se contentant d’évaluer uniquement la sécurité des composants publiquement accessibles ne sont pas à même de mesurer de manière fiable le niveau de sécurité du système d’information. En dix ans, le marché de la sécurité applicative a connu plusieurs phases. D’un domaine de précurseurs, il est devenu un marché reconnu dans lequel quelques « généralistes » ont mis le pied à une époque où sécuriser les applications Web restait une opération relativement simple. Mais aujourd’hui, l’évolution rapide des techniques d’intrusion et d’évasion impose le retour sur le devant de la scène de spécialistes à même de réagir rapidement et efficacement à l’apparition des nouvelles menaces. C’est pourquoi, en parallèle de l’évolution des solutions de sécurité, les outils d’audit et de tests d’intrusion ont également intégré différentes fonctions dont l’objectif est de simuler la pénétration en profondeur d’un système d’information une fois la 15 La sécurité applicative passe par l’innovation La capacité d’une attaque applicative à pénétrer jusqu’au cœur du système d’information change la dimension de la problématique. Quand seule une application Web périmétrique était exposée à des risques d’intrusion, la mise en place ponctuelle d’une solution pouvait conduire à un niveau de sécurité acceptable. Ceci dans la mesure où l’impact d’une intrusion sur le reste du système d’information restait quasiment nul. La sécurité applicative politique globale dans une Une politique de sécurité globale se construit à partir de l’évaluation des niveaux de risque acceptables pour les actifs de l’entreprise vis-à-vis des différentes menaces, généralement identifiées au travers de la matrice DICAP (Disponibilité, Intégrité, Confidentialité, Audit, Preuve). Cela implique que la menace d’une intrusion sur un élément d’une plate-forme Web soit reconsidérée dans la mesure où son impact n’est plus limité à la périphérie. Techniquement, cette intégration doit s’effectuer selon deux axes : l’ESI et l’individualisation de la politique de sécurité. Le déploiement des Web Services, véritables vecteurs de communication entre le serveur Web et les chaînes applicatives internes, ainsi que la propagation de codes d’injection puissants, ont notablement changé la situation. Idem dans les environnements « cloud ». Un compromis sur la sécurité d’une application Web, une incohérence dans la politique de sécurité globale aussi bien qu’une simple erreur de configuration, peuvent conduire à la propagation d’une intrusion sur l’ensemble des composants internes de l’infrastructure applicative. Enterprise Security Intelligence (ESI) Le premier est la centralisation de l’intégralité des événements relatifs à la plate-forme d’accès sur laquelle l’application est hébergée. En effet, avoir une visibilité globale sur les alertes remontées par les différents composants d’une telle infrastructure permet de rapidement évaluer la nature, l’impact et la sévérité d’un incident. Dans le cas d’une intrusion, une telle surveillance du réseau offre un statut précis de sa gravité et de sa Le challenge de ces prochaines années consiste donc à adresser trois points, avec une égale importance : 1. Intégrer la sécurité applicative de manière cohérente dans la politique de sécurité globale de l’entreprise ; propagation dans les composants internes du système d’information. Si de nombreuses solutions d’analyse et de corrélation de logs existent déjà, l’avenir semble appartenir à des solutions globales à même d’intégrer ces données techniques dans un contexte global propre à l’entreprise et à son activité. Ces solutions, baptisée ESI (Enterprise Security Intelligence) par Gartner, casseront les silos qui existent entre les différents 2. Accroître le niveau de sécurité afin de s’adapter aux nouvelles menaces et aux nouvelles applications ; 3. Automatiser la définition des politiques de sécurité afin de réduire les erreurs et les délais de déploiement. 16 domaines de la sécurité pour définir un domaine de sécurité global à l’entreprise. Comprendre pour apprendre Le trafic applicatif est longtemps resté proche de quelques standards tels que HTTP ou HTML. Malgré l’ajout de variantes plus ou moins normalisées ou l’utilisation détournée de certaines fonctions, le contexte global s’inscrit dans un univers fini de possibilités, et compris par les serveurs Web ou les reverse-proxy. Le Web 2.0 et les Web Services ont notablement changé la situation en consacrant l’hégémonie de langages ouverts, tels que JavaScript et le XML. Une sécurité individuelle Le second axe est la définition de politiques de sécurité applicables à l’individu, dont l’identification ne sera plus nécessairement basée sur un unique paramètre (tel que l’adresse IP), mais sur une combinaison d’éléments. Les annuaires, les serveurs de nom, les serveurs d’allocation d’adresses IP (DHCP) aussi bien que les serveurs d’authentification et d’autorisation, les autorités de certification locales et les générateurs de tickets vont être amenés à s’intégrer dans une unique infrastructure de pilotage de la politique de sécurité. En parallèle, le besoin de nouveaux types de données pour les animations, le contenu dynamique ou la vidéo ont imposé des formats qui ne sont plus compréhensibles sans interprétation. Ainsi, les technologies Flash ou Silverlight font usage de données binaires qu’un simple filtre, basé sur l’analyse de texte, ne saurait comprendre. Ces composants deviendront la moelle épinière de la sécurité du système d’information et devront faire l’objet d’une sécurité applicative robuste, au risque de voir l’ensemble de la politique de sécurité compromise. L’analyse par modèles statiques est donc une technologie en voie d’obsolescence. L’avenir appartient à des moteurs à même de comprendre le contenu et de définir pour chaque application protégée le modèle de données qui lui est propre. Ce modèle pourra alors être appliqué aux techniques de filtrage habituelles, adaptées aux langages, protocoles et types de données correspondant. De nouveaux standards de sécurité La sécurité applicative ne peut plus être considérée comme une option ou une simple fonctionnalité pour laquelle un niveau « moyen » est considéré comme acceptable. En effet, le développement des attaques avancées, permettant d’accéder très rapidement au cœur du système d’information, change la donne. Que ce soit via des marchés largement accessibles ou « à titre gratuit », comme le font des groupes tels que les Anonymous, les outils nécessaires au lancement d’attaques faisant usage de techniques d’obfuscation, de propagation automatisée et de prise de contrôle à distance de réseaux entiers sont aujourd’hui à la portée de tout le monde. Toutefois, si la forme impose une expertise pointue tant dans la connaissance de chacun de ces langages et protocoles que dans les problématiques de sécurité associées, le fond est similaire au mode opératoire appliqué pour la sécurisation des flux HTTP et HTML. En effet, il s’agit de comprendre le protocole de transport (HTTP), d’identifier les anomalies, de normaliser les composants acceptant différentes formes de représentation et d’extraire les éléments potentiellement vecteurs d’attaques. Il s’agit des éléments de structure du protocole (méthode, version, en-têtes, URI) et des données. Les 17 premiers peuvent être traités par les différents moteurs de filtrage, les seconds sont transmis à une chaîne de traitement spécifique dont le rôle est également de comprendre le langage de représentation (HTML), d’identifier les anomalies, de canoniser les éléments et de les transmettre à un moteur de filtrage. efforts de recherche et développement ayant été essentiellement fournis pour développer des fonctionnalités annexes afin d’ouvrir de nouveaux marchés aux éditeurs. Lutter contre les évasions consiste à créer des moteurs de normalisation plus puissants et dont le mode opératoire ne se limite plus à une analyse syntaxique ou à une simple transformation des données à filtrer. La conception de moteurs à même de reproduire et d’intégrer ce processus d’analyses en cascade représente l’avenir de la sécurité applicative. Les nouvelles générations des moteurs de normalisation se baseront sur la compréhension globale d’une expression via deux mécanismes complémentaires : Le schéma ci-dessous détaille ce mécanisme pour l’analyse d’un flux HTTP, transportant des données JSON dont certaines sont utilisées pour une requête vers une base de données SQL. Les données associées à chacun de ces protocoles ou langages sont extraites au fur et à mesure de l’analyse et transmises au moteur correspondant. L’analyse contextuelle des membres des expressions, c'est-à-dire leur « traduction » dans une forme canonique considérée par le moteur comme la plus simple ; Comprendre pour détecter La réduction des expressions en évaluant les différentes valeurs que ces dernières peuvent retourner. Les techniques d’évasion sont un des domaines dont l’évolution est la plus rapide et la plus impressionnante. Il s’agit de la conséquence d’un niveau de sécurité qui est resté constant au fil des années, les 18 Ainsi, si l’analyse d’une expression SQL complexe, dont les membres sont des valeurs de retour de fonctions, démontre que cette expression ne peut prendre qu’une seule valeur (telle que « TRUE » par exemple), il est évident qu’il s’agit d’une injection SQL simple. Dans le cas d’une expression pouvant prendre uniquement deux valeurs (« TRUE » et « FALSE »), il est fortement probable qu’il s’agisse d’une injection SQL « en aveugle ». Automatisation des configurations L’approche actuelle consiste à fournir des modèles par défaut, intégrant les principaux éléments de sécurisation de différents types d’application, tels qu’Outlook Web Access, SAP Netweaver, Microsoft Sharepoint, etc. L’efficacité de cette approche repose sur deux éléments : la connaissance de la nature précise de l’application à protéger et la stabilité de ces applications. Cette efficacité reste par conséquent très relative dans la mesure où, d’une part, de très nombreuses applications ne peuvent pas être couvertes, tout simplement parce que ce sont des développements spécifiques, ou parce qu’elle sont peu ou pas connues ; et, d’autre part, parce que la très grande majorité des applications habituellement couvertes offrent des capacités de personnalisation qui rendent un modèle de sécurité au mieux inefficace, au pire « dangereux », dans le sens où il bloquera le trafic légitime. L’efficacité de tels moteurs, qui sont l’avenir des systèmes de détection, est fortement liée à la capacité du système de sécurité à identifier la nature des données et à les extraire. Il est donc indispensable que les contrôles de sécurité comprennent les flux qui les traversent. Automatisation et précision L’erreur humaine reste toujours un facteur de risque important. L’origine peut en être le niveau de compétence de la personne en charge de la configuration d’un équipement, un manque d’organisation et de procédures dans des structures de grande taille, ou la complexité des politiques définies. Mais, quelle que soit la cause, de telles erreurs peuvent avoir deux conséquences : l’ouverture d’une faille dans la sécurité de l’infrastructure ou le blocage de flux légitimes. L’approche statique est donc insuffisante et les années à venir vont voir de nouveaux moteurs de sécurité basés sur l’analyse des transactions. Cette analyse permettra d’identifier exactement le type d’application et la nature des transactions. A partir de cette identification, un modèle de sécurité spécifique pourra être construit à l’aide de blocs de filtres et de fonctions répondant à un besoin de sécurité spécifique et qualifié. Limiter les erreurs humaines implique la mise en œuvre de deux types de technologies : De manière très simplifiée, nous pouvons prendre l’exemple d’une analyse démontrant qu’une application fait usage de cookies et autorise l’upload de fichiers. Une politique serait automatiquement définie, imposant le chiffrement des cookies et l’analyse des fichiers par un système anti-virus tiers. Une technologie d’automatisation de la création des politiques de sécurité ; Une technologie de détection des failles applicatives couplée à la première. 19 Détection des failles Il existe aujourd’hui deux familles de solutions automatisées permettant d’identifier les failles dans une application : une priorité. Elle peut être mise en œuvre rapidement et efficacement en couplant les systèmes de tests à des outils de contrôle de la sécurité applicative, tels qu’un WAF, dont les politiques seront adaptées afin de garantir que la faille identifiée soit effectivement bloquée. Les outils de scan de vulnérabilité, ou DAST (Dynamic Application Security Testing), Les outils d’audit de code, ou SAST (Static Application Security Testing). Ce couplage ne doit toutefois pas rester statique, et ce pour deux raisons. D’une part, la majeure partie des vulnérabilités qui sont trouvées par les scanners sont déjà protégées via des règles plus génériques implémentées sur les outils de contrôle. L’ajout d’une règle spécifique est alors non seulement inutile mais également source de complexité et d’utilisation inutile de ressources. D’autre part, l’attaque appartient nécessairement à une famille dont les variantes sont nombreuses. Ainsi, bloquer spécifiquement une attaque est loin d’être suffisant si toutes les variantes de cette même attaque ne sont pas prises en compte. Les résultats de ces tests restent aujourd’hui complètement décorrélés. Ainsi, un scan de vulnérabilité pourra relever une possibilité d’inclusion de fichier distant (remote file inclusion), quand une analyse de code révélera l’absence de validation de données en entrée d’une fonction. En revanche, aucun lien n’est fait entre la cause, identifiée par l’analyse du code, et la conséquence, révélée par le scan de vulnérabilité. L’efficacité de ces techniques qui sont complémentaires dépendra donc, dans l’avenir, de leur capacité à échanger les informations et à établir la relation de causalité entre les résultats obtenus via les différents moyens mis en œuvre. Un couplage de ces technologies réduira de manière conséquente les délais de correction de failles. En revanche, une fois ces éléments pris en compte, le couplage d’un système DAST/SAST unifié avec un WAF de nouvelle génération, capable d’automatiser de manière fiable la construction de politiques de sécurité, est une solution qui promet d’être redoutablement efficace. En parallèle, la sécurisation des applications, laissées vulnérables le temps que cette correction soit opérée, doit être 20 Conclusion Conclusion Traiter de sécurité applicative sans comprendre les dessous de la technologie est une entreprise vaine. Les attaques sont de plus en plus sophistiquées, les protocoles de communication plus complexes et une sécurité approximative, ou moyenne, vouée à l’échec. D’un autre côté, la sécurité d’entreprise ne peut plus être gérée efficacement par silos de technologies plus ou moins isolés les uns des autres. Les attaques mutent, exploitent de nombreux vecteurs pour se propager et compromettre le système d’information. Une gestion trop étroite des risques fait le lit d’un risque d’intrusion en profondeur aux conséquences catastrophiques. L’avenir de la sécurité applicative impose donc de relever un double challenge : associer une vision globale et intégrée de la sécurité à une connaissance toujours plus pointue des risques encourus. Un challenge d’autant plus difficile à relever qu’il impose la compréhension et la maîtrise de deux mondes différents, sinon opposés. C’est celui que Deny All se propose de relever dans les années qui viennent, en s’appuyant sur son expertise technique et son expérience de la sécurité applicative. 21 22 A propos de Deny All Deny All est l’un des pionniers de la technologie reverse proxy filtrante et le leader européen du marché des Web Application Firewalls. Ses produits protègent et accélèrent plus de 30 000 applications Web et serveurs FTP à travers le monde. Fondée en 2001, après quatre années d’incubation au sein de la Société Générale, la société Deny All fête ses 10 ans en 2011. Depuis son siège social situé à Boulogne Billancourt et grâce à ses équipes locales, Deny All est présente dans les principaux pays européens et représentée dans de nombreux pays du monde par son réseau de partenaires. Deny All s’adresse aux grands comptes comme aux PME, aux hébergeurs et aux fournisseurs de solutions « Cloud ». Les clients de Deny All interviennent dans de nombreux secteurs d’activité : banque et assurance, industrie, services, secteur public, commerce et e-Commerce. Entreprises et pouvoirs publics utilisent les pare-feux de Deny All pour sécuriser des applications désormais accessibles via un simple navigateur Web : site institutionnel, site bancaire, site commerçant, bien sûr, mais aussi messagerie, portail collaboratif, bases de données et applications d’entreprise, qu’il s’agisse d’ERP (Enterprise Resource Planning), de CRM (Customer Relationship Management), de gestion financière ou de gestion des ressources humaines. Les firewalls de Deny All protègent ces applications contre les risques de vandalisme, de déni de service, d’intrusion et de vols de données. Les attaques connues sont stoppées net, mais aussi celles de demain, grâce aux innovations technologiques telles que la scoring list ou l’analyse comportementale, pour n’en citer que deux. Les produits de Deny All, disponibles sous forme de logiciels, d’appliance physique, d’appliance virtuelle ou encore de service cloud, sont les suivants : sProxy 4.0, WAF plug & play particulièrement adapté aux besoins des PME, rWeb 4.0, WAF de nouvelle génération, combinant sécurité négative et positive, rXML 4.0, firewall pour Web Services, Edge, tests de pénétration pour applications Web, rFTP 3.0, pour sécuriser les serveurs FTP, Deny All Management Console 4.0, pour gérer votre sécurité applicative. Pour plus d’informations, rendez-vous sur www.denyall.com. 23 [email protected] Tel : + 33 1 46 20 96 00 Fax :+ 33 1 46 20 96 02 63 ter, Avenue Edouard Vaillant 92100 Boulogne-Billancourt 24 FRANCE Conception: Sogoa - RCS Paris 421 869 330 - Printed in France - 2011 Contact