Boiler BIG-IP ASM v13.1

BIG-IP® Application Security Manager™ (ASM)
est une solution de sécurisation des

infrastructures applicatives WEB. Ce module
permet de définir les politiques de sécurités des
applications web et des web services via des
politiques pré-définies ou par un puissant
moteur d’apprentissage. En complément de la
protection contre les attaques classiques ASM
dispose de moteurs spécifiques pour la
détection de robots, du "brute force" et des
dénis de service (DoS).
BIG-IP Application Security Manager ASM

Version 13.1
F5 Networks
1. Description synthétique de la solution BIG-IP ASM ______________________________ 4
1.1. Fonctions clés ________________________________________________________________5
1.2. Les types d’attaques qu’ASM bloque ______________________________________________6
1.3. Bénéfices d’ASM ______________________________________________________________7
2. Détail des fonctionnalités d'ASM ____________________________________________ 8

2.1. Création d’une politique de sécurité ______________________________________________8
2.1.1. L’approche sécurité positive _________________________________________________________9
2.1.2. L’approche de sécurité négative______________________________________________________9
2.1.3. L'approche de sécurité combinant sécurité positive et négative _____________________________9
2.1.4. L'analyse comportementale _________________________________________________________9
2.1.5. La protection au niveau du navigateur de l’utilisateur ____________________________________10
2.1.6. L'utilisation du moteur d’apprentissage automatique ____________________________________10
2.1.6.1. Réglage de la sensibilité du "Policy Builder" ________________________________________10
2.1.6.2. Policy Builder - Liste des sources de confiance ______________________________________11
2.1.6.3. Le mode semi-automatique ____________________________________________________11
2.1.7. L'utilisation d’un template ASM _____________________________________________________12
2.1.7.1. Templates spécifiques à une application __________________________________________12
2.1.7.2. Templates génériques_________________________________________________________12
2.1.8. L'utilisation d’un résultat d’audit de vulnérabilités ______________________________________12
2.2. Composants d’une politique de sécurité ASM ______________________________________14

2.2.1. Conformité protocolaire - "HTTP Protocol Compliance" __________________________________15
2.2.2. Techniques d'évasion – "Evasion Techniques" __________________________________________15
2.2.3. Types de fichiers – "File Type" ______________________________________________________16
2.2.4. Gestion des URLs – "URL" __________________________________________________________17
2.2.5. Gestion des paramètres - "Parameters" _______________________________________________18
2.2.5.1. Gestion des types de paramètres ________________________________________________19
2.2.5.2. Gestion des caractères spéciaux dans les paramètres ________________________________21
2.2.5.3. Gestion des informations privées des utilisateurs ___________________________________22
2.2.6. Signatures d'attaques – "Attack Signatures" ___________________________________________22
2.2.7. Gestion des sessions - "Session and Logins" ____________________________________________23
2.2.7.1. Renforcement des sessions des utilisateurs - "Login Enforcement" _____________________23
2.2.7.2. Suivi de session des utilisateurs - "Session Tracking" _________________________________24
2.2.7.3. Détection du vol de session - "Session Hijacking" ___________________________________26
2.2.8. Gestion des en-têtes HTTP – "Headers" _______________________________________________26
2.2.8.1. Gestion des Cookies __________________________________________________________26
2.2.8.2. Gestion du header "Host" ______________________________________________________27
2.2.8.3. Gestion des méthodes HTTP ____________________________________________________27
2.2.9. Adresses IP sources – "IP Addresses" _________________________________________________28
2.2.10. Profils pour contenus spécifiques – "Content Profile" ____________________________________29
2.2.10.1. Profil XML __________________________________________________________________29
2.2.10.1. Profil JSON__________________________________________________________________31
2.2.10.2. Profil GWT __________________________________________________________________31
1 BIG-IP APPLICATION SECURITY MANAGER v13.1| F5 NETWORKS

2.2.10.3. Profil Plain Text ______________________________________________________________32
2.2.11. Protection contre les fuites de données – "Data Guard" __________________________________33
2.2.12. Protection contre les attaques CSRF – "CSRF Protection" _________________________________34
2.2.13. Détection des anomalies – "Anomaly Detection"________________________________________35
2.2.13.1. Protection contre les atttaques "Brute-Force" ______________________________________35
2.2.13.2. Protection contre les attaques "Web Scraping" _____________________________________36
2.2.14. Intégration avec des services tiers – "Integrated Services" ________________________________37
2.2.14.1. Protection Anti-virus __________________________________________________________37
2.2.14.2. Sécurité des bases données (DAM) ______________________________________________38
2.2.15. Gestion des localisations des clients – "Geolocation Enforcement" _________________________38
2.3. Configurations complémentaires de sécurité ______________________________________39

2.3.1. Protection contre les Bots et les DoS - "DoS Profile" _____________________________________39
2.3.1.1. Protection contre le robots -"Bots" ______________________________________________39
2.3.1.2. Protection contre les attaques DoS/DDoS _________________________________________42
2.3.2. Sécurité FTP ____________________________________________________________________45
2.3.3. Sécurité SMTP ___________________________________________________________________46
2.4. Fonctionnalités de gestion des politiques ASM _____________________________________47

2.4.1. Politique de blocage ______________________________________________________________47
2.4.2. Moteur d'apprentissage de politique ASM – "Policy Builder" ______________________________47
2.4.3. Classification des violations de sécurité _______________________________________________50
2.4.4. Définition des "Server Technologies" _________________________________________________51
2.4.5. Visualisation de l'arborescence d'une politique ASM - "Tree View" _________________________51
2.4.6. Pages de réponse en cas de violation de politique de sécurité – "Response Pages" _____________52
2.4.7. Logs d'administration – "Audit Logs" _________________________________________________53
2.4.8. Historique des versions des politiques ASM ____________________________________________53
2.4.9. Gestion des différences entre politiques ASM __________________________________________54
2.4.10. Héritage entre politiques ASM ______________________________________________________54
2.4.11. Liste des tâches en attente _________________________________________________________57
2.4.12. Mise à jour de la base de signatures__________________________________________________58
2.4.13. Mise à jour de la base de réputation IP _______________________________________________59
2.5. Journaux d’événements – "Logs" ________________________________________________59

2.5.1. Événements de sécurité - "Event Logs" _______________________________________________59
2.5.2. Incident et corrélation d’événements – "Event Correlation" _______________________________61
2.5.3. Évènements DoS L7 ______________________________________________________________62
2.6. Génération de rapports – "Reporting" ____________________________________________63

2.6.1. Rapports sur les évènements de sécurité ______________________________________________63
2.6.2. Rapports sur les attaques DoS L7 ____________________________________________________65
2.6.2.1. Ecran de visualisation des attaques DoS___________________________________________65
2.6.2.2. Rapport sur les latences par URL ________________________________________________66
2.6.3. Conformité PCI-DSS ______________________________________________________________67

Contrôle du document
Contributeurs
Nom Département
Nicolas Berthier Avant-Vente
Tewfik Megherbi Avant-Vente
Xavier Dauphin Avant-Vente
Correcteurs
Nom Département
Révisions du document
Date Auteur Version Description de la révision
N. Berthier 11.2 Original

CréationAuthor
17/09/2014 T. Megherbi 11.6 Ajouts des nouvelles fonctionnalités de la version 11.3 à 11.6
05/05/2016 T. Megherbi 12.0 Ajouts des nouvelles fonctionnalités de la version 12.0
04/07/2016 T. Megherbi 12.1 Ajouts des nouvelles fonctionnalités de la version 12.1
01/03/2018 X. Dauphin 13.1 Ajouts des nouvelles fonctionnalités de la version 13.1
Documents liés
Référence Auteur Version Description de la révision

1. Description synthétique de la solution BIG-IP ASM
Avec l’explosion des applications web 2.0 et du trafic applicatif web, une quantité croissante de données sensibles
est exposée aux tentatives de vol, aux vulnérabilités de sécurité et aux vecteurs d’attaques.
F5 BIG-IP® Application Security Manager™ (ASM) est la solution de sécurité développée pour les applications Web.
En tant que Pare-feu Applicatif Web (Web Application Firewall ou WAF), la solution ASM (Application Security
Manager) permet d’assurer la sécurité des applications Web tout en préservant leur fonctionnement et leur
disponibilité. Elle intègre également, sur la même plateforme, des fonctions d’ADC, de Reverse-Proxy et d’anti-DDoS,
permettant ainsi de consolider en un point central tous les outils nécessaires à la publication sécurisée d’une
application.
La solution F5 BIG-IP® Application Security Manager™ (ASM) est un Pare-feu Applicatif Web totalement flexible qui
sécurise les applications web et ce quel que soit le mode de déploiement choisi : traditionnel ou alors en
environnement cloud, public et privé. L’administrateur de la solution a également toujours le choix d’utiliser l’outil
en mode dit "Bloquant", évitant ainsi les attaques éventuelles, ou en mode dit "Transparent", c’est à dire
uniquement comme un outil de surveillance de ses applications, capable aussi de générer des rapports sur
l’utilisation de ses applications.
ASM permet de contrôler très finement les échanges entre les utilisateurs et les serveurs Web. Les éléments pouvant
être analysés ou filtrés sont :
§ Les protocoles (RFC) et langages (HTTP, XML, JSON, Web Socket…)

§ Les techniques d’évasion (attaques offusquées)
§ Les motifs d’attaques connues (liste de signatures)
§ Les méthodes HTTP (GET, POST, HEAD, etc…)
§ Les types d’objets (JPEG, PNG, HTML, JS, CSS, etc…) et leur taille
§ Les URL et leur enchainement
§ Les paramètres (inputs) : leur nom et leurs valeurs possibles
§ Les sessions des utilisateurs
§ Les cookies
§ La structure des données d’un web service SOAP/XML ou REST/JSON notamment
§ Les headers HTTP
§ La géolocalisation et la réputation IP d’un utilisateur
§ La présence d’un bot imitant le comportement d’un utilisateur
§ Tout utilisateur ou robot ayant une utilisation abusive de l’application protégée (déni de service, Brute-
Force, aspiration de contenu, etc…)

1.1. Fonctions clés
Les fonctions clés de la solution ASM sont les suivantes :
§ Des templates de configuration pré-définis pour les applications les plus populaires.
§ Des fonctionnalités d’apprentissage entièrement automatisé ou semi-automatisé permettant de construire
simplement une politique de sécurité pour chaque application.
§ Une base de signatures d’attaques (également appelée "liste noire").
§ Des outils simplifiant la création d’une "liste blanche" comprenant l’ensemble des objets constituant une
application web (URLs, paramètres, fichiers, méthodes, headers, cookies, etc…).
§ Des moteurs d'analyse du comportement des utilisateurs, permettant la détection et l'atténuation des
dénis de service (DoS/DDoS), des attaques "Brute-Force" et des aspirations de contenu ("Web Scraping").
§ Un suivi et un renforcement des sessions des utilisateurs tout au long de leur navigation.
§ Un moteur unique de protection contre les attaques de type CSRF, visant à exploiter la session d’un
utilisateur à son insu.
§ Une base de données de géolocalisation IP.
§ Une base de données de réputation IP.
§ Un firewall SOAP/XML et REST/JSON permettant la protection des applications de type "web service"
§ Une fonctionnalité unique de protection des applications utilisant les Web Sockets.
§ Un moteur de détection des fuites de données.
§ Une intégration avec des solutions tierces de type anti-virus, via le protocole ICAP, pour analyse du contenu
des fichiers postés par les utilisateurs.
§ Une interface douée de capacités à traiter des logs en masse ou à les exporter vers des systèmes tiers.
§ Un outil de génération et d'export de rapports.

1.2. Les types d’attaques qu’ASM bloque
F5 BIG-IP® Application Security Manager™ (ASM) protège les infrastructures web critiques des attaques ciblant la
couche applicative, que celles-ci visent à compromettre la disponibilité, la confidentialité ou l'intégrité du contenu
publié. Par exemple, ASM protège contre les attaques suivantes :
§ Les manipulations des cookies ou des champs cachés.

§ Les attaques en injection SQL visant à exposer les informations confidentielles ou à corrompre les données.
§ Les exploitations malicieuses des buffers mémoire pour arrêter des services, avoir les accès au Shell et pour
propager des programmes malicieux.
§ Les accès non autorisés aux comptes d’utilisateurs authentifiés en utilisant la méthode Cross-Site Request
Forgery (CSRF)
§ Les changements non autorisés du contenu du serveur
§ Les tentatives visant à saturer l’application web, à ralentir les réponses aux utilisateurs légitimes.
§ Les attaques en déni de service sur la couche 7 ("DoS")
§ Les attaques de type "Brute-Force", essayant de voler l'identité et les données d'un utilisateur légitime.
§ Les attaques de type "Web Scraping", ayant pour but de collecter massivement des données et de manière
abusive.
§ Les accès via des adresses IP suspectes ou des localisations non autorisées

1.3. Bénéfices d’ASM
Garantit la sécurité et la disponibilité de l’application

F5 BIG-IP® Application Security Manager™ (ASM) fournit une protection contre les injections de code malveillant,
contre l’utilisation abusive de l’application protégée, et de manière générale contre les attaques du top 10 OWASP.
Cette protection est valable aussi bien pour les applications web classiques que pour les applications dynamiques
utilisant AJAX et JSON ou celles fonctionnant uniquement sous la forme d’un web service (SOAP/XML ou REST/JSON).
Réduit les coûts d'exploitation et assure la conformité des applications

F5 BIG-IP® Application Security Manager™ (ASM) permet d’assurer la conformité aux standards de sécurité (PCI-DSS
notamment) avec une protection applicative intégrée et un déploiement centralisé de politiques de sécurité,
assurant une exploitation simplifiée des politiques de sécurité applicative.
Fournit des politiques de sécurité prêtes à l’emploi

F5 BIG-IP® Application Security Manager™ (ASM) fournit une protection efficace grâce à des politiques de sécurité
prédéfinies et ne nécessitant qu'une configuration minimale, facilitant une mise en production rapide.
Améliore la sécurité et la performance des applications

Permet définir des politiques de sécurité avancées tout en améliorant les performances et en optimisant les coûts.
En effet, certaines fonctions assimilables à un celles d’un Reverse-Proxy comme la compression HTTP, la mise en
cache du contenu, la gestion du chiffrement SSL, l’optimisation TCP ou la répartition de charge sont également
embarquées nativement dans ASM.
Apporte de la flexibilité et s’intègre avec les outils de sécurité tiers

Permet aux équipes IT de se focaliser sur le déploiement rapide d’applications, d’apporter de la flexibilité dans leur
choix d’environnement qu’il soit physique, virtuel ou dans un cloud, tout en s’intégrant avec des solutions externes
comme les outils de détection de vulnérabilités pour effectuer du Virtual Patching applicatif. Ainsi, les équipes IT
peuvent automatiser les tests sur les politiques de sécurité ASM, permettant de réduire considérablement le temps
d’apprentissage d’ASM pour construire une politique adaptée à chaque application.

2. Détail des fonctionnalités d'ASM
2.1. Création d’une politique de sécurité
La création d’une nouvelle politique de sécurité ASM passe par l’utilisation d’un assistant de configuration qui
permet de faire certains choix stratégiques dès la création de la politique ASM, comme par exemple le fait d’être
dès le départ en mode bloquant ou transparent, ou d’opter pour un template de configuration, ou encore de choisir
des signatures d’attaques adaptées à l’application à protéger.
Figure 1 : Écran de configuration de l’assistant de création
Afin de choisir un template de configuration adapté, il est recommandé de déterminer au préalable quelle(s)
approche(s) ASM devra utiliser pour sécuriser l’application. En effet, deux visions s’opposent généralement mais
peuvent très bien se compléter : l’approche positive et l’approche négative.
De même, l'administrateur devra déterminer le degré d'autonomie qu'il souhaite donner à ASM et son "Policy
Builder" dans la construction d'une politique de sécurité. En effet, l'administrateur peut décider :
§ de laisser ASM se configurer presque en totale autonomie, le "Policy Builder" ayant alors le droit de modifier
des éléments de configuration de la politique de sécurité sans accord préalable de l'administrateur.
§ de laisser ASM suggérer des modifications de la politique de sécurité, nécessitant accord préalable de
l'administrateur avant leur prise en compte effective dans la politique de sécurité.
§ de désactiver tout mécanisme d'apprentissage s'il estime que le template utilisé ne nécessitera pas de
modification ou des modifications pouvant être manuellement réalisées par l'administrateur s'il en a la
compétence.

2.1.1. L’approche sécurité positive
Dans cette approche de la sécurité, appelée également liste blanche, l’administrateur ou l’exploitant doit connaître
l’application de façon assez complète à exhaustive. L’idée générale est de définir dans ASM l’architecture, la
structure de l’application à protéger, afin de bloquer tout ce qui n’aura pas été explicitement autorisé. Tous les
objets constituant l’application devront être définis, à savoir notamment les URI, les types de fichiers, les méthodes
HTTP, les cookies, les paramètres, etc... Il n’est pas toujours nécessaire de définir l’intégralité des objets mais la
philosophie de cette approche est d’être le moins générique possible. Par exemple pour simplifier la construction
d’une politique positive, il est possible de définir uniquement les URI du premier niveau d’arborescence sans
forcément définir les autres niveaux (déclarer /abc/* sans pour autant devoir déclarer /abc/def/ et /abc/ghi).
En suivant cette approche, les délais de réalisation de la politique de sécurité peuvent être plus ou moins longs,
suivant la complexité de l’application et le niveau de sécurité que l’on souhaite appliquer sur cette application. Ainsi,
pour être efficace dans cette approche et éviter aux administrateurs de la solution d’avoir un trop grand nombre de
saisies manuelles à effectuer, il est recommandé d’utiliser les outils d’auto-apprentissage d’ASM pour qu’il crée de
lui-même tous les objets de la Liste Blanche. Pour faciliter et accélérer ce traitement automatisé, il est recommandé
de placer ASM entre l’application et un outil de test automatisé de l’application web (scanner) ou une population
d’utilisateurs réputés légitimes.
2.1.2. L’approche de sécurité négative
Dans cette approche de la sécurité, appelée également liste noire, l’administrateur ou l’exploitant n’a pas besoin de
connaître finement le fonctionnement de l’application. L’idée générale est d’autoriser tout ce qui n’aura pas été
explicitement interdit. L’administrateur peut faire confiance aux bases de signatures fournies avec la solution ASM,
qui couvrent un très large spectre d’attaques possibles. Une connaissance générique de la sécurité des applications
Web et des applications à protéger est suffisante pour sélectionner les signatures à activer. Les délais de mise en
œuvre de la politique de sécurité sont très rapides, ce qui fait que ce mode de déploiement est aujourd’hui le plus
utilisé par les administrateurs d’ASM.
2.1.3. L'approche de sécurité combinant sécurité positive et négative
Dans ce cas de figure, une connaissance basique du fonctionnement de l’application à protéger permet de mettre
en œuvre une politique de sécurité plus efficiente. L’administrateur ou l’exploitant peut commencer par appliquer
une sécurité négative pour obtenir dans un premier temps un niveau de sécurité déjà robuste. Il peut ensuite
compléter cette sécurité avec une approche positive sur les éléments les plus critiques de l’application. Cela permet
d’augmenter le niveau de sécurité sans pour autant allonger considérablement les délais de mises en œuvre de la
politique de sécurité.
2.1.4. L'analyse comportementale
Pour certains types d’attaques web, il n’est pas toujours possible d’avoir une approche positive ou négative dans le
sens où chaque requête utilisateur, analysée de manière unitaire, serait toujours considérée comme légitime quel

que soit le modèle. Il s’agit notamment des attaques de type DoS L7 ou DDoS L7, Brute-Force ou Web Scraping. De
manière plus générale, il s’agit souvent de différencier le comportement humain légitime de celui d’un robot (Bot).
ASM propose pour ces scénarios d’attaque spécifiques des moteurs de sécurité alternatifs, basés sur l’analyse
statistique et heuristique des utilisateurs de l’application.
L'analyse comportementale est un complément souvent indispensable, que l'approche globale soit positive ou
négative.
2.1.5. La protection au niveau du navigateur de l’utilisateur
Certaines attaques web sont malheureusement réalisables sans que le trafic malveillant passe par ASM, rendant la
détection des requêtes illégitimes beaucoup plus difficile. C’est notamment le cas des attaques CSRF, où l’injection
de contenu malveillant se fait directement entre un site web corrompu (non protégé par ASM) et le navigateur de
l’utilisateur. L’attaque vise à utiliser à son insu et à travers son navigateur la session de l’utilisateur sur l’application
à protéger. Pour contrer ce type d’attaque, ASM sait injecter du contenu dans les pages web du site à protéger afin
de pouvoir différencier les actions réellement effectuées par l’utilisateur d’une session de celles effectuées sans son
accord.
2.1.6. L'utilisation du moteur d’apprentissage automatique
Quelle que soit l’approche de la sécurité choisie (notamment positive ou négative), ASM peut mettre en œuvre son
moteur d’apprentissage automatisé. Il utilise alors le flux de production ou de qualification (un scanner web par
exemple) pour créer une politique de sécurité. Quand le flux analysé est un flux de production, toutes les sources ne
sont pas considérées comme "garanties" et un moteur d’analyse statistique est utilisé pour détecter l’activité
légitime des attaques pouvant avoir lieu pendant l’apprentissage. Par exemple, pour être considérée comme
légitime, une requête doit être vue de manière très répétitive sur plusieurs sessions utilisateur, en provenance de
plusieurs adresse IP et pendant une plage de temps ni trop longue ni trop courte. Lorsque le trafic de production est
trop faible pour réaliser une telle analyse statistique ou tout simplement pour accélérer le traitement, il est
également possible de définir une liste d’adresses IP de confiance, à partir desquelles ASM accélérera son
apprentissage.
2.1.6.1. Réglage de la sensibilité du "Policy Builder"

La configuration du "Policy Builder" permet aussi de configurer les seuils statistiques utilisés pour autoriser la
création d’un nouvel objet dans la politique de sécurité quand l’adresse IP de l’utilisateur n’est pas catégorisée
comme source de confiance. Pour simplifier, il est possible de configurer le "Policy Builder" pour apprendre très
rapidement ou pour apprendre en ayant un meilleur niveau de garantie sur la qualité des sources. Ce choix est réalisé
par le choix d’une vitesse "low", "medium" ou "fast" qui augmente ou réduit le nombre de session, le nombre d’IP
et le nombre de requêtes nécessaires pour autoriser la création de l’objet.

Figure 2 : Seuils d'apprentissage paramétrables
2.1.6.2. Policy Builder - Liste des sources de confiance

En plus des statistiques, il est possible de manuellement configurer une liste d’adresses IP qui seront
automatiquement considérées comme de confiance pour apprendre les objets directement. Il s’agit généralement
des adresses IP des machines de qualification, des développeurs, ou d’un scanner légitime car aucune attaque n’est
attendue depuis ces machines.
2.1.6.3. Le mode semi-automatique

Il est toujours possible pour l’administrateur d’ASM de valider manuellement les choix suggérés par le Policy Builder.
Dans ce cas, l’administrateur va accéder à un menu nommé "Learning Suggestions" et valider/invalider les
changements de configuration proposés par le Policy Builder. Un indice de confiance sur chaque suggestion indique
la probabilité que ce changement soit nécessaire et légitime. NB : en mode automatique, le Policy Builder n’accepte
automatiquement que les suggestions ayant 100% de score de confiance.
Figure 3 : Écran d'apprentissage des suggestions

2.1.7. L'utilisation d’un template ASM
2.1.7.1. Templates spécifiques à une application

Quand l’application à sécuriser avec ASM est une application standard, il est possible d’utiliser une politique fournie
pas F5 via l’assistant de configuration.
La liste des "templates" actuellement disponibles est :
§ ActiveSync v1.0 v2.0

§ Drupal
§ Joomla
§ LotusDomino 6.5
§ OWA Exchange 2003
§ OWA Exchange 2003 with ActiveSync
§ OWA Exchange 2007 with ActiveSync
§ Oracle 10g Portal
§ Oracle Applications 11i
§ PeopleSoft Portal 9
§ SAP NetWeaver 7
§ SharePoint 2003
§ SharePoint 2007
§ SharePoint 2010
§ Wordpress
2.1.7.2. Templates génériques

ASM propose également des templates génériques, destinés à être déployés quelle que soit l’application à protéger.
En voici la liste actuelle :
§ Fundamental
§ Comprehensive
§ Passive Deployment Policy
§ Rapid Deployment Policy
§ Vulnerability Assessment Baseline
2.1.8. L'utilisation d’un résultat d’audit de vulnérabilités
Pour faciliter la création et même l’évolution d’une politique de sécurité ASM tout au long du cycle de vie d’une
application, il est possible d’utiliser les rapports d’outils d’audit de vulnérabilités du marché. Les outils actuellement
supportés sont :
§ QualysGuard

§ Trustwave App Scanner (Cenzic)
§ WhiteHat Sentinel
§ IBM AppScan
§ HP WebInspect
§ ImmuniWeb
§ Quotium Seeker
Il suffit, en fonction de l’outil d’audit utilisé, soit de télécharger le rapport d’audit via l’interface d’administration,
soit de laisser ASM utiliser l’API de l’éditeur pour télécharger automatiquement ce rapport.
Dans le cas où le scanner à utiliser ne serait pas référencé, il est toujours possible d’utiliser un format générique
pour en importer le rapport de vulnérabilités. Dans ce cas, un travail de conversion de données entre le format du
scanner et le format d’ASM sera à effectuer.
Figure 4 : Écran d'import d’un rapport d’audit de vulnérabilités
Figure 5 : Utilisation d'un rapport d’audit de vulnérabilités

2.2. Composants d’une politique de sécurité ASM
Les politiques de sécurité ASM se composent de différents éléments que l’on retrouve sous les termes suivants :
Entité Description Classification principale

Vérification de la conformité
HTTP Protocol Compliance Sécurité négative
protocolaire des requêtes HTTP
Détection des techniques
d’évasion, permettant aux hackers
Evasion Techniques Sécurité négative
de contourner d’autres systèmes
de protection
Extension des pages composant
Sécurité positive
File Types l’application (HTML, JS, PNG, GIF,
Sécurité négative
JPEG, etc…)
Sécurité positive
URLs URL utilisées par l’application
Paramètres (inputs) de
Parameters l’application. Exemple : entrées des Sécurité positive
formulaires
Attack Signatures Base de signatures d’attaques Sécurité négative
Sécurité positive
Suivi et renforcement des sessions
Session and Logins Analyse comportementale
utilisateur
Reporting / suivi des utilisateurs
Header HTTP apparaissant dans
Headers l’application. Inclut également les Sécurité positive
cookies et les méthodes HTTP
Gestion des adresses IP client de
confiance (liste blanche) et Sécurité positive
IP Adresses
réputées malveillantes* (liste Sécurité négative
noire)
Définition de profils pour tes
formats de données spécifiques
Sécurité positive
Content Profiles comme XML ou JSON
(essentiellement pour des web
services)
Détection et blocage ou offuscation
Data Guard Sécurité négative
du contenu sensible des pages
Protection contre le Cross Site
CSRF Protection Sécurité du navigateur
Request Forgery
Protection contre les attaques
Anomaly Detection Analyse comportementale
Brute-Force, Web Scraping
Antivirus intégré (ICAP) et
Integrated Services protection de base de données Intégration avec des outils tiers
(SGBDR)
Accessibilité de l’application web
Sécurité positive
Geolocation Enforcement en fonction de la localisation
géographique des clients
* La liste des IP réputées malveillantes est une option soumise à licence additionnelle (IP Intelligence)

2.2.1. Conformité protocolaire - "HTTP Protocol Compliance"
Ce composant permet à ASM de s’assurer de la conformité des requêtes reçues avec le protocole HTTP. La liste des
critères d’évaluation est paramétrable. Ces options sont globales à la politique de sécurité ASM et non dépendantes
d’un contexte applicatif particulier.
Figure 6 : Contrôles de conformité protocolaire
2.2.2. Techniques d'évasion – "Evasion Techniques"
Ce composant permet à ASM de détecter la présence de techniques d’évasion dans les requêtes HTTP reçues,
pouvant permettre à un hacker de contourner un autre système de protection mis en place par ASM lui-même ou
par le serveur web.
Une technique d’évasion courante est l’encodage de certains paramètres, permettant de masquer leur caractère
malveillant au regard de certains moteurs de sécurité. Afin que ces outils de protection restent efficaces, il appartient
à cette fonction de décoder ces paramètres donc de rendre lisible et interprétable tout le contenu des requêtes
HTTP.
Les options de paramétrage du composant Evasion Techniques sont globales à la politique de sécurité ASM et non
dépendantes d’un contexte applicatif particulier.

Figure 7 : Contrôles des techniques d'évasion
2.2.3. Types de fichiers – "File Type"
Ce composant permet de gérer les types de fichiers (HTML, PNG, GIF, JPEG…) autorisés ou interdits pour les
utilisateurs de l’application.
Pour les fichiers autorisés, les entrées sont créées par extension et l’on peut associer à cette extension des
contraintes complémentaires du type longueur de l’URL, longueur des requêtes, longueur des POST.
Figure 8 : Configuration d'un type de fichier autorisé
Pour la liste des fichiers interdits, seule l’extension du fichier est nécessaire.
Figure 9 : Configuration d'un type de fichier interdit

2.2.4. Gestion des URLs – "URL"
Le composant URL permet de créer des listes d’URL autorisées ou interdites sur le serveur applicatif.
Ces URL sont constituées du chemin absolu à la ressource (/dir_1/dir_2/index.html) mais peuvent aussi contenir des
caractères génériques.
Le paramétrage d'une URL peut également inclure la définition des méthodes HTTP autorisées ou interdites sur celle-
ci. Ce paramètre préempte la liste des méthodes autorisées au global sur la politique ASM.
Figure 10 : Configuration d'une URL autorisée
Figure 11 : Configuration d'une URL interdite
Il est aussi possible de préciser pour l’ensemble des URL de l’application les caractères spéciaux autorisés ou
interdits.

Figure 12 : Configuration des caractères spéciaux autorisés dans les URLs
Il est possible en complément des listes blanches et noires de configurer ASM pour vérifier le "circuit" utilisateur
entre les pages web. Par exemple autoriser l’accès à la page page2.html uniquement si la précédente page était
index.html. Cette fonction s’appelle le "flow" et permet de créer des liaisons statiques ou dynamiques entre les URLs
autorisées.
Figure 13 : Configuration d'un "Flow"
2.2.5. Gestion des paramètres - "Parameters"
Ce composant permet de gérer les différents paramètres envoyés par l’utilisateur de l’application à protéger. Il s’agit
le plus souvent des paramètres d’un formulaire HTML mais il peut aussi s’agir d’une liste de valeurs en format JSON
ou d’un contenu au format XML.
Chaque paramètre configuré dans la politique ASM repose principalement sur les points suivants :
§ Son nom
§ Son niveau (Global, URL ou Flow). En effet un même paramètre peut être utilisé sur plusieurs pages avec
des comportements différents, il est donc possible de définir si la configuration s’applique pour l’ensemble
de l’application, pour une URL spécifique ou un flow (liaison entre deux URLs).
§ Ses valeurs possibles : en fonction du type de valeur du paramètre la protection apportée par ASM va être
différente. En effet, ASM traitera différemment une saisie dans un formulaire HTML, un upload de fichier,
un paramètre JSON et fichier XML.
§

2.2.5.1. Gestion des types de paramètres
Le type User-Input Value

Ce type est utilisé quand le paramètre est obtenu via la saisie par l’utilisateur dans un formulaire d’une valeur. Cette
configuration permet de préciser le "data type" (Alpha-numeric, File Upload, decimal, mail, integer ou phone). Il est
aussi possible de préciser un masque de validation ainsi que les caractères spéciaux autorisés, de même que les
signatures d’attaques à activer ou désactiver spécifiquement pour ce paramètre.
Figure 14 : Configuration d'un paramètre de type "User-Input Value"
Le type Ignore Value

Ce type permet de demander à ASM de ne pas sécuriser ce paramètre.
Le type JSON Value

Ce type est utilisé pour un échange JSON et doit impérativement être associé à un profile "Content Profile JSON"
Figure 15 : Configuration d'un paramètre de type "JSON Value"
Le type XML Value

Ce type est utilisé pour un échange XML et doit impérativement être associé à un profile "Content Profile XML"

Figure 16 : Configuration d'un paramètre de type "XML Value"
Le type Static Content Value

Ce type est utilisé pour un paramètre dont les valeurs sont finies. Il est nécessaire pour l’administrateur ASM de
connaitre de façon exhaustive les valeurs autorisées et de les préciser dans l’interface.
Figure 17 : Configuration d'un paramètre de type "Static Content Value"
Le type Dynamic Content Value

Ce type est utilisé quand un paramètre est envoyé sans action explicite de l’utilisateur (par exemple des champs
"Hidden" dans un formulaire ou liste déroulante dynamique) et permet à ASM d’automatique extraire de la page
HTML envoyée par le serveur la ou les valeurs autorisées. Elle nécessite l’utilisation d’un objet complémentaire
appelé "Extraction" qui permet à ASM de savoir où extraire l’information du masque de sécurité positive.
Figure 18 : Principe de fonctionnement du "Dynamic Content Value"

Figure 19 : Extraction du contenu dynamique d'un paramètre
2.2.5.2. Gestion des caractères spéciaux dans les paramètres

Il est possible de configurer les caractères spéciaux autorisés ou interdits dans les noms ou les valeurs de façon
spécifique pour chaque paramètre ou de façon globale.
Figure 20 : Gestion de caractères spéciaux dans les paramètres

2.2.5.3. Gestion des informations privées des utilisateurs
Il est possible de configurer ASM pour ne pas générer de log sur le contenu de certains paramètres. La politique de
sécurité est bien appliquée mais la valeur de ces paramètres n’apparait pas dans les journaux ainsi que dans la GUI
d’administration.
Figure 21 : Gestion des paramètres "sensibles"
2.2.6. Signatures d'attaques – "Attack Signatures"
ASM contient par défaut une base de signatures d’attaques catégorisées. Il est possible de configurer globalement
pour l’intégralité du site web protégé les signatures utilisées sachant que pour tout objet de la politique il est aussi
possible d’ajouter ou de désactiver spécifiquement une ou plusieurs signatures.
Figure 22 : Utilisation des signatures d'attaques
Il est conseillé d'activer sur chaque politique ASM des signatures génériques (valables pour tout type d'application
web), ainsi que des signatures spécifiques au système protégé (par exemple les signatures spécifiques à MySQL si ce
type de base de données fait partie de la chaine applicative).
NB: le menu "Server Technologies" de chaque politique de sécurité permet de faciliter la sélection des groupes de
signatures.

2.2.7. Gestion des sessions - "Session and Logins"
2.2.7.1. Renforcement des sessions des utilisateurs - "Login Enforcement"

Afin d’améliorer le niveau de sécurité, ASM peut détecter et renforcer la sécurité des sessions utilisateur. Cette
gestion repose sur la configuration des pages utilisées pour l’authentification (et éventuellement la déconnexion)
des utilisateurs.
Il faut configurer ASM pour détecter la saisie du formulaire d’authentification ainsi que les paramètres renseignés
par l’utilisateur, de même que les messages renvoyés par le serveur en cas de succès ou d’échec d’authentification.
Actuellement ASM supporte les mécanismes d’authentification suivants :
§ Formulaire HTML
§ HTTP basic
§ HTTP digest
§ NTLM
§ JSON / AJAX
Figure 23 : Création d’une page d’authentification
NB: le Policy Builder peut être configuré pour détecter automatiquement les pages de login, évitant ainsi la saisie
manuelle des paramètres ci-dessus.
Une fois l’authentification détectée par ASM il est possible de configurer les parties du site web non accessibles sans
être authentifié ainsi que la durée de vie de la session.

Figure 24 : Protection des zones soumises à authentification
2.2.7.2. Suivi de session des utilisateurs - "Session Tracking"

De même, grâce à la détection des paramètres d'authentification, le nom d’utilisateur associé à chaque session
pourra apparaitra dans les journaux (logs) ASM, pour chacune des requêtes journalisées. Ceci permet de suivre plus
facilement les actions d’un utilisateur sur l’application protégée et éventuellement de faciliter l’analyse des logs par
des outils tiers.

Figure 25 : Journaux avec suivi des sessions
L’utilisation du "Session Tracking" dans ASM permet aussi de mettre en place des contre-mesures automatiques
(comme le blocage complet d’une session) quand un seuil d’attaques pour un utilisateur est dépassé ou de modifier
la configuration de journalisation pour enregistrer l’ensemble de trafic (légitime et malveillant) quand une activité
suspecte est détectée pour un utilisateur.
De même, pour les environnements où le risque de faux positif est considéré comme bien plus important que le
risque de non blocage d’une requête malveillante, il est possible de commencer à bloquer les requêtes d’un
utilisateur qu’à partir de la nième requête suspecte détectées dans la même session.

Figure 26 : Configuration du "Session Tracking"
2.2.7.3. Détection du vol de session - "Session Hijacking"

ASM peut calculer pour chaque utilisateur un "device ID", sur la base d'informations récupérées au sein du
navigateur du client. Cela permet de détecter et prévenir le piratage de session. Concrètement, si un même cookie
est utilisé par deux "device IDs" différents, cela indique à ASM qu'une session a été volée.
NB: il est possible de définir une page de réponse spécifique pour le blocage des sessions volées.
2.2.8. Gestion des en-têtes HTTP – "Headers"
Le composant "Header" permet la mise en place d’une politique sur les entêtes HTTP (comme les cookies) envoyés
par le client ou par le serveur.
2.2.8.1. Gestion des Cookies

Dans une politique ASM il est possible de configurer les cookies autorisés et surtout de préciser si les cookies sont
modifiables par le client.

Figure 27 : Configuration d'une protection de cookie
Il est aussi possible de configurer les caractères spéciaux autorisés ou interdits dans les cookies.
Figure 28 : Caractères spéciaux autorisés dans les cookies
2.2.8.2. Gestion du header "Host"

Toute requête HTTP 1.1 contient un champ Host qui est généralement le nom DNS du serveur hébergeant
l’application. Il est possible avec ASM de créer une liste des "hosts" autorisés dans le champ.
Figure 29 : Gestion du header "Host"
2.2.8.3. Gestion des méthodes HTTP

ASM permet aussi de gérer une liste blanche des méthodes HTTP autorisées dans l’application.

Figure 30 : Gestion des méthodes HTTP autorisées
2.2.9. Adresses IP sources – "IP Addresses"
Le composant "IP Addresses" permet de gérer des listes d’exceptions pour plusieurs moteurs dont la prise de
décision peut se baser sur l’adresse IP source, ainsi que la gestion de la base de réputation IP.
La liste d’exceptions peut mettre en œuvre les actions suivantes :
§ Considérer une adresse IP comme étant de confiance" pour le Policy Builder

§ Ignorer l’adresse IP dans la détection d’anomalies (Brute-Force et Web Scraping)
§ Ne pas générer de suggestion d’apprentissage pour le trafic en provenance de l’adresse IP
§ Ne jamais bloquer l’adresse IP
§ Ne jamais journaliser le trafic en provenance de l’adresse IP
§ Ne pas appliquer le filtre de réputation sur l’adresse IP
Figure 31 : Exception sur adresse IP source

Le même composant "IP Addresses" permet de configurer la gestion du filtre par réputation IP. Pour les différentes
catégories de la base "IP Intelligence" il est possible de choisir entre journalisation et/ou blocage. Les catégories
actuellement supportées sont :
§ IP détectée comme exploitant des failles Windows

§ IP détectée comme attaquant des sites web
§ IP détectée comme participant à un BotNet
§ IP détectée comme scanner web
§ IP détectée comme participant à des dénis de service
§ IP détectée comme source infectée
§ IP détectée comme source de phishing
§ IP détectée comme proxy anonyme
§ IP détectée comme appartenant à un fournisseur de Cloud
§ IP détectée comme application mobile malveillante
§ IP détectée comme appartenant au réseau Tor
Figure 32 : Filtre par réputation IP
2.2.10. Profils pour contenus spécifiques – "Content Profile"
Le composant "Content Profile" permet la gestion du XML, du JSON ainsi que du Google Web Toolkit (GWT).
Ces profils sont nécessaires pour permettre à ASM de gérer les requêtes SOAP/XML, comprendre le format de
données JSON et formater des messages d’erreur spécifiquement pour ces environnements.
2.2.10.1. Profil XML

La sécurité XML comprise dans ASM porte sur les aspects suivants :

Conformité des schémas
La communication d’information est régie par un ensemble de règles décrivant comment doivent être mises en place
les données. Cet ensemble de règles constitue le schéma XML. Si des informations étaient transmises sans valider le
schéma, les composants de l’application aboutiraient à un comportement inattendu.
Validation de l’utilisation des méthodes SOAP

Certains outils de développement s’appuyant sur XML génèrent du code pour les applications ainsi que les moyens
d’accéder aux fonctions assurées par ces applications. Ces fonctions peuvent être utilisées à l’aide d’appels avec
SOAP. Si ces services sont utilisés avec des paramètres incorrects, ils peuvent mettre à mal l’application qui les
consomme. De même, si la liste de ces services est complètement ouverte, il peut être possible de tous les découvrir
et d’accéder à d’autres comportements ou données de l’application, alors que ceux-ci auraient dû rester cachés.
Protection des Parsers XML

Les parsers XML sont chargés d’interpréter et de transmettre les données aux moteurs applicatifs (XML
DOM). Si ces données sont mal formatées ou ne respectent pas les standards, le traitement de ces données par le
parsers XML conduit à des comportements inattendus (consommation excessive de mémoire, boucle infinie, charge
excessive, ...).
Vérification de motifs d’attaques

Les messages XML peuvent véhiculer des attaques sur les applications, tout comme on pourrait le faire
dans un formulaire Web. Il est alors nécessaire d’analyser ces messages et de s’assurer qu’ils ne sont pas vecteurs
d’attaques classiques sur les bases de données, l’injection de commande, la navigation XPath, etc…
La mise en place d’une politique XML Firewall nécessite l’utilisation d’un fichier de description de service. Ce fichier
de description prend la forme d’un fichier WSDL ou XML qui doit être importé dans la console ASM.
Figure 33 : Import de fichier WSDL/XML

2.2.10.1. Profil JSON
La configuration du profil JSON permet le parsing du JSON. L’option Parse Parameters permet notamment de
d’apprendre les paramètres JSON détectés et de les retrouver dans le menu Parameters.
Figure 34 : Configuration d'un profil "JSON"
2.2.10.2. Profil GWT

Google Web Toolkit (GWT) est un Framework Java qui est utilisé pour créer des applications AJAX.
Lorsqu’on ajoute la fonctionnalité de validation GWT à une politique de sécurité, le système peut détecter les
données GWT malformées, les requêtes et les valeurs de paramètres qui dépassent les limites de longueur définies,
les signatures d’attaques, et les méta-caractères illégaux dans les valeurs de paramètres.
La configuration du profil GWT permet le parsing du GWT et aussi de configurer les signatures d’attaques associées.

Figure 35 : Configuration d'un profil "GWT"
2.2.10.3. Profil Plain Text

Dans le cadre de la sécurisation d’une application de type Web Socket, il peut s’avérer nécessaire de définir un profil
"Plain Text" (texte simple) afin d’analyser les données transitant au travers de ces connexions, sous réserve que
celles-ci sont bien dans ce format de données. Ce format de données est d’ailleurs celui utilisé par défaut pour les
URL Web Socket wilcard (*) ou toute nouvelle création d’URL Web Socket, notamment lorsqu’elle ne peut être
catégorisée en format JSON ou "Binary" (binaire).
Les paramètres disponibles dans le profil "Plain Text" permettent de limiter les longueurs des "payloads" ou de
chaque ligne d’un "payload", ainsi que de définir les signatures d’attaques et les méta-caractères devant être
détectés.

Figure 36 : Configuration d'un profil "Plain Text"
2.2.11. Protection contre les fuites de données – "Data Guard"
Le composant "Data Guard" permet à ASM de vérifier dans le contenu des pages HTML générées par le serveur
applicatif la présence de valeurs "non autorisées" comme par exemple les numéros de carte bancaire.
Data Guard permet aussi d’analyser le contenu de fichiers téléchargés depuis l’application (PDF, Word, etc…) à la
recherche des mêmes chaînes de caractères suspectes.
En cas de détection, ASM peut bloquer la page ou simplement remplacer la chaîne par une suite de caractères "*".
Figure 37 : Configuration du "Data Guard"

2.2.12. Protection contre les attaques CSRF – "CSRF Protection"
Les attaques de type Cross-Site Request Forgery (CSRF) utilisent l'utilisateur comme déclencheur, celui-ci devient
complice sans en être conscient. L'attaque étant actionnée par l'utilisateur, un grand nombre de systèmes
d'authentification sont contournés.
Le CSRF est un type d'attaque qui :
§ Implique un site cible qui repose sur l'authentification d'un utilisateur pour effectuer certaines actions
§ Exploite cette confiance reposant uniquement dans l'authentification pour autoriser des actions
implicitement
§ Envoie des requêtes HTTP à l'insu de l'utilisateur pour déclencher ces actions au travers de sa session
authentifiée
Pour résumer, les sites sensibles au CSRF sont ceux qui acceptent les actions sur le simple fait de l'authentification à
un instant donné de l'utilisateur et non sur une autorisation explicite de l'utilisateur pour une action donnée.
Le composant CSRF d’ASM permet la mise en place d’un mécanisme de "tokenisation" des formulaires et des liens
afin de protéger les pages contre une utilisation frauduleuse de l’application web via le navigateur des utilisateurs
légitimes.
Par exemple dans une page web protégée le lien :
<a href="https://host.domain.com/default.aspx">
Devient :
<a href="https://host.domain.com/default.aspx?CSRT=17017154763700437104">
L’activation de la protection CSRF est réalisée en listant les pages sensibles aux attaques (les caractères génériques
sont supportés). Une page à risque contient généralement un formulaire permettant la saisie de données sensibles,
qui si elles sont manipulées peuvent présenter un intérêt pour un hacker. Exemple : la page de saisie d’un virement
d’une banque en ligne.
Figure 38 : Configuration de la protection contre les attaques CSRF

2.2.13. Détection des anomalies – "Anomaly Detection"
2.2.13.1. Protection contre les atttaques "Brute-Force"

ASM protège l’application en évitant qu’un utilisateur ne génère trop de requêtes sur une page d’authentification
afin de découvrir des mots de passe. Pour ce faire, différentes stratégies sont mises en œuvre.
Attaques en provenance d’une source unique

Une attaque de type Brute-Force peut parfois provenir d’une même source, à savoir une adresse IP source
spécifique, un "device ID" unique ou un nom d’utilisateur particulier. En cas de détection d’un comportement
suspect, basée sur le dépassement d’un seuil de requêtes d’authentification ayant échouées, ASM peut alors :
§ Journaliser l’évènement
§ Tester le client en vérifiant s’il est capable de répondre à un challenge JavaScript. Ceci permet de bloquer
les Bots les plus simples sans générer de perturbation pour les utilisateurs légitimes
§ Demander la saisie d’un CAPTCHA à l’utilisateur
§ Répondre à la source par une page de blocage
§ Répondre à la source par une page de type "Honey Pot" (fausse page d’authentification laissant croire à la
source que son comportement suspect n’a pas été détecté)
§ Couper la connexion TCP de la source
Certaines de ces actions peuvent être combinées et enchaînées. Par exemple, il est classique dans un premier temps
de répondre à la source par un challenge JavaScript puis si l’attaque continue de répondre cette fois avec un
CAPTCHA et enfin de couper la connexion TCP de la source si celle-ci parvenait in fine à contourner le système de
CAPTCHA d’ASM.
Attaques en provenance de multiples sources

Certaines attaques Brute-Force ne permettent pas d’identifier une source en particulier. Il peut par exemple s’agir
d’un robot essayant des combinaisons de noms d’utilisateur et de mots de passe tous différents et en provenance
d’un grand nombre de machines non similaires et localisées à des endroits différents.
En cas de détection d’un comportement suspect, basée sur le dépassement d’un seuil de requêtes d’authentification
ayant échouées, ASM peut alors :
§ Journaliser l’événement
§ Tester les clients en vérifiant s’ils sont capables de répondre à un challenge JavaScript. Ceci permet de
bloquer les Bots les plus simples sans générer de perturbation pour les utilisateurs légitimes
§ Demander la saisie d’un CAPTCHA aux utilisateurs
§ Enchainer successivement ces trois actions

Figure 39 : Configuration de la protection contre les attaques "Brute-Force"
2.2.13.2. Protection contre les attaques "Web Scraping"

Le Web Scraping décrit généralement en informatique un moyen d'extraire du contenu d'un site Web, via un script
ou un programme, dans le but d’en exploiter la donnée ou de changer son format pour permettre son utilisation
dans un autre contexte sans respecter les droits de ses auteurs.
ASM met en œuvre les protections suivantes contre les attaques Web Scraping :
Protection Description
Détection des clients suspects ASM sait détecter et bloquer les clients ayant dans leur
navigateur des plugins ou extensions utilisables dans le
cadre d’attaques web scraping.
Détection de Bot ASM sait détecter et bloquer :
- une navigation trop rapide (changements de pages,
rafraichissements de pages) en provenance d’une
source identifiée
- des entrées clavier / souris / écran tactile suspectes,
potentiellement effectuées par un robot
Détection d’ouvertures anormales de sessions ASM sait détecter et bloquer :
- des ouvertures de sessions trop nombreuses
en provenance d’une même adresse IP

- des réinitialisations (reset) de session trop
nombreuses en provenance d’une même
source, identifiée sur la base d’informations
persistantes dans son navigateur
Détection de transactions anormalement nombreuses ASM sait détecter et bloquer des clients ayant au cours
de leur session un nombre de transactions avec
l’application anormalement élevé par rapport aux
autres utilisateurs
Figure 40 : Configuration de la protection contre les attaques "Web Scraping"
2.2.14. Intégration avec des services tiers – "Integrated Services"
2.2.14.1. Protection Anti-virus

Il est possible d’interconnecter ASM avec un serveur Anti-Virus ICAP (Internet Content Adaptation Protocol) pour
fournir une protection contre les malwares. ASM va ainsi soumettre au serveur ICAP les requêtes pour analyse. ASM
a été testé et validé avec les solutions McAfee VirusScan, Trend Micro InterScan, Symantec Protection Engine, et
Kaspersky Antivirus.
Il est ainsi possible de configurer une vérification antivirale pour les téléchargements de fichiers en HTTP et les pièces
jointes aux requêtes de type web service SOAP.

Figure 41 : Configuration du serveur ICAP
2.2.14.2. Sécurité des bases données (DAM)

Il est possible de déployer ASM avec des produits de sécurité de bases de données (Database Activity Monitoring
ou DAM), comme IBM InfoSphere Guardium, pour augmenter la visibilité sur les sessions des utilisateurs, recevoir
les alertes sur toute activité suspecte et prévenir des attaques.
Lorsqu’ASM est intégré avec un tel système, il surveille le trafic applicatif web et fournit des informations au DAM,
que celui-ci ne peut obtenir directement, comme le nom de l’utilisateur correspondant à chaque session. Ainsi, le
DAM peut corréler les requêtes SQL générées par le serveur web avec l’activité d’un utilisateur sur le serveur web.
La figure ci-dessous montre un exemple d’intégration entre ASM et IBM InfoSphere Guardium :
Figure 42 : Exemple d’intégration entre ASM et IBM InfoSphere Guardium
2.2.15. Gestion des localisations des clients – "Geolocation Enforcement"
La fonctionnalité de géolocalisation permet d’identifier la provenance géographique d’un client ou d’un utilisateur
d’application web, sur la base de son adresse IP.
Pour les applications protégées par ASM, il est possible d’utiliser la fonctionnalité de "Geolocation Enforcement"
pour retreindre ou autoriser l’utilisation d’une application à des pays spécifiques. Cela se fait en ajustant la liste des
pays ou des localisations qui sont autorisés ou bloqués dans une politique de sécurité.
Si un utilisateur essaie d’accéder à l’application web à partir d’une localisation non autorisée, ASM remonte une
alerte de violation.

Figure 43 : Configuration du "Geolocation Enforcement"
2.3. Configurations complémentaires de sécurité
2.3.1. Protection contre les Bots et les DoS - "DoS Profile"
ASM fournit un ensemble de mécanismes de détection des bots et des dénis de service (DoS/DDoS), couplé à des
systèmes de défense visant à en atténuer les effets.
Ces fonctions sont regroupées au sein d'un profil DoS, qui peut être associé à un "Virtual Server" (une application
protégée) indépendamment du profil ASM.
Le profil DoS se compose de plusieurs moteurs, combinant des bases de signatures de bots avec des mécanismes de
détection de comportements suspects. En voici la description :
Fonction Description Classification principale

Identification et blocage des bots connus
Bot Signatures Sécurité négative
(repérables grâce à une signature particulière)
Proactive Bot Defense Identification et blocage des bots inconnus Analyse comportementale
Identification et autorisation des utilisateurs
Mobile Applications (SDK) Sécurité positive
légitimes d'applications mobiles
Détection et blocage d'attaques DoS, sur la base
TPS-based Detection Analyse comportementale
de seuils de requêtes HTTP par seconde
Stress-based Detection de seuils de latence serveur et de requêtes HTTP Analyse comportementale
par seconde
Behavioral Detection d'une analyse multidimensionnelle (environ 500 Analyse comportementale
critères) s'appuyant sur du machine learning.
2.3.1.1. Protection contre le robots -"Bots"
Détection des robots par signature – "Bot Signatures"

Cette section du profil DoS détecte et classe chaque bot dans une catégorie (crawler, dos tool, stress tool, search
engine…). Chaque catégorie de bot peut être indépendamment détectée ou bloquée. Par défaut, l'outil va bloquer
les bots malveillants et autoriser les inoffensifs, tels que les moteurs de recherche. C'est la première étape de filtrage
des bots et la plus simple à réaliser, puisqu'elle se base sur une analyse purement statique.

NB: l'identité des bots dits inoffensifs ("Benign") est doublement vérifiée: via leur signature mais aussi via une
requête DNS inversée ("reverse-lookup") sur l'adresse IP source du client, permettant au système de s'assurer qu'il
ne s'agit pas d'une tentative d'usurpation d'identité.
Figure 44 : Configuration des "Bot Signatures"
Détection des robots inconnus – "Proactive Bot Defense"

Certains robots ne pouvant être systématiquement détectés par une signature spécifique, le profil DoS permet de
différencier les humains des robots sur la base d'une analyse comportementale. Ce moteur, activable en toute
circonstance ou uniquement en cas d'attaque DoS en cours, va envoyer plusieurs challenges aux clients d'une
application pour permettre d'identifier les robots parmi la population d'utilisateurs. Le système va associer à chacun
un score permettant par la suite de décider si le client sera autorisé, bloqué ou soumis à la validation d'un CAPTCHA
pour poursuivre sa session sur l'application protégée.

NB: une fois cette fonctionnalité est activée, lorsqu’un client accède au site web protégé pour la première fois, le
système injecte un challenge JavaScript en lieu et place de la réponse initiale, dans le but de valider si le client est
un navigateur web légitime ou s’il s’agit d’un robot (Bot). Un navigateur web légitime saura répondre au challenge
correctement et envoyer sa prochaine requête avec un cookie signé, qu’ASM validera. Cela se fera de façon
totalement transparente pour l'utilisateur. Il sera alors autorisé à accéder au serveur applicatif. Toutefois, à cause
de l'utilisation de code JavaScript, ce mécanisme est incompatible avec les applications mobiles. Il convient d'utiliser
la section "Mobile Applications" du profil DoS pour protéger les services web dont les clients sont des applications
mobiles.
Figure 45 : Configuration du "Proactive Bot Defense"
Identification des utilisateurs légitimes d'applications mobiles – "Mobile Applications (SDK)"

Les applications mobiles ne pouvant pas être challengées de la même manière qu'un navigateur pour différencier
les bots des utilisateurs légitimes, il est nécessaire d'utiliser des fonctions dédiées à cet environnement.
La section "Mobile Applications" du profil DoS, créée dans ce but, permet d'établir des critères de conformité pour
applications mobiles (iOS ou Android) souhaitant se connecter au service web protégé.
L'identification des applications légitimes repose sur l'implémentation d'un SDK (fourni par F5) dans le code source
de l'application mobile. Au lancement de l'application, ce code va permettre à ASM de réaliser une vérification de
conformité de celle-ci et une analyse du comportement de l'utilisateur. Les applications mobiles non conformes,
émulées ou contrôlées par un "Bot" pourront alors être bloquées. De même, les téléphones identifiés comme
"Jailbroken" (iOS) ou "Rooted" (Android) peuvent être interdits d'accès.
NB: cette fonction est une option soumise à licence additionnelle.

Figure 46 : Configuration de la protection anti-bot pour mobiles
2.3.1.2. Protection contre les attaques DoS/DDoS

Le profil DoS permet de détecter et atténuer les effets des attaques DoS et DDoS. Une première méthode de
détection, nommée "TPS-based," se base uniquement sur un comptage du nombre de transactions HTTP par
seconde (TPS), tandis qu'une deuxième, nommée "Stress-based", combine le comptage du nombre de TPS avec une
détection simultanée de l'augmentation de la latence serveur. Enfin, une dernière méthode, nommée "Behavioral
Detection and Mitigation", met en œuvre une analyse multidimensionnelle sur environ 500 critères pour repérer
des anomalies dans le trafic.
Méthodes "TPS-based" et "Stress-based"

Ces deux méthodes utilisent des vecteurs de détection et des méthodes d'atténuation des attaques similaires. En
voici la liste :
Vecteurs de détection Méthodes d'atténuation

Seuil de TPS par adresse IP source § Challenge JavaScript
§ Challenge CAPTCHA
§ Limitation du nombre de requêtes
§ Blocage de toutes les requêtes

Seuil de TPS device ID § Challenge JavaScript
Seuil de TPS par géolocalisation § Challenge JavaScript
Seuil de TPS par URL § Challenge JavaScript
Seuil de TPS pour tout le site web § Challenge JavaScript
(toutes URLs confondues) § Challenge CAPTCHA
Tous les vecteurs de détection peuvent s'additionner pour former une protection complète de l'application. De
même, les méthodes d'atténuation peuvent être combinées et jouées les unes après les autres, par ordre croissant
d'impact sur les utilisateurs, en fonction de la robustesse de l'attaque. Par exemple, il est recommandé de réaliser
en premier un challenge JavaScript des clients car celui-ci est totalement transparent pour les utilisateurs légitimes,
avant d'éventuellement challenger les clients avec un CAPTCHA ou de limiter de nombre de leurs requêtes.
Chaque seuil de transactions HTTP par seconde (TPS) est en réalité composé d'un double seuil :
§ Un premier, absolu, qui correspond au nombre maximal de TPS devant être comptées à travers le vecteur
de détection désigné.
§ Un second, relatif, qui correspond à un ratio d'augmentation du nombre de TPS sur le dernier relevé par
rapport à une moyenne mobile.
Ces seuils peuvent être soit définis manuellement par l'administrateur, soit automatiquement sur la base d'une
analyse du trafic web.

Figure 47 : Extrait de configuration du "TPS-based Detection"
Méthode "Behavioral Detection and Mitigation"

F5 Networks a développé une technologie innovante qui détecte et atténue les attaques en DDoS, pas simplement
en tirant partie des seuils de TPS définis et de l'augmentation de la latence serveur, mais aussi en mettant en œuvre
du "Machine Learning" et les analyses "Big Data" pour repérer des anomalies dans le trafic web. Ce moteur,
entièrement basé sur une étude statistique, est en apprentissage permanent sur la base de 500 critères d'analyse
afin d'améliorer sa précision. Chaque attaque détectée et atténuée sert d'expérience nouvelle au moteur pour
affiner ses futures analyses. L'approche utilisée peut se résumer en 6 étapes :
1. Apprendre le comportement typique d'un client sur une application

2. Détecter une attaque sur l'application (augmentation soudaine des TPS, de la latence serveur…)
3. Trouver une anomalie dans les comportements observés – Ce qui a changé par rapport au comportement
général avant l'attaque
4. Identifier les clients qui ont créé les anomalies détectées (les attaquants)
5. Générer une liste de règles (signatures) qui décrivent le comportement des attaquants, sans affecter le
trafic légitime
6. Bloquer les attaquants par différents vecteurs, notamment par ralentissement ou blocage des adresses IP
source suspectes et par mise en œuvre des signatures crées.
NB: les signatures créées peuvent être soumises à approbation de l'administrateur avant d'être utilisées par le
système pour bloquer le trafic malveillant.

Figure 48 : Configuration du "Behavioral Detection and Mitigation"
2.3.2. Sécurité FTP
ASM offre la capacité de protéger les flux FTP en effectuant des contrôles sur les tentatives de connexion
ou les commandes autorisées dans un canal FTP.
Figure 49 : Configuration de la sécurité FTP

2.3.3. Sécurité SMTP
ASM offre la capacité de protéger les flux SMTP en effectuant des contrôles sur les tentatives de connexion
ou les commandes autorisées ainsi que la mise en place d’un mécanisme de "grey filtering".
Figure 50 : Configuration de la sécurité SMTP

2.4. Fonctionnalités de gestion des politiques ASM
2.4.1. Politique de blocage
Dans les propriétés générales de chaque politique ASM, il est possible de configurer si à la suite d'une détection
d’une attaque celle-ci doit engendrer un blocage, une alarme ou un apprentissage.
Pour chaque famille de violation il est donc possible de changer le comportement d’ASM. Cela permet par exemple
d'avoir une politique de sécurité bloquante sur certains critères éprouvés, tout en testant l'outil en mode non
bloquant sur des nouvelles fonctionnalités.
Figure 51 : Extrait de la politique de blocage
2.4.2. Moteur d'apprentissage de politique ASM – "Policy Builder"
A partir de la version 12.0, ASM embarque un nouveau système d'apprentissage qui combine des éléments de
définition semi-automatiques et automatiques pour la construction de politiques de sécurité. Les moteurs de
définition semi-automatiques et automatiques étaient séparés dans les versions précédentes.
Désormais, il existe un seul écran pour les suggestions de modification des politiques de sécurité, quelle que soit la
méthode d'apprentissage.

Figure 52 : Écran de gestion des suggestions du "Policy Builder"
L’intérêt de cette fonctionnalité est qu’elle apporte une visibilité complète pour les suggestions d’apprentissage et
les informations nécessaires pour les gérer à partir d’un seul endroit.
Dans le mode automatique, on peut laisser le système prendre les décisions, mais on peut aussi à tout moment voir
les suggestions en attente et prendre les actions appropriées avant que le système le fasse de lui-même, afin
d'accélérer la période d'apprentissage. Quel que soit le mode d'apprentissage choisi, chaque suggestion est associée
à un score de fiabilité, qui évolue en fonction du nombre d'utilisateurs uniques produisant la même suggestion et
de sa répétition à intervalles réguliers dans le temps. Lorsque le Unified Policy Builder est en mode automatique, les
suggestions ayant 100% de score de fiabilité sont acceptées par le système dans la politique ASM.
Par ailleurs, avec la console de gestion des suggestions, il est possible de :
§ Filtrer et trier les suggestions par score de fiabilité et types de violations associées, afin de traiter en priorité
celles qui sont les plus importantes.
§ Pour chaque suggestion, visualiser en détails les logs complets de la requête à étudier et le jeu de violations
qui ont déclenché la suggestion.
§ Visualiser toutes les suggestions relatives à une entité (URL, paramètre…) afin par exemple de faire des
traitements groupés.
Concernant les actions possibles sur les suggestions, on peut effectuer les suivantes :
§ Accepter la suggestion : la politique ASM est modifiée de façon que les violations ne se reproduisent plus.

§ Ignorer la suggestion : la suggestion ne sera pas apprise automatiquement et n’apparaitra plus dans l’écran
d’apprentissage. Il sera cependant possible de la visualiser depuis le filtre des "Ignored Suggestions".
§ Laisser la suggestion telle quelle et voir l’évolution de son score de fiabilité augmenter avec le temps. Dans
ce cas, la violation sera marquée comme "lue".
§ Supprimer la suggestion. Elle peut potentiellement revenir si un autre évènement la déclenche mais l'action
remet son score de fiabilité à zéro.
Dans tous les cas, il est possible de mettre un commentaire dans la suggestion pour décrire la violation et la raison
derrière la décision prise.
Enfin, la console de gestion des suggestions dispose d'une fonction de création de rapports dédiés permettant à la
fois d'obtenir une vue résumée et classée par catégories des suggestions en attente de traitement et objets ajoutés
à la politique, ainsi qu'une vue graphique de l'évolution dans le temps du nombre de suggestions et d'objets créés.
Figure 53 : Exemple de rapport produit par le "Policy Builder"

2.4.3. Classification des violations de sécurité
Pour chaque requête qui provoque une violation de sécurité, le système fournit une classification sur la base de
valeurs allant de 1 à 5, où la valeur 1 correspond sûrement à un faux positif et la valeur 5 correspond très
probablement à une attaque réelle sur l’application web.
Cette classification, qui facilite à l’administrateur la prise de décision concernant les suggestions d’apprentissage à
accepter, peut être consultée dans deux menus du module ASM.
Revue des logs de requêtes

Afin de faciliter la lecture et l’analyse des entrées de logs pour discerner les attaques effectives et les faux positifs, il
est possible de filtrer les requêtes par leurs niveaux de classification de violation.
Si la majorité des requêtes ont une classification (violation rating) basse, la politique de sécurité a de forte chance
d’être trop stricte et génère surement des faux positifs.
Si la majorité des requêtes ont une classification (rating) haute, la politique de sécurité est probablement définie
correctement mais le site web doit faire l’objet d’une attaque ou affiche un comportement vulnérable (envoi de
requêtes SQL ou uploads HTML).
Revue des suggestions du moteur d’apprentissage manuel :

De façon générale, accepter toutes les suggestions d’apprentissage peut conduire à un assouplissement de la
politique de sécurité et, potentiellement, à accepter plus attaques.

Avec la fonctionnalité de classification de violation (violation rating), lors de la revue des suggestions du moteur
d’apprentissage manuel, il est possible de consulter le niveau de classification de la requête qui a généré la
violation.
Dans le cas où la classification (rating) est basse, la violation de sécurité est probablement un faux positif et l’on peut
envisager l’acception de la suggestion du moteur d’apprentissage (typiquement, en modifiant la politique de sécurité
pour autoriser la "violation" qui n’en est probablement pas une).
En revanche, si le niveau de classification est haut, la violation constitue probablement une menace réelle et il faut
analyser la requête avant de modifier ou pas la politique de sécurité.
2.4.4. Définition des "Server Technologies"
Afin de faciliter la mise en œuvre de signatures d'attaques spécifiques à l'application protégée, il est recommandé
d'utiliser le menu "Server Technologies". Ce dernier propose d'ajouter pour le compte de l'administrateur les
signatures adéquates sur la base :
§ soit des choix de pile applicative faits par l'administrateur (saisie manuelle)
§ soit d'une détermination automatique grâce à un apprentissage fait par analyse du trafic applicatif.
Figure 56 : Exemple de configuration des "Server Technologies"
2.4.5. Visualisation de l'arborescence d'une politique ASM - "Tree View"
Au fur et à mesure de l'apprentissage réalisé sur l'application protégée, l'arborescence de cette dernière pourra être
représentée, notamment lorsqu'il s'agit de créer une liste blanche. Chaque objet de la "Tree View" est en réalité un
lien vers un élément de la configuration de la politique ASM, ce qui facilite la recherche d'objets dans les politiques
complexes et donc in fine l'exploitation de la solution.

Figure 57 : Vision "Tree View"
2.4.6. Pages de réponse en cas de violation de politique de sécurité – "Response Pages"
Lorsqu'ASM détecte une anomalie dans le trafic, il forge une réponse qui est envoyée au client de l'application. Par
défaut, cette réponse indique explicitement que la requête de l'utilisateur a été rejetée et spécifie un "Support ID",
qui est un identifiant que l'utilisateur bloqué peut donner à l'administrateur d'ASM s'il estime que sa requête était
légitime (faux positif).
En réalité, ASM permet de configurer plusieurs types de réponses pour une même policy, notamment selon le type
de requête (HTTP classique, XML, Ajax, JSON…), voire même d'afficher une page de saisie de CAPTCHA à l'utilisateur
dans certains cas (en particulier en cas de Brute-Force).
Enfin, quel que soit le type de page de réponse, son contenu est entièrement personnalisable, des headers au body.
Figure 58 : Configuration des "Response Pages"

2.4.7. Logs d'administration – "Audit Logs"
ASM garde trace des modifications réalisées sur chacune de ses politiques. Parmi les informations sauvegardées, on
trouve notamment la date de l’événement, l’action réalisée et le nom de l’utilisateur à l’origine du changement de
configuration.
Figure 59 : Exemple de visualisation des "Audit Logs"
2.4.8. Historique des versions des politiques ASM
A chaque modification dans une politique ASM, le système garde en historique la version précédent le changement,
permettant un retour arrière rapide en cas d’erreur constatée après déploiement.
Figure 60 : Gestion de l'historique des configurations

2.4.9. Gestion des différences entre politiques ASM
ASM met à disposition un outil de gestion des différences entre deux politiques. Il permet de mettre en évidence les
objets qui n’existent que dans l’une ou l’autre des deux politiques comparées. Chaque différence peut être
directement corrigée à partir de cette interface. Enfin, une fonction de fusion globale permet de faciliter les
changements en les traitant de manière groupée.
Figure 61 : Gestion des différences entre politiques ASM
2.4.10. Héritage entre politiques ASM
A partir de la version 13.0 d’ASM, son administrateur peut définir à la création de chaque politique si cette dernière
sera une "Security Policy" ou une "Parent Policy":
§ "Security Policy" : il s'agit tout simplement d'une politique ASM qui pourra être associée à un Virtual Server,
c'est à dire qui pourra avoir une action sur le trafic applicatif, comme toutes les politiques ASM des versions
antérieures.
§ "Parent Policy" : il s'agit d'un type de politique ASM permettant de suggérer voire d'imposer certains
paramètres à ses politiques "enfant", c'est à dire aux "Security Policies"
L'intérêt de cette fonctionnalité est de faciliter la gestion des politiques ASM, notamment lorsque celles-ci
deviennent nombreuses et qu'il devient donc plus difficile de s'assurer que chacune est bien en adéquation avec la
PSSI. En effet, une politique "Parent" peut par exemple décider d'activer un certain nombre de paramètres
correspondant à un minimum de sécurité requis, afin d'assurer la mise en conformité avec la PSSI de toutes les
applications protégées.

De manière générale, un changement sur une politique "Parent" peut être répercuté immédiatement sur toutes les
politiques "Security", ce qui permet aussi de limiter les actions à effectuer de manière itérative sur chacune lorsqu'un
administrateur décide par exemple d'élever le niveau de sécurité de toutes ses politiques ASM.
L'exemple suivant montre les paramètres d'une politique "Parent". Chacun peut avoir 3 états :
§ "Madatory" : toute politique "Security" en héritant devra avoir la même configuration que sa politique
"Parent". Si un changement doit avoir lieu, par exemple à cause d'un faux positif mis en évidence, seule la
politique "Parent" peut l'autoriser.
§ "Optional" : les politiques "Security" en héritant devront décider si elles acceptent les paramètres de leur
"Parent" ou si elles souhaitent les outrepasser.
§ "None" : la fonction d'héritage sera désactivée sur les paramètres désignés.
Figure 62 : Gestion de l'héritage entre politiques ASM


2.4.11. Liste des tâches en attente
Afin de faciliter la configuration du module de sécurité ASM, ce dernier dispose d’un écran "Overview", global à
toutes les politiques, qui permet d’obtenir une vue synthétique des tâches restantes afin de finaliser la configuration
des politiques de sécurité.
Figure 65 : Visualisation de la page "Overview"

2.4.12. Mise à jour de la base de signatures
Les signatures d'attaques sont développées et maintenues par F5. Elles sont mises à jour très régulièrement par une
équipe d’experts sécurité. La fréquence de mise à jour n’est pas fermement définie et peut varier dans le temps. Le
service a été lancé en 2007 sur la base d’une mise à jour de la base signature tous les 3 mois. L’actualité sécurité
peut conduire à une mise à disposition de nouvelles signatures plus rapidement.
Cette opération de mise à jour de la base de signature est réalisable de plusieurs façons :
Téléchargement automatique
Il est possible de demander au boîtier de récupérer les mises à jour sur le site de téléchargement F5. Cela n’est
possible que si le boîtier dispose d’une connexion internet. Si nécessaire, ASM peut utiliser un proxy explicit pour
réaliser cette connexion.
Téléchargement manuel
L’administrateur ou l’exploitant peut réaliser le téléchargement du fichier de signature sur le site downloads.f5.com.
Il est alors possible de déposer ce fichier sur l'instance ASM.
Il est important de noter que les nouvelles signatures peuvent être placées en état "Staging", c'est à dire soumises
à une période d'évaluation avant d'être éventuellement passées en mode bloquant. Cela permet d'éviter un risque
de faux positif lors d'une mise à jour de la base de signatures.
Figure 66 : Configuration de la mise à jour de la base de signatures

2.4.13. Mise à jour de la base de réputation IP
Concernant la base de données de réputation IP, une fois la licence associée présente dans le système, un processus
spécifique réalise à la mise à jour automatique de la base toutes les trois minutes, à destination du serveur hébergé
chez WebRoot, le fournisseur du service.
Figure 67 : Vérification de la mise à jour de la base de réputation IP
2.5. Journaux d’événements – "Logs"
2.5.1. Événements de sécurité - "Event Logs"
Par défaut la configuration d’ASM repose sur la journalisation locale des événements de sécurité (le trafic
légitime n’est pas journalisé). Mais il est aussi possible de journaliser les événements (et le trafic légitime) sur un
serveur externe de type Syslog. De plus, ASM supporte la journalisation simultanée vers de multiples destinations,
chacune pouvant avoir son propre format de "log".
Quand les journaux sont stockés localement, ils sont accessibles via l’interface d’administration et incluent
des informations complémentaires sur chaque événement (liste non exhaustive) :
§ Type d’attaque et raison de la levée d'alerte

§ Géolocalisation du client (si disponible)
§ Réputation IP du client (si disponible)
§ Nom d'utilisateur de la session (si disponible)
§ ID de la session
§ ID de la requête (appelé également "Support ID")
§ Contenu de la requête et/ou de la réponse provoquant l'alerte.
§ Noms du Virtual Server et de la politique ASM concernés
§ Heure de l'évènement

Figure 68 : Interface de visualisation des événements de sécurité

Figure 69 : Informations complémentaires sur un événement de sécurité
2.5.2. Incident et corrélation d’événements – "Event Correlation"
Afin de réduire la charge de traitement unitaire des événements de sécurité, ASM embarque un moteur de
corrélation basé sur la source, la destination et le type d’attaque qui permet de regrouper les événements sous
forme d’incidents de sécurité. Ainsi, si un attaquant émet par exemple une suite d'injections SQL à destination d'une
même application, les événement de sécurité associés seront tous regroupés sous le même incident.

Figure 70 : Incidents – Vue générale
Figure 71 : Incidents - Zoom
2.5.3. Évènements DoS L7
Il est possible d’afficher des journaux d’évènements spécifiques aux attaques DoS L7 afin d’obtenir des informations
détaillées sur les attaques et les éventuelles contre-mesures prises par ASM.

La figure suivante montre un exemple de journal d’évènements DoS qui affiche les informations relatives à une
attaque DoS : comme l'heure de début et de fin de l’attaque, la méthode d’atténuation utilisée par ASM, l’adresse
IP à l’origine de l’attaque, le nombre de transactions par seconde et un identifiant unique par attaque.
Figure 72: Exemple de journal d’évènements DoS
2.6. Génération de rapports – "Reporting"
2.6.1. Rapports sur les évènements de sécurité
En complément des journaux d'évènements, il est possible via l’interface d’administration d'ASM de générer des
rapports graphiques sur les différents critères qui sont stockés dans sa base de données. Il est également possible
de faire envoyer des rapports de façon automatique par mail.

Figure 73 : Exemple de rapport de sécurité
Figure 74 : Exemple de rapport de sécurité

2.6.2. Rapports sur les attaques DoS L7
Lorsque la protection contre les dénis de service (DoS) est active sur le système, il est possible de visualiser les
graphiques, rapports et statistiques relatifs et les atténuations mises en œuvre par le système.
2.6.2.1. Ecran de visualisation des attaques DoS

L'interface d'ASM intègre un écran dynamique de visualisation des attaques DoS en cours et passées.
Figure 75 : Dashboard DoS

Figure 76 : Dashboard DoS
2.6.2.2. Rapport sur les latences par URL

Il est possible d’afficher les statistiques de latences des pages web d’une application web.
Le rapport liste les latences pour chaque URL séparément et peut aussi afficher une latence moyenne pour toutes
les URLs combinées.

Figure 77: Exemple de rapport de latences par URL
2.6.3. Conformité PCI-DSS
ASM intègre la génération d'un rapport synthétique de conformité de la configuration de chacune de ses politiques
vis-à-vis des règles PCI-DSS.
Figure 78 : Exemple de rapport PCI-DSS

Langue

Boiler BIG-IP ASM v13.1

Transféré par

Informations du document

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Boiler BIG-IP ASM v13.1

Transféré par

Droits d'auteur :

BIG-IP® Application Security Manager™ (ASM)

est une solution de sécurisation des

BIG-IP Application Security Manager ASM

2. Détail des fonctionnalités d'ASM ____________________________________________ 8

2.2. Composants d’une politique de sécurité ASM ______________________________________14

1 BIG-IP APPLICATION SECURITY MANAGER v13.1| F5 NETWORKS

2.3. Configurations complémentaires de sécurité ______________________________________39

2.4. Fonctionnalités de gestion des politiques ASM _____________________________________47

2.5. Journaux d’événements – "Logs" ________________________________________________59

2.6. Génération de rapports – "Reporting" ____________________________________________63

2 BIG-IP APPLICATION SECURITY MANAGER v13.1| F5 NETWORKS

Nicolas Berthier Avant-Vente

Tewfik Megherbi Avant-Vente

Xavier Dauphin Avant-Vente

Date Auteur Version Description de la révision

N. Berthier 11.2 Original

05/05/2016 T. Megherbi 12.0 Ajouts des nouvelles fonctionnalités de la version 12.0

04/07/2016 T. Megherbi 12.1 Ajouts des nouvelles fonctionnalités de la version 12.1

01/03/2018 X. Dauphin 13.1 Ajouts des nouvelles fonctionnalités de la version 13.1

Référence Auteur Version Description de la révision

3 BIG-IP APPLICATION SECURITY MANAGER v13.1| F5 NETWORKS

§ Les protocoles (RFC) et langages (HTTP, XML, JSON, Web Socket…)

4 BIG-IP APPLICATION SECURITY MANAGER v13.1| F5 NETWORKS

Les fonctions clés de la solution ASM sont les suivantes :

5 BIG-IP APPLICATION SECURITY MANAGER v13.1| F5 NETWORKS

§ Les manipulations des cookies ou des champs cachés.

6 BIG-IP APPLICATION SECURITY MANAGER v13.1| F5 NETWORKS

Garantit la sécurité et la disponibilité de l’application

Réduit les coûts d'exploitation et assure la conformité des applications

Fournit des politiques de sécurité prêtes à l’emploi

Améliore la sécurité et la performance des applications

Apporte de la flexibilité et s’intègre avec les outils de sécurité tiers

7 BIG-IP APPLICATION SECURITY MANAGER v13.1| F5 NETWORKS

2.1. Création d’une politique de sécurité

Figure 1 : Écran de configuration de l’assistant de création

8 BIG-IP APPLICATION SECURITY MANAGER v13.1| F5 NETWORKS

2.1.2. L’approche de sécurité négative

2.1.3. L'approche de sécurité combinant sécurité positive et négative

2.1.4. L'analyse comportementale

9 BIG-IP APPLICATION SECURITY MANAGER v13.1| F5 NETWORKS

2.1.5. La protection au niveau du navigateur de l’utilisateur

2.1.6. L'utilisation du moteur d’apprentissage automatique

2.1.6.1. Réglage de la sensibilité du "Policy Builder"

10 BIG-IP APPLICATION SECURITY MANAGER v13.1| F5 NETWORKS

2.1.6.2. Policy Builder - Liste des sources de confiance

2.1.6.3. Le mode semi-automatique

Figure 3 : Écran d'apprentissage des suggestions

11 BIG-IP APPLICATION SECURITY MANAGER v13.1| F5 NETWORKS

2.1.7.1. Templates spécifiques à une application

La liste des "templates" actuellement disponibles est :

§ ActiveSync v1.0 v2.0

2.1.7.2. Templates génériques

2.1.8. L'utilisation d’un résultat d’audit de vulnérabilités

12 BIG-IP APPLICATION SECURITY MANAGER v13.1| F5 NETWORKS

Figure 4 : Écran d'import d’un rapport d’audit de vulnérabilités

Figure 5 : Utilisation d'un rapport d’audit de vulnérabilités

13 BIG-IP APPLICATION SECURITY MANAGER v13.1| F5 NETWORKS

Entité Description Classification principale

14 BIG-IP APPLICATION SECURITY MANAGER v13.1| F5 NETWORKS

Figure 6 : Contrôles de conformité protocolaire

2.2.2. Techniques d'évasion – "Evasion Techniques"

15 BIG-IP APPLICATION SECURITY MANAGER v13.1| F5 NETWORKS

2.2.3. Types de fichiers – "File Type"

Figure 8 : Configuration d'un type de fichier autorisé

Figure 9 : Configuration d'un type de fichier interdit

16 BIG-IP APPLICATION SECURITY MANAGER v13.1| F5 NETWORKS