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